datakick

@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

@SLiCK_303 - I've added zip file to release. Regarding php 7.xx - I couldn't reproduce this issue. Everything seems to be working ok on my 7.0.11. What version exactly do you have?

I've just released a new version 1.0.6 - this one get rid of inline styles we have discussed with @zimmer-media. This version introduces breaking change - if you copied front.css file to /themes/<yourtheme>/modules/revws/revws.css and modified it, it will no longer be used. To make changes to CSS, please create file /themes/<yourtheme>/modules/revws/views/templates/front/css-extend.tpl and enter your css changes here. Content of this file will be appended after content of file /modules/revws/views/templates/front/css.tpl. CSS priority rules will make sure definitions in css-extend.tpl file will have priority over default values from css.tpl file. You might have notices that the css file(s) has .tpl extension - that's right, this is normal smarty template, we just generate css instead of html markup. Generated css file is stored in you theme cache directory. Example of how to extend CSS styles - create file css-extend.tpl with following content to have your stars in red color .revws-grade-on path { fill: red; stroke: red; }

@zimmer-media said in [Free Module]Revws - Product Reviews: Despite the great module, you will be devalued by these many additional inline styles by Google. Google doesn't care at all if we use inline styles or css. What is important for them is page load and render time. And very often web pages with inline-styles only can easily beat css powered ones. Simply because there's no need for additional css fetch, and browser can start rendering the page even before it is completely downloaded and parsed. That's not possible if page contains css. But, obviously, inline styles impact page size, and that in turn impact load time. So it will have some negative effect. In our case we are talking about two inlines styles per star: style="padding-left:2px;padding-right:2px" and style="stroke-width:50". So we have extra payload of 325 bytes per review. If we have 20 products block on page, we will have to transfer extra 6k. But since everyone is using gzip, this will be greatly reduces to ~1k (gzip is great for repeating texts). With current speed of internet, this amount of extra data won't even register. We are talking about microseconds here. Compare it with size of all the retina images you have on your page... I agree it would be nice if I didn't have to emit these to page. Why don't I use css here? That's because we couldn't adjust theme from settings page. For example, star size option (and in the future fill and stroke colors, spacing,...). If these properties were hardcoded in css, we couldn't change them from ui. For example, try change star size with your revwspaddi class in place. It will not scale nicely, as 2px padding is too small for large stars. My module is targeted to ordinary users/merchants, not power users who knows how css works. And with that comes the price :) Note: maybe in the future I'll add some option to dynamically generate css files when theme options are changes in settings. But at the moment it has very little priority.