datakick

@movieseals if you could make a list of modules / or built-in features / that should be integrated with krona, I could try to add support for them in my spare time

what captcha module are you using?

Hi everyone, I've just released first paid version of revws module - you can read more about it's functionality in one of the previous post. At the moment I only sell it on my own website, but I'm figuring how to add this to official thirtybees store. The development of this premium module is not finished yet - I plan to add additional functionality such as rewards for reviews, posting reviews to facebook, automated backups,... But don't worry, if you purchase module now you'll get all future updates for free. PS: you can test the paid module functionality on my demo account

@movieseals I'm afraid there isn't an easy way. Those third party modules will have to implement couple of hooks in order to communicate with krona module. With the small tb community this probably won't happen anytime soon. I'm really sad that this module is not ported to vanilla ps16, because the adoption rate by merchants would be much higher. And with that might come the support by third-party modules.

@colorful-ant try this ``` $content = strip_tags($post->content); $pos = strpos($content, ' ', 160); $meta = substr($content, 0, $pos); ... 'meta_description' => $meta ``` This will strip HTML tags from post, and take max 160 characters. It does not break words - meta description can, and usually will be, a bit shorted than 160 characters.

I've just release new version 1.0.18 Enhancements sanity checks - detect problems with module configuration - report missing email translations etc. improve review creation experience for multiple criteria - there is now a slide effect between criteria drilldowns - links from review list to product / customer microdata - emit information about worst and best ratings fix translations [nl, de, es, ru] dedicated data export / import page (extracted from settings) multiple bugfixes microdata - render aggregated ratings within review list microdata - incorrect calculation of average ratings MyReviews page - fix bug with missing product information

Thanks @nickon for the feedback. I would put the revws subscribe block UNDER the ps/tb thank you block. So that the user is not confused I can't change position of subscribe block - this is decided by theme itself, I just render the content. You would need to modify your theme and move hook placement to some better position. When clicking on the subcribe button I would change the button to “thank you for subscribing” Good idea The checkbox of the email subscription should be on gdpr module where I could check/uncheck the consend I see what I can do about this. Unfortunately it might not be possible, as prestashop's official gdpr module expects every module to have only one consent. In revws case, there are actually two consents, each for specific area of functionality. One is for review authoring (permission to use provided data when someone write a review), the second needs to be given when user create an account, so we can communicate with them.

According to upgrade process you have to Go to your modules directory and DELETE all of your stats module except statsdata and statsmodule. Also delete the modules graphnvd3, gridhtml, pagesnotfound, and sekeywords.

@nickon Someone switched consent mode to Not required, so that's the reason why consent checkbox was not displayed. The module can be access from Catalog > Product reviews

Hi everyone, some of you may already know this - I'm going to release a paid version of revws module with ask for review by email functionality (and then a couple more features). I've just started testing it on my demo account, and I wanted to ask you for your help and feedback. If you are interested in this functionality, please try it. There are these areas to test Consent management with all the GDPR stuff it's important to be nice and friendly. That's why I added support for consent with sending review requests. You can choose one of these consent levels: - no consent required - newsletter subscription is considered consent - either newsletter subscription or explicit consent - explicit consent When you choose one of the explicit consent levels, then you will get a consent checkbox on Account creation page, and also additional request on Order confirmation page (but only if we don't have consent yet) Also, you customers can unsubscribe from receiving further email requests, so that should help with compliance as well. Order list There are many options to specify for which orders (and when) email requests should be sent. For example, you can define min and max order age, order state, or how long to wait after merchandise was shipped. To make things easier to understand I added a list of all orders. This list is displaying a stage in which each order is. So you can easily check and see what is going on, why some review requests are not being sent, etc... Emails And of course there are review request emails. You can, obviously, start review process from there. You can also unsubscribe from further review requests. And, to make things a bit more user friendly, there is auto-logging functionality as well.

@luv thanks for reporting this. This is a known bug, and it's already fixed in upcoming version

I was suggesting to use different approach than attribute groups. Attributes are used to generate product combinations. Each combination must have an record in db -- and that's not possible with this many options. Customization, on the other hand, is something completely different. It gives your customers option to customize the product when they order it. I think this is what you want.

Disallow this page using robots.txt, google will eventually stop indexing it.

If these attributes don't have impact on quantity on stock, or on price, then it doesn't really need to be an attribute in the first place. You should have a look at some customization modules, for example https://addons.prestashop.com/en/combinaisons-customization/6638-advanced-customizations.html

If the tbupdater is meant only for those native thirtybees modules, then it makes sense to fix these. It could be a lot of work, though, as someone would have to go through all of them. If, in the future, you plan to use tbupdater module to install / update third party modules (for example community modules from tb store), than this could be a big problem. I've seen many modules that allow user to uploads images (or other files) and stores them somewhere in module's directory. It's not realistic to expect that module developer will fix this. I'm afraid we'll need to choose the lesser evil here. The replace method would keep module code clean, but module updates might result in loss of file-data. The merge method can result in quite a mess in the module directory, with outdated / unused files everywhere. But the module will still work in 99% of the time (unless it does some dangerous *.php autoloading), and no data will be lost. But we definitely need to decide which algorithm to use, and use it both in tbupdater, and in manual module update in core

I checked this - when we manually upload module zip file from backend, its content is merged with the existing module directory. However, when module is updated using tbupdater module, the old module directory is completely deleted and replaced by content from zip package. Although the tbupdater approach sounds like a much better way to me (definitely more predictable and maintainable), I'm afraid it breaks backward compatibility - any module that stores some data to its own directory will be affected by this. Maybe the best solution would be some mixed approach - replace all code files (*.php, *.tpl , *.js , *.html , *.css ) , but keep binary data (images, etc). Also, it would be nice if the same algorithm were used for both manual installation and tbupdater

More information regarding translations. At the moment revws module is translated to bg, cs, de, es, nl languages (only partially) txt Translation 'bg': 156 strings translated [ 62.15% ] Translation 'cs': 251 strings translated [ 100% ] Translation 'de': 170 strings translated [ 67.73% ] Translation 'es': 235 strings translated [ 93.63% ] Translation 'nl': 170 strings translated [ 67.73% ] It would be amazing if you guys could help me complete these translations, or add support for another language. There are few ways to do this: 1) normal prestashop translation process - just translate everything in your thirtybees backoffice, and then send me .php file 2) download and edit language json file from github. If language does not exists yet, download en.json and rename it to your .json. When you done, send me json file via email 3) if you know how to work with git, then clone revws repository and make changes directly there. Then create pull request I personally prefer editing strings directly in json file, as I don't have too much confidence in prestashop backend translator tool.

@daokakao actually strings from *.js files are going through translation process as well. There shouldn't be any need to modify strings in back-version.js file. If you look at javascript source code, you'll see that english strings are wrapped in function named __(), for example __('English text'). This function will replace the string with translated version during runtime. If you find any string that can't be translated, please let me know -- it's possible I've forget to wrap some strings into this function somewhere. It would be great if you could send me your Russian translation to [email protected]. Please include translation of email templates as well, if you can. Your help would be very much appreciated.

Well, I'm sure it didn't destroy itself. What was the last thing you did? Did you modified some tpl file / turn on cache / installed some module? Revert.

@colorful-ant I have found the bug, and it will be fixed in next version

@Traumflug you are right, there seems to be some mechanism. tbupdater module already checks for module updates from this location https://api.thirtybees.com/updates/modules/all.json The question is how this list updates. TB store expects community modules to integrate with github webhooks, so I guess similar mechanism is / should be in place for native modules.

@colorful-ant said in [Free Module]Revws - Product Reviews: Point 1 If I use the new option https://www.yoursite.com/en/reviews and then click on the product in the list, I get a 404 page. I have not yet tested in both shops, but I suspect it may be the same error (whether multilingual or not). The product link from the revws page example https://www.yoursite.com/en/product. The actual link is with me https://www.yoursite.com/en/category/product. After the click, the 404 page appears to me because the correct link to the product is not correct (category is missing in the link). There must be something wrong with your core / routing settings. Revws module just calls standard $product->getLink() function, and renders the url that this function returns. I've tested this, and can confirm this works correctly on tb1.0.4 / ps1.6 / ps17. How do you have your routes / seo set up? Is it possible for a future version to create an option where all scores appear on average in a small div or something that can only be inserted on the homepage, for example. I'm not sure if I follow. Could you elaborate - what is the use case?

That's probably because thirtybees doesn't operate addons alternative - some sort of centralised repository that your store could query and download new version from. I'm not really sure if there is a plan for such repository, though - maybe the new updater will be the solution for this problem

Hi again, the last version contained serious bug regarding translations. If you have installed 1.0.17, please download it again from my website, reinstall, and clear both server and browser cache. Sorry for the trouble

Hi everyone, I've just released new version 1.0.17 Data backup This new feature allows you to export all your data to XML format. Just in case you wanted to change the review module :) In the upcoming version there will be an option to import data from this XML format. Meanwhile, you can use Datakick module for this. Real delete and review filtering As you may know, revws module didn't really delete reviews, it just marked them as deleted and archived them. Now you have an additional option to really delete these archived reviews. I've also introduced filtering for backend review list, so you can choose what reviews should be visible. Archived items are hidden by default - you won't see those red lines anymore (unless you want to). List of all reviews There is a new page that lists all reviews located at reviews route. You can try it by navigating to https://www.yoursite.com/en/reviews or https://www.yoursite.com/reviews I recommend you create some link to this new page, so google can find it and start indexing it! Bugfixes revws did not worked correctly with layered navigation module (ps16/thirtybees) clear cache after GDPR data deletion invalid jquery selector in revws-bootstrap.js file google rich snippets - always render aggregate ratings metadata, even when averages are not displayed on product page Future I've been thinking about this for a long time, and I have decided to fork revws module and provide a paid version with additional functionality. As a long-time unix user I believe in philosophy of having many simple tools, each one of them being great at one particular things. That's why I want to keep free version of this module pure - it will be just about reviews, like it is now. Nothing more. If you want to send review request, use dedicated module made for that. When you want to reward user for writing reviews, use krona module... But there are many merchants that don't share this philosophy. They don't want (or maybe they are not tech savvy enough) to integrate multiple modules together to achieve expected functionality. For these merchants I'll prepare a paid version of revws module, with all the bells and whistles integrated. It won't be as powerful as cooperation of multiple modules, but it will be easy to use and setup.