datakick

seriously guys, why should we even care? This is one request per hour, and that's definitely wont hurt your server - just compare it with one page load of average visitor - that's like 20-30 requests and hundreds of sql requests. If you ask me, this cron service is one of the nicest gesture prestashop as a company ever did. Granted, it's not perfect and it's very buggy - but hey, we can say the same about ps codebasem and we are using it daily. This service removes barrier to entry significantly, as it allows for scheduled tasks out of the box. There are many merchants who doesn't understand how cron works. and software shouldn't force them to learn about it.

@vincentdenkspel do you have SPF and DKIM set up properly? My suggestions is to outsource sending emails to third party service, such as mailgun (I personally have great experience with them). You could: create a dedicated subdomain for transactional emails, such as mail.yourdomain.com (you can still send emails from whoever@yourdomain.com using this subdomain). Don't send any other email using this subdomain (for example, if you have mailchimp, create another subdomain for it) sign up for mailgun, or other similar service for transactional email. set up SPF and DKIM dns records for this subdomains (they'll guide you) use their smtp service to send emails from your server. Alternatively, you can set up email server on your vps as an email relay - your local email server will forward emails to mailgun smtp server. This will help in case mailgun smtp is down (very unlikely, but it happens) These service providers are very good at delivering emails. They know all in and outs, and it really shows. They employ special algorithms, such as email validation, advances queuing, and scheduling, they have fallback mechanism for bounced emails, etc... in short, they make recipient's email servers very happy, and thus gradually increasing your mail reputation.

@bocua try it and let us know

I've released a new version 1.0.12. This version http requests uses CSRF security token to protect against cross site request forgery attacks. It's a very important from security point of view, so revws module won't be abused for sending spam. CSRF is good enough protection against most of the dumb/blind bots. But I plan to implement captcha as well, so even more sophisticated bots won't have a chance added option to check (automatically or manually) for new version of the module added support page with links to this forum topic as an official discussion board (so hopefully that will bring in some prestashop users), and a few other links to modules that cooperate with revws - @SLiCK_303 's send review request, @wakabayashi krona module, and of course my very own datakick module.

@slick_303 you are right, it's the same action from database perspective. Both actions will mark review as deleted. The difference is not what happened, but who has performed the action. When it's review author, the action is Delete review. When it's administrator, the action is Reject review. This distinction is important, so I know what emails to send. Regarding real delete - I plan to implement filtering into backoffice review list. The list will, by default, hide all delete reviews. But it will still be possible to show them. So this will partly solve this nuisance. And after that, I'll maybe implement real delete function. But it has very low priority.

The looks amazing

I've released new version 1.0.11. This version brings better integration with datakick and krona modules. And it also let you import yotpo reviews

@manisch this really seems like some data integrity problem caused by botched data import. I'd guess data from different tables were incorrectly paired, possibly referencing non-existing documents. I could have a look at your data to confirm this, but it probably won't help you much. It would be hard to fix the data in place - it's probably better to do the import again.

@cassim said in Setup mail delivery + modules: And you think this will work. Or will that just show if they have open for that port. ? that's just verifies whether port 25 is open or not. It should display this: Trying 104.199.96.85... Connected to in.mailjet.com. Escape character is '^]'. 220 in.mailjet.com ESMTP Mailjet

@cassim than it's most probably your server configuration fault. You should contact your hosting provider, and ask whether they block ports 25 and 465. Alternatively, if you have ssh access, you can connect to your server and try running command telnet in-v3.mailjet.com 25

@cassim have you tried to set up the same smtp configuration in some email client, say thunderbird? If it's not possible to send email with this configuration even from thunderbird, then it's an issue with mailjet. - you have either used wrong server, username, password, or encryption method. - if you are sure you've entered the right connection info, then contact mailjet support - problem must on their side. If you can send email using this configuration from thunderbird, then it's an issue with your server configuration. For example, there may be some firewall blocking communication with stmp server.

@vincentdenkspel @30knees not yet. Amazon integration is in backlog, but I still haven't got to it

I don't understand what the problem with mailjet is. You shouldn't need any module to make it work. Just switch email sending method in Advanced Parameters > Email to Set my own SMTP parameters (for advanced users ONLY), and fill in mailjet smtp server information. The credentials are your $MJAPIKEYPUBLIC as a login and $MJAPIKEYPRIVATE as a password. You can find your SMTP credentials in your Account Setup page.

just FYI, I've added this module to the store. I'm not going to create a separate forum thread for this module, but if anyone has feature requests feel free to create one

New version 1.0.10 has just been released. This one fixes some css caching bugs and introduces new hook called displayRevwsReview You can call this hook anywhere in your theme to show specific review. As an example I'll show you how to add featured review to your homepage: edit file /themes/yourtheme/index.tpl and add something like this ``` ... Featured review {hook h='displayRevwsReview' review=2} ... ``` You can customize the review layout a bit by passing these parameters - review - id of a review to display. This is required parameter - displayCriteria - how to render criteria breakdown. Expects one of inline | side | false values. Default value is the one set up in your settings. This is optional parameter. - displayReply - if we should render shop reply (if exists). Expects either true or false. Default value is true. Optional parameter example: {hook h='displayRevwsReview' review=2 displayCriteria='inline' displayReply=false}

I've just tried your configuration on my test server and it works just fine. Well, what strange is that there's a typo in gzip_min_lenght that needed to be fixed first, otherwise nginx failed to restart. How come your server managed to restart with this typo in config file? Is the nginx-gzip.conf file actually included ? And did you actually restart nginx to reload settings?

try to set gzip_http_version 1.0, or alternatively gzip_http_version 1.0 - this could help, according to this article

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