datakick

Thirtybees does not have such thing as a text attribute. All attributes values *MUST* be defined in back office, se they can be used when specifying your combinations. Text attributes would, by definition, be created by your end users. There is, however, Customization option. You can create text fields (or file fields) and allow your customers to customize the product. Unfortunately it's not very flexible, for example there isn't any price impact, etc... If you need these advanced features, you'll need to purchase one of the many Product Customization modules out there. There are indeed great variety of these modules, I'm sure you'll find one that will meet your needs. Some of them are quite cheap as well

@lovelygifts try to turn off friendly url for a few minutes and look at your site without it. I believe the problem could be here. For example: image url with rewrite does not work: https://lovely-gifts.co.uk/844-large_default/image.jpg image url without rewrite works: https://lovely-gifts.co.uk/img/p/8/4/4/844-large_default.jpg

If directory permissions are OK, then it's probably issue with image misconfiguration. Please go to Preferences > Images and have a look at defined image types. Verify that image type large_default is there, and it's enabled for Products.

You can disable edit in settings page Usually everyone should leave at most one review, but I can see some use cases when multiple reviews would be beneficial -- for example for customized products like T-shirts with custom design. In this case, multiple reviews (with images) would really be nice to have. I'll investigate how hard it would be to allow this

Module doesn't seem to be installed / enabled at all. Please check that 1. module is enabled 2. check that option Advanced Parameters > Performance > Disable non thirty bees modules is not enabled

Could you share your show url?

Every product can have multiple suppliers, so there's no one reference. Also, every combination can have different reference as well. So, in general, you'll get supplier reference matrix. This code should help you start, put it somewhere into your product.tpl: <table class="mt-4 mb-4 table table-striped"> <thead> <tr> <td>Id supplier</td> <th>Attribute</th> <th>Supplier reference</th> </tr> </thead> <tbody> {foreach from=ProductSupplier::getSupplierCollection($product->id|intval, false) item=sup} <tr> <td>{$sup->id_supplier}</td> <td>{$sup->id_product_attribute}</td> <td>{$sup->product_supplier_reference}</td> </tr> {/foreach} </tbody> </table>

Are you using standard template? Some themes does not implement all hooks on product page.

Yes, 2.0.4 is the latest version. There is no auto-login setup, it just works. Every email send to customer is logged in the table with a special security code associated. Link to review contains this security code, and it is used to authenticate customer automatically. Well, the more strict consent level you choose, the fewer email requests will be send. This is really up to you to decide what's correct for you and your country. For example, in my country (Czech Republic), no consent is required at all. Our state agency issued an official statement in which they confirmed that merchants have legitimate interest in collecting responses in order to maintain high quality service, and as such no opt-in is required. Merchants must, however, inform about these emails in their TOS and privacy policies, and offer opt-out. This basically means that review requests emails are on the same level as normal transactional emails associated with order. It's possible that in your country state regulator has different opinion about this. But you can always modify the email template and *mask* it as normal transactional email. Something like this: "We are sending you this email to let you know that your order at OurStore has been completed, and no further actions are necessery. You can download your invoice here and there... Also, please review your product here :)"

Every piece of data thirtybees send to paypal is subject to very strict validation, even if it's optional. When it fails to validate for some reason (wrong postcode, country code, different rounding), then the whole transaction is rejected. This was one of the reason why old versions of paypal module did not work for some merchants. The solution for this problem was to send only required information, and scratch everything optional. It is not the best solution, but it's the simplest and it just works.

Fixed in community theme. Unfortunately this will not fix any theme based on community theme, ie. niara.

Quite the opposite, actually. When we make a sale, we always have to make a snapshot of the base information (product price, name, tax settings, shipping settings, etc...) so we could work with the order/invoice later, even when these changed already. In other word -- when you change the product price or shipping settings, your current orders and invoices can't change. The big problem is that the bulk of the calculation is performed in Cart class, and then cart is just converted to Order. That works good for front-office, but it's a terrible situation for back-office. There are few things we can do: - duplicate the code from cart to order and adjust it. This is recipe for disaster, as we would end up with two similar implementations tackling the same problem - create new / temporary cart when modifying the order - this is how it's done now, at least for adding new products to order. While it may sound like a good idea, it's really not. Cart work against current state of the database, but that's not what we want when updating order. We want to use historical data (product price valid at the time when product was originally ordered), we don't want cart to check available quantities for some products, but we would like to check quantities for products newly added to order,... It became real messy very soon. The proper solution would be to extract the business logic from cart, and make it reusable by both cart and order. But that's very hard and dangerous refactoring. I don't think this will be tackled anytime soon

How could that have any effect on sending, or delivering email? Worst case scenario - the email will contain order reference placeholder not substituted.

To make it work, all you need to do is to delete this entry from configuration table: DELETE FROM tb_configuration WHERE name IN ('PS_STATS_GRID_RENDER', 'PS_STATS_RENDER') AND value = 'statsmodule'; The core code will be fixed in one of the upcoming version

Reprosteps: Go to Statistics > Best categories During installation, statsmodule class is registered as default grid renderer. But this class does not implement hookGraphEngine. And it also does not extends ModuleGridEngineCore class as well, so it can't be used as a renderer at all. The fix should consist of: 1. fix the configuration key (drop it completely) 2. add additional checks to ModuleStatsCore::engineGrid to ensure grid engine implements hook,... or even better, drop this nonsense and call hook in standard way 3. add additional checks to ModuleStatsCore::createGrid to ensure grid engine implements ModuleGridEngineCore interface ... and the same for *Graph

This js script makes sure that IntersectionObserver functionality can be used in all browsers, and not only by those that implements this natively. This way, tb code can use this functionality without fear that it will cause runtime errors in your browsers. In this case it's quite unnecessary, though. The polyfill is loaded by community-theme, but the only code using this functionality is located in back-office forms. So front theme does not help here at all. I suggest you to remove this from your theme header.tpl -- your shop will load a tiny bit faster.

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