datakick

your nginx (reverse proxy?) server is probably not configured correctly. You can read more about this here. Note: If you use nginx in front of apache server then you don't need to have mod_deflate enabled on apache at all. That will have negative impact on overall performance. Let nginx gzip this instead.

Thanks @Kleijn36, very much appreciated. I've merged your pull request, and it will be part of the next release.

wow, what a storm. I was away this weekend, and I'm really sorry I've missed it. It seems quite late to join in now. So I just say that I really hope that the community will heal quickly. Thanks @lesley for the blog post, it really reinforces the faith in the project. I sure hope you'll continue to inform us on regular basis, to prevent this kind of situation from happening ever again. I know it takes tremendous amount of time and energy, and I very much appreciate it.

@nickon said in Suggestion to generate more income for TB: Too much emphasis is giving as a ps fork. I disagree with this statement. I think it's very unlikely that new merchants will choose thirtybees over prestashop. First of all, they will not discover it at all, as there isn't any marketing in place. And even if they come across 30bz, why should they choose it? It's a new player, with very small community, and no guarantee it will be here for upcoming years. And I also agree with @rubben1985 's post about landing page not selling benefits enough. On the other hand, there is a huge crowd of ps16 merchants who are reluctant with migrating to ps17. And I think attracting this crowd is a key to success. Unfortunately I don't think 30bz is doing a good job here. Here's my 2 cents 1) stop talking about 1.1.x version. In fact, drop this from roadmap completely. ps16 users don't want to migrate to ps17. Why should they migrate to thirtybees if there's a vision of yet another, potentially hazardous, migration ahead? Why would anyone think tb 1.1.x will be better than ps17? We should focus on stabilizing 16, and that's it. Give merchants some piece of mind. 2) don't force merchants to migrate to 30bz. This is strange, but I think it's important point. For example, all modules for 30bz are not compatible with ps16. Why? Why not make them ps16 compatible, and use them for marketing purpose? Make them available for free on prestashop forum, and lightly mention it's primarily made by, and for, thirtybees. Merchants running 16 stores will be happy to see there's still someone investing in creating modules for their version of software. For many of them, this will be the first time they actually hear about 30bz project. And when the time for migration comes, there will be bigger chance they will decide for 30bz instead of ps17. 3) make an EQUAL sign between ps16 and thirtybees, and officially provide support for both platforms. Obviously, solution for many support requests by ps16 users will be to upgrade to 30bz. Most important is that ps16 users has to know that they can seek help on this forum if in trouble. I'm sure they'll fell in love with the community shortly. Also, if they are looking for ps16 module, they should think about thirtybees store first. 4) provide frictionless upgrade service. If the ps16 merchant decide to migrate, they mustn't encounter any bug or issue. Period. In fact, I'm thinking about providing this service myself... I think we should focus on building community around the idea of thirtybees. The actual numbers of stores running thirtybees is not important at all. The installations themselves do not generate any money. But the community can, and will.

@wakabayashi could you pm me your test server url?

@dosbiner you are correct, but I think the main problem here is to keep webstore stock up to date with all 10 systems running on physical locations. @Bodegadelibros noted that inventory changes a lot, and he probably want to perform online check at the purchase time, instead of perform regular inventory sync.

@SLiCK_303 @movieseals - robots.txt standard technically does not recognize asterisk as a wildchar. So, if some bot implemented robots.txt handling strictly according to specification, they wouldn't understand your directive and could actually follow the link. Google, Bing, and other major players support this kind of extension to the standard, so they will process it properly. But I think it's safer to use Disallow: /blackhole/, or even Disallow: /blackhole to be sure no bot with good intentions will be caught in this trap. Basically, this directive means that any url starting with /blackhole/ is prohibited from browsing. Your (nonstandard) directive says that any url containing /blackhole/ is prohibited.

hmmm, it doesnt work for you because of missing slash at the end of the url. I’ve fixed this bug, download new version from previous post

@slick_303 did you actually enter the url address? You can try it on my demo account. After you install module, view source of your page to see if there's trap link: And when you enter this url, you'll get error message.

there’s no need for this dir to exist at all

@slick_303 yep, it's already fixed. Download new version from my previous post

Here's the module. To use it, you need to 1) install it 2) edit robots.txt and add following lines User-agent: * Disallow: /blackhole/ That's it. Module will add hidden nofollow link to blackhole destination to all your frontend pages. Any well-behave bot should ignore this link (if you have correctly set up robots.txt). Bad bots will eventually open this link, and they'll immediately get banned. You can try its functionality yourself by navigating to www.yourdomain.com/blackhole/ address. Your ip address will be added to blacklist, and you won't be able to access the site anymore. At the moment there isn't any mechanism to remove address from blacklist - you'll need either reset module, or directly remove record from db table PREFIX_blackholebots_blacklist blackholebots.zip github link

I'll re-wrap this blackhole functionality into tb module, so if you just wait a couple hours...

I've just released new version 1.0.9 which includes couple of bugfixes, and 2 new features: Verified purchase - review has new boolean field named verified_buyer. This will be set to true if customer really purchased product associated with review. This is determined at the time of review submission - there must exists already shipped order. This means that reviews submitted before product purchase will not be marked as verified. Administrator can check/uncheck this field from back-office. Verified purchases are highlighted in review list. Criteria breakdown - If you use multiple review criteria, you can now show them on review list. You can choose on of the 3 ways to display criteria breakdown. Don't show criteria breakdown at all -- this is current behavior, only average ratings is shown Show criteria on top, in single line separated by divider Show criteria on right side

@movieseals the idea behind blackhole bad bots mechanism is really very clever. It shouldn't be hard to implement this as a tb module.

@chandra I believe this is CCC bundle

@chandra that one's not generated by my module

@chandra sorry about that, I forgot to remove code that forces new css regeneration. Please edit file revws.php and delete line #464: $data .= time(); You can safely delete all revws-**.css files from cache directory. The easiest way is to clear cache from Advanced Parameters > Performance

@drmasterchief that's correct behaviour. These rows are linked using id_reference column - there should be only one active row for each id_reference. Every non-active row in this table represents a historical state / settings, and are linked to from orders / invoices. So, even if you change your shipping rates, your orders are not affected.

@Luv verified purchase / buyer will be in upcoming version of the module. I've already implemented it, but I want to test it a little bit longer, because this release requires database change. You can test it on my demo account - front / back

Since I have a little bit of a free time this week, I decided to implement another feature to this module. Since version 1.0.8 you can change star color from settings page.

I've released new version 1.0.7 - this is a bugfix - I've forgot to include txt email templates to previous module builds. This resulted in not sending emails.

@Troy-Roberts if the popup does not show, there's probably some javascript error. Could you send me url of your shop so I can have a look? Regarding emails - do you have email templates translated to your language(s)?

@slick_303 I didn't have smarty cache enabled before. When I enabled it, it started doing exactly the same weird behaviour you've reported before. With the fix it seems to be working.

@SLiCK_303 I may have found the problem with smarty cache. Could you please try it on your end to verify it's working - simply change line ~326 in revws.php from return $this->display(__FILE__, 'product_list.tpl'); to return $this->display(__FILE__, 'product_list.tpl', $this->getCacheId() . '|' . $productId); Then clear cache. Let me know if that helped