datakick

I don't think it's possible at the moment. Thirtybees sanitize html input and removes every weird markup, js, css,... You can create enhancement request on github for this, though

Are you sure this product has associated review? Because it seems to be working correctly -- when I go to any product from all-reviews page: https://www.librairiezbookstore.com/en/reviews?module=revws Also, revws module can be set up to filter by current language. For the product above, there exists one review in French. When you see product in English, no review is shown. You can disable this in module settings page, and then reviews from all languages will be displayed.

@DaoKakao you must be using old preview version. This module is now called coreupdater, and this line is no longer part of it

Hi @rubben1985 First of all, thanks for your effort, it's really appreciated. Unfortunately, I don't think that these changes will make it into the sitemap module. Why not? Because it introduces explicit dependency between modules. With this change, sitemap module now *magically* knows how to access *stblog* module's data. But only *stblog*. if we install any other blog module, then its data won't be accessible. Moreover, these changes access stblog module tables directly. That's just wrong, because it hardcodes information about other module's table structure. What if the author of stblog module release new version with different table structure? Such change would break this integration, and possibly bring down the whole shop. We try hard to eliminate these kind of explicit dependencies from core, and core modules. And it's quite easy, that's what hooks are for. And sitemap module already executes hook named gSitemapAppendUrls. Any module that wants to append its data to generated xml file can register this hook, and use it to provide data during runtime. This is much safer. It is also standard hook (kind of). It's used by both sitemap and gsitemap modules, and it's already supported by number of blog (and other) modules. For example, standard tb blog module already uses this hook to provide data. I think the best way forward would be to contact stblog developer, and ask them to implement gSitemapAppendUrls hook. That will immediately make stblog module compatible with both sitemap and gsitemap modules, without any need for their modification.

It's not that bad. You have probably installed some older module that overrides Link::getImageLink() method incorrectly. What you can do: 1. find out what module is responsible for this (you can install override check module to do that) 2. edit override file, and fix the method signature to match look like this: getImageLink($name, $ids, $type = NULL, $format = 'jpg', $highDpi = false) 3. if the override function calls parent::getImageLink(), then make sure you pass all the parameters That's it

You are correct. Those modules were not marked as uninstalled, so thirtybees still think they are there and active. You can delete them directly from db, if you are not afraid. It's table tb_module. (and possibly tb_hook_module) It would be nice to have some consistency check for these system records.

When you open javascript console, you'll find out this: Geocoding Service: This API project is not authorized to use this API. For more information on authentication and Google Maps JavaScript API services please see: https://developers.google.com/maps/documentation/javascript/get-api-key

When some error occurs, thirtybees tries to log it into file. But in your case, because of incorrect directory permission, it's not able to create file in /usr/share/nginx/html/log/ directory, thus failing with this warning. And we don't know the root cause of this problem, because the original error is lost. So, first of all, fix the directory permissions so it's writable. Then test again, and let us know what error message appears in the error log.

I believe this is fixed in upcoming version: https://github.com/thirtybees/thirtybees/commit/8e89acf9061e88bc106658891c8bd5abb83eeb9c#diff-f44483a142f09ca47bd59224eb070bfb

In this case there's no hook available. The only way to disable this functionality is using override. Because this is thirtybees-only functionality, NONE of the existing seo module comes with such override. They don't need to, because ps16 does not have this feature. What that means for merchants? It means that in order to use any of these seo modules, they need to modify them first, and create php override file. Or manually create override file. Or modify core... Now, isn't it easier to simply turn this feature off, and then install module that do this particular thing better?

It does

It's simply not possible to implement feature like this and cover needs of every merchants. The default implementation is pretty solid, and meets the requirements of almost everybody. But then there are few use cases when it doesn't. I know about two already: - multistore / one store per language setup -- if we wanted to support this in the core then it would actually require quite complex configuration page, and that would definitely not make things easier to setup... and no, it's not really possible to resolve this automagically / algorithmically. Some user input is required here - custom canonical links / relations between different products - I remember there was some thread asking about this recently. Somebody wanted to group similar products under one canonical product umbrella to avoid duplicate content penalisation. Again, if we wanted to have this in core, it would require quite an extensive config page And I'm sure there are other scenarios when the default implementation just doesn't work out of the box. But what's worse, it actually blocks merchants from implementing alternative. When you install any seo module, you will get conflicting metadata in html markup, and that can actually hurt from the seo perspective. That's why it's definitely good to have an option to disable this default implementation.

Third party modules, mostly. Since ps16 does not have this, there already exists many modules that implements this functionality, and then some. It makes sense for some merchants to turn the default implementation off, and use this 'advanced module' implementation instead. Anyway, I think it's a good strategy to have features hidden behind a switch (and they already usually are).

I believe @lesley is planning to move away from patreon to some different solution. What exactly is not 'handy for business user' ?

There are multiple commits [ 1 , 2 , 3 ]related to this, you'll need all 3. Then you get this:

The fix for this, including new back office switch, is scheduled for the next release. @Smile there's no need to sponsor individual fixes, especially when they are trivial 🙂 But feel free to join patreon program (if you haven't already), that's always appreciated!

The bug that was causing 500 error code was fixed, so Full Page cache should be usable in the upcoming version. Note that by default every hooks are non-cached, so when you turn it on, you might even experience some slowdown. To get the benefits of FPC, you will need to turn on caching for hooks that *you believe* should be cached. And this is the hard part -- nobody knows if the hook has some side effects other than rendering the output. If it has side effects, turning caching on will break stuff. So you need to be very careful, and test everything.

Tracked here: https://github.com/thirtybees/thirtybees/issues/848

It is a bug, but it's also very specific. You need to have multistore enabled, and distinct set of languages used by each stores. With this configuration, tb will indeed emit alt links for languages used in other stores. This should be fixed. Should thirtybees emit alt link for different store? That's questionable. Probably not, imho. While it would make sense for your specific use case, when you use multistore as a language selector, it would not work in general. Especially when stores have their own products. I also agree that there should be a switch to turn off this feature, and a hook to alter alt links just before they get rendered to the html.

The auto-login functionality exists only in premium version, and it's tied up to email record. Every sent review request email is tracked in database, and it includes private security key needed to perform the auto login. I've tested on my environment, and image aspect ratio is maintained correctly. I've tested with image sizes 150x300 and 300x150, and in both scenarios the result was ok. It's possible that you have modified/outdated revws css, or that some other css is applied to review list as well.

Another free version 1.0.23 released Enhancements Issue 86 - custom placement for review average - you can now position stars/ratings widget anywhere on your product page. For example prominently below product title Issue 97 - added shortcuts from settings page to reviews, import, criteria pages Issue 100 - added configuration option for number of reviews to be displayed on all-reviews / my-reviews page Issue 48 - you can now edit review date from back office Issue 47 - review lists can now be filtered by category and brand. Bugfixes Issue 90 - fix pagination problem that occured on some versions of MariaDB without proper support for SQL_CALC_FOUND_ROWS Issue 96 - fixed overflow problems with long review content Issue 20 - read review link now works in quick view Issue 99 - don't filter reviews on my-reviews page by selected language Tip and tricks Try adding this short snippet somewhere into your smarty template. It will display product reviews associated with category 4 {hook h='displayRevwsReviewList' category=4 }

what do you mean change the classes/tools.php ?

I believe that new core updater module handles database migration as well: https://github.com/thirtybees/coreupdater/blob/e58130881076265a0bc1a

That's correct. It's stupid, isn't it 🙂

You need to run your store on https