datakick

I agree it's terrible error message, and it should definitely be fixed. Do you, by any chance, have nocaptcharecaptcha module installed?

Most certainly not. If there's a bug, it's been introduced sometime between Jan 21 - Mar 21. You never answered my question - where did you encounter this problem? Was it on front end? One page / every pages? Have you tried disabling non-thirtybees modules?

That's not good, we should definitely find out root cause for this problem, so it won't get into the next release. Unfortunately I can't reproduce it locally, so it's probably caused by some module / theme interference (which does not mean that module / theme is the culprit, they may just use the system in a way that triggers this error). Has anyone else encountered similar problem(s) on bleeding edge?

@smarterweb have you also cleaned cache? Even if you have all cache disabled, smarty can still compile and cache templates in /cache/smarty directory. (btw, you can safely delete this directory using ftp / ssh)

For me, the image is displayed correctly on both blog post detail and blog category pages

Where do you get this error? I've just updated my demo account to bleeding edge, and it works ok for me, so I'm not sure where the problem might be.

The core updater **DOES NOT** work against thirtybees git repository. That's because tb repository contains source code, but core updater needs *compiled* code. I know... in php there is no such thing as compiled code. But there is a build process. To put it simply - if you were to download code from tb repository and uploaded it to your server, it would not work. You need to build it first. So there is another (private) repository, which contains *compiled* code -- result of build process. Core updater communicates with this repository. The problem is that there is not yet any automated mechanism to build thirtybees git repository and publish it to private repo. This is done by hand at the moment, and that's the reason why you don't see the changes very often. This automation is under construction, though, so very soon this will be solved, and Bleeding edge will truly bleed 🙂 BTW, I've just updated the private repo, so you should be able to update to *new* bleeding edge

Should be fixed now

Look into: 1. Advanced Parameters > E-mail -- to verify that the email wasn't really send. It's quite possible that your server actually sends it, but it gets dropped somewhere along the way. 2. Advanced Parameters > Logs -- if the email is not send, there should be some hint in the system logs. For example information about missing template. Note that these email error log entries are logged only once, the first time thirtybees see it. That means that it may be buried somewhere deep in the log list. So look carefully. Alternatively, you can truncate tb_log table to start with clean slate. truncate tb_log;

I think that this affects users that were migrated to new forum. Newly registered users should see signatures by default. I'm sure @lesley knows more

Yes, I'll fix this in future version Emails are extremely tricky. There exists many different email clients, and every one of them supports different subset of html and css markup. Moreover, web based clients (like web gmail) actually modifies the html markup, dropping unsupported tags or css declarations. Email images are another big problem. Some email clients block images from remote url. Alternative is to embed image into email body as attachemnts. But that's also problematic, because some (web) clients can't reference attached images from html markup. Inlining image using data-uri doesn't work as well, for example gmail blocks this... This all leads to email displaying differently in different email clients. And there's really not much we can do about that, other than providing textual alternative. Revws trying to do this, so email is displayed somewhat coherently. For a comparison, here's the same email displayed in gmail web client, and in apple email client: Not optimal, but still quite usable.

No, settings is global for all shops. I guess it should be pretty easy to enable this per shop, though -- just replace Configuration::updateGlobal with Configuratin::update Not yet. There's a enhancement request in the backlog for this Pretty sure it works, you can test it on my demo shop, for example by using this url: https://demo.getdatakick.com/en/module/revws/EmailAction?id=95&action=review&product-id=3&rating=4&secret=217d5565d80f7e1cd5e2b3156d78acb5 Compare it with invalid link -- this one should display error https://demo.getdatakick.com/en/module/revws/EmailAction?id=95&action=review&product-id=3&rating=4&secret=217d5565d80f7e1cd5e2b3156d78acb0 Yes, that's current order status. If you want to send review requests only to those orders that has been shipped, you use "Delivery delay" option. Whenever your order goes through some state that has 'Set the order as shipped' turned on, it will update delivery_date field on this order. This field is then used by revws module to calculate 'Delivery delay'

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.