datakick

@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.

@Manisch / @nickon - what is the percentage of customers who subscribe to newsletter / optin? I don't think it will be substantial. Does it make sense to somehow nudge customers to give consent specifically to send review request? I was thinking about some popup window that would appear after the customer completed the order (and only if he didn't opt-in for newsletter already). Here we could explain the benefits of providing review, ie say that he will receive discount coupon, and ask for the consent for sending review request by email. All without disrupting order process

Also, it occurred to me that my previous solution might be unnecessary complicated. We could just use different html markup. Instead of ``` Label 1 we could use Label 1 and <label> would be implicitly bounded with <input> without the need foridandfor``` attributes. The question is whether the CSS rules to display fancy checkboxes would still apply.

@daokakao said in Checkbox won't check - Art Free GDPR Module: @datakick the codepen example shows slightlyvdifferent behaviour: When i click second checkbox then 'v' mark appears/disappears in the first checkbox, this is obvious behaviour. In the real case the second checkbox does not reacts at all. It does (well, it did). This was the original behaviour - note that clicking on label in main form changes value inside popup: @manisch said in Checkbox won't check - Art Free GDPR Module: Sweet, thanks a lot! Seems to work :) Do you mind posting that also over at the Prestashop forum? First of all the solution could be useful over there, as well. Second I don't want to copy and paste it - you should get the credit. Glad I could help. Feel free to post the solution to ps forum. I don't really need the credit :)

@manisch there are many ways to do this. One possibility is 1) create static variable inside artfreegdpr module that counts how many checkboxes were generated during one request 2) edit hookCreateAccountForm and hookDisplayCustomerIdentityForm hooks - when hook is called, increase counter and pass its value to template 3) use this counter in template itself: Note that this module does not work with this checkbox in any way. Given consent is not stored anywhere, neither is verified on server side that it was actually checked... so it's not very gdpr compliant :)

@daokakao there's no javascript, it's all pure html + css solution. The label is styled differently based on associated input :checked status. See this codepen

@daokakao said in Checkbox won't check - Art Free GDPR Module: So, this div must be bound to some JS which should, in turn, change the value of hidden checkbox. Actually, this is all pure html+css solution, no javascript is necessary. It uses this HTML markup: ``` Label 1 thefor``` attribute on label binds the label with input with id gdpr - when you click on the label it actually toggles value of . And it works as expected. The problem is that there are two inputs with the same id: ``` Label 1 ... Label 2 ``` So, when you click on Label 2, the first will be toggled. You can see this behaviour on this codepen To fix this problem, we have to ensure that the two checkboxes have different IDs. That means edit /views/templates/hook/gdprCheckbox.tpl template, and replace hardcoded id with some variable that is passed from php hook. And ensure that hook generate unique ID

Ahh, I see where the problem is. Your theme has a feature to create account by clicking on person icon in upper right corner. In that case popup window will appear: This popup window contains this GDPR checkbox as well -- that means that your page contains two html elements with the same id. When you click on the label in your account creation form, you are actually switching state of the other input on the page (inside popup window) You gotta love html :)

I think that there may be some javascript that prevents default behaviour. It's hard to tell what js is causing this, because you are using CCC. If you disable CCC, I can have a look. From top of my head: the input id contains dash freegdpr-consent. This could be the problem. Although dash is perfectly valid character, it may confuse some javascript :) You could edit template views/templates/hook/gdprCheckbox.tpland replace all 3 occurances of this text for something different, for example gdpr. If that works... then it's a proof that you have some very buggy javascript on your site, and the same problem can appear elsewhere.

I forgot to clear cache after data erasure, I'll add this to the next version

@nickon let's agree to disagree :) I really think it's not necessary, but... have a look at my fork of this send review request module, where I've just submitted psgdpr support. Should do the trick... I haven't tested it thoroughly, so let me know if you found any bug. You will need to download git repository as zip, unpack it, and rename folder from sendreviewrequest-master to sendreviewrequest. I'll create a pull request, maybe @SLiCK_303 will integrate it to the upstream module

@nickon that can't be right. These are your data, not customer's. Example 1: Lets say I have an online shop where you can upload your photos, and I'll generate some PDF book from it. You can download it after you pay. Does GDPR give the customer the right to have this pdf book exported, just because it's related to him? No, that would be ridiculous. You can have your original photos back, if you wish. And you can ask me to delete everything about you (including the book). But I don't have to give you the book itself (unless you pay for it). Example 2: let's say that you calculate some sort of 'customer rating' and use it to give different prices to different customers. This 'rating' is based on order history, so it is obviously related to the customer. Has your customer the right to have this information exported? Or to even ask you to transfer it to your direct competitor? I don't think so. This is your information, generated by your sophisticated algorithm. Why should you tell your competitors how much you think this customer is worth? Your customer has the right to transfer his data to other controllers - he should get everything he provided. Be we don't need to give him anything else. We can, of course :)

@nickon I'm not sure if there's a need for this. Article 20 says that The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller. Send Review Request does not store any data provided by user. It just logs information an email has been sent to customer with given ID.

That's true, models with namespaces won't work on ps16. In this case it's not important, as Send Review Request module does not use namespaces. @nickon - just edit file sendreviewrequest.php, and remove highlighted lines if (!defined('_TB_VERSION_')) { exit; } And it will work. This trick will not work on krona module, though, as it uses namespaces

@toplakd I've never said that the updater project should be scratched - I'm sure tb is somehow bound by contract with indiegogo to deliver the promised goods. I was asked why I think this is overkill, so I answered. If you disagree with me you are welcome to raise your counter argument

@lesley said in Thirtybees roadmap: Saving time is the only way we are going to get ahead with a small team. We have to look at our processes and refine them to cut the fat out. Two months ago if we decided to release a new version with an update we would be looking at 10-15 hours of work. Now we are looking at around 8. Once we get the updater finished we will be looking at 10 minutes worth of work. That is 9:50 that can be spent somewhere else. Of course I understand the benefits of updater, it's definitely a good thing to have. But I still think it's not needed at the moment. How much time will it take to build this? I assume at least 200 hours (and that's conservative estimate, considering all the features listed on the blog post). So you'll start saving time after 20 releases. If you will release every 2-3 weeks, you'll break even in a year. Is such high release rate good? As I already wrote before, I don't believe merchants will update their store so often, it's too risky. You don't have a QA team that would run tests and sign off the release. Also, with this high release rate, the submitted code won't have a chance to mature in the branch - your developers won't have so much time to discover new bugs before the release. It's much more likely that bugs will make it to end users. I personally think that 2-4 releases per year is more than enough. And with such release schedule it wouldn't make sense to invest so much effort and resources into an updater. That's why I think that the updater is an overkill. But this is just my opinion. As far as a rough roadmap, this is what we have discussed so far, but nothing is set in stone yet. 1.0.x - just bug fixes 1.1.x - modernize the front end, convert to bootstrap 4 and have a new theme 1.2.x - modernize the backend, convert to bootstrap 4 and have a new theme Thanks. Maybe it would be good if you guys selected some feature candidates, and let community decide/vote what should be implemented. Possibly let only patreons vote - that would be nice incentive for becoming one.

@nickon said in Thirtybees roadmap: @datakick I would really like to hear your opinion on why the updated is overkill. Because if it is maybe @lesley and @mdekker could use the time/money to build something that is more usefull. Sure, why not. I believe that serious merchants don't need new release every two weeks. That's way too often. We have to remember that this is legacy codebase - Prestashop/Thirtybees source code is big bowl of tangled spaghetti, and every change can cause some bug. So every release is a potential thread, and should be accompanied with thorough re-test of your shop (or at least basic functionality). I'm sure that most merchants that has been running ps/tb for a few years has already experienced some issues with version upgrades. It can be pain, especially when you have many third-party modules. It's tolerable when you are upgrading your shop every 6 month - you just close your shop, and dedicate one weekend for upgrade and thorough retest. But I'm pretty sure most merchants wont be undergoing this task every two weeks, or every month. I think that stability is what merchants value the most. I can see them using this new updater on their dev/test sites to test new codebase. But how many merchants have test sites? From my perspective it's more than enough to release new version once every 6 month. I understand that manually create release can be time consuming -- but how much time can it take, really? Maybe a day or two. How much time will this new updater take? Just my 2 cents... very possibly I'm completely wrong in my assumptions :)

@traumflug said in Thirtybees roadmap: v1.0.5? That’s later this month. There will be a module validator. Maybe some people noticed it, the v1.0.4 release wasn’t as seamless as making a release should be. All the module and theme upgrades got forgotten, even the already distributed ZIP file had to be corrected. So I started an effort to make not forgetting such things much easier. Probably this sounds boring to many, it doesn’t change much to the merchant/customer experience. Still I consider this to be important, because a successful project needs a strong foundation. Thanks for info. Module validator is definitely useful and needed functionality. But it's not a feature, it's a build tool. And that surely doesn't require a release. Anyway, I'd really like to know if there is some sort of short/mid/long-term plan, to see the direction this project is going to. Should we expect mainly bug fixes, or are there some features on the table as well? If so, how are the features prioritized / who decides what will be worked on? How many resources do you have at your (company as a whole) disposal - are we talking about 10 hours a month, or is it 200 hours/month? I understand that you are doing this for free, and that we (community) are not entitled to anything. But still, if you want this project to succeed, you need to commit to your vision and be accountable for it. Otherwise you won't be considered as a serious partner by most merchants (or other developers)