datakick

@troy-roberts it uses standard prestashop Mail::Send(...), so it will use whatever transport you have set up. In case it fails to send email there should be an entry in log with some informations, look into Advanced Parameters > Logs. It's usually due to missing email translation.

@SLiCK_303 is it really responsibility of review module to auto log-in customer? I'm not sure, but I'd say this should be handled by module that generates the review link. You don't have to send visitors directly to product page. You can create some controller that will perform auto-login, and then redirect visitor to product page. Obviously, this is very sensitive topic, as it involves authentication

@wakabayashi it's still under development. Unfortunately I haven't had much time to work on this lately as I'm very busy with freelance project right now. As I can't devote as much time as I would like, the progress is very slowly. The first version could be released in (maybe) 1 week. But no promises.

new version 1.0.4 has been released that fixes this z-index bug

On product page review js is loaded asynchronously, and that might be the reason why it does not fire. Try this one, that should work if (window.location.hash.indexOf('post_review') > -1) { var action = { type: 'TRIGGER_CREATE_REVIEW', productId: id_product }; window.revws ? window.revws(action) : window.revwsData.initActions = [ action ]; }

@SLiCK_303 any js error in console? Also, have you tried the other approach, to direct your visitor to the My Reviews page?

@slick_303 yes. Alternatively, you can direct user to this url https://www.domain.com/en/module/revws/MyReviews?review-product=<productId> Review dialog will be opened automatically, and you don't need to make any changes to hookHeader at all.

@SLiCK_303 you can try this javascript snippet: $(document).ready(function() { if (window.location.hash.indexOf('post_review') > -1) { window.revws({ type: 'TRIGGER_CREATE_REVIEW', productId: id_product }) } })

I haven't tested it, but I think it should be enough to edit hookDisplayHeader, and add this line at the very beginning of this function: if ($this->context->customer->isLogged()) return;

@wakabayashi said in Planned Free Module: Loyalty Points: ...but it’s just a symbolic reward. If an user reaches certain amounts of points, he will become a “super ninja” If you associate levels with customer groups, it can be much more than just symbolic reward

@manisch in the first post you wrote that your subdomain’s root-folder is the same as the main-domain’s = “/httpdocs”. So there shouldn't be any copy error :) What does your console/network tab says? Is it 404, or other error?

You will need to set up CORS policy on your server https://github.com/fontello/fontello/wiki/How-to-setup-server-to-serve-fonts

@wakabayashi that's good, but I would recommend to refactor the first hook. When should other modules register actions? During their installation? That introduce dependency on module installation order... If user first install revws, and then your krona, they wouldn't be linked. I suggest you reverse it. Instead of registering, use dynamic discovery. So, when user opens config page of your module, your module will trigger hook actionDiscoverKronaAction. Every module in the system that's krona-enabled will be reply with their actions. The code will look like this: $modules = Hook::exec('actionDiscoverKronaAction', [], null, true, false); if ($modules) { foreach ($modules as $key=>$def) { // $def contains actions defined by module with key $key } } I'm actually doing something very similar in my new module mailstream, that will be used for email automation. I'm using this technique to discover review modules in the system.

@Generaal, do you have debug mode enabled? If so, please turn this fu***g functionality off. It screws everything

@wakabayashi awesome. I assume one of the hooks you've mentioned will be there to discover all available rewardable actions in the system, and the second hook to inform your module that the action actually happened? Or do you have some other mechanism in mind?

@generaal said in [Free Module]Revws - Product Reviews On the review in FO, there don't come up some options to give some information on the review, after placed and approved the review. Options to vote/report abuse are available only for other visitors, not for review author. Review author see edit/delete review buttons instead. When I tried to delete some reviews in BO, I have to click serval times to change some settings and it's not possible to delete them even. I don't understand what exactly the problem is. Do you mean that the app does nothing when you click on delete button, of on review itself? If so, what browser do you use? Also, it's not possible to permanently delete review, you can only mark it as deleted. I'll add an option to permanently delete them in the future, or even better filter them out of the list. I'm not a big fan of permanent deletion

@Manisch I would need to see source code of the module. But I believe that the line you've mentioned starts with something like this: $this->context->controller->addJS(.... You will want to remove the whole line. Next, search for text 'google.maps' in *.js files of this module... and get rid of all references to google maps api... somehow...

also, if your server is on 2-level domain such as http://domain.com, then it will have no effect if you set up static server on subdomain, ie static.domain.com. Cookies will be shared. Cookieless request will be only if your primary server is on subdomain as well, ie www.domain.com

Did you clear cache? This feature doesn't have big impact. The http requests are still routed to the same server, the only difference is that these requests don't contain cookies. Which can save few hundreds bytes per request. It would be much more interesting if there was a mechanism to transfer static context to different server (say amazon s3), and when everything is synced then turn this media server automatically. It's probably hard to implement, because the static context in tb is not that static :)

@manisch that's not a good solution. This will probably create script tag in your page like this: <script type="text/javascript" src='httpen' /> that will result in http request to your domain, ie: http://www.domain.com/httpen. Request will return 404 not found, and you'll get error code in your console. Immediately after that you will find another couple of errors related to missing google maps library, because javascript code that utilize this library is still present...

@generaal, there a bug in json module. It tests whether productcomments module is installed, but it doesn't test if it's also enabled. So either uninstall productcomments completely, or set up json module to use different review module. From the code it seems like this should be part of configuration....

@lesley I don't think we have to complicate this by reserving urls, etc... the history log doesn't even have to be unique. Just find out which product used this link-rewrite last, and display that one. I'm sure this simple mechanism would display the 'right' product 95% of the time. I believe conflicts with link rewrite would rarely happen. And even when there's a conflict and we display different product than to which link originally point to, it's safe to assume this new product will be similar. It's definitely much better than showing 404, that one only cause bounce.

@lesley I think we are talking about two different things. I believe you are talking about changing schema or urls / routes under Preferences > SEO & URLs. I'm talking about changing link_rewrite on product page. I'm not sure which problem @30knees originally talked about.... Now, I also think it doesn't make any sense to automatically fix url when route schema changed. That would be crazy, and we would indeed have to use htaccess fille. Moreover, it's also not very important issue because no sane merchant will ever change routes on running shop with some history. But they can, and often will, change friendly url on individual products. At the moment, when you change friendly url on product, any link to this product will stop working. For example, I've changed friendly url on Candle to candle-1 -- url changed to /en/gifts/candle-1, and original url /en/gifts/candle now returns 404. Prestashop doesn't have this problem because they rely on product id as a primary identifier in URL, so they can change friendly urls how many times they want. It would be very easy to fix this issue. We just have to remember history of friendly urls for each product, and use this info when we can't find product. Performance impact is none for happy path, and only a single sql query for historical url. But added value is huge.

@davidp I disagree. First of all, table with 20000 records is not a big table, especially when it contains 2 columns only (product id and original url / link rewrite). This mechanism wouldn't have any negative performance impact on 'normal' page load, as it would be triggered only when product can't be found. Also, there can't be any redirect chain, only one redirect to current product url. Actually, we don't even have to do the redirect, we could simply render product page with canonical url meta tag in the header.

modules have their own repositories, these aren't really related to tb version at all. I was talking about fixes in the core