datakick

Your question is not very clear. "now this whole page of features looks like big piece of shit" -- what page of features? This post was originally about front office "Data Sheet" section, and it's translation. Are you referring to this section?

This is bug in ultimatedatabaseoptimizer module -- module constructs invalid sql query, and database raises error. New version of tb reports all invalid sql queries as errors. Previous tb versions silently ignored these errors. You can force the original behaviour (see Advanced Parameters > Performance > Ignore SQL errors), but I strongly advice against it. You should contact module developer and ask them to fix the bug instead.

That's because this is not an application issue, but deployment problem. Thirty bees correctly created resized image files, as you proved by accessing them directly without time=??? parameter. If the image is not accessible when you add any query parameter to the url (like time=111), then the issue is in your server configuration. Check your .htaccess and/or nginx rewrite rules. Check your proxy server settings (cloudflare, or whathave you).

Yeah, this is definitely a bug in the Whatsapp module. The proper way is to fix the module itself. Module should not pass integer as 3rd parameter. This method always accepted 2 parameters only (in ps16, and in all previous tb versions), so passing this 3rd parameter was always a no-op. We will see more issues like this in the future, with newer PHP versions being much more strict.

It's a deprecation warning, just an annoyance. Revws works fine on php8. It will not work on php9 without changes. Fix will be released before that

<span id="our_price_display" class="price" itemprop="price"> This <span> should not have itemprop attribute. See here: https://github.com/thirtybees/niara/blob/eddb7661e611f9f4f494449eec0cea134c0c884d/product.tpl#L326-L327

No,it's not normal. That would be huge coincidence. What tb version are you running on? There were some fixes in bleeding edge regarding webp generation, so maybe updating to 1.4 will help.

you don't need their webp module. tb supports webp natively.

See my previous answer. Moving watermark section to the end of .htaccess is not a solution, as other rules have precedence. You can even delete the watermark section, as it is a no-op when at the end of the file. The watermark section explicitly says that access to source image files is forbidden, unless the referrer header matches your admin directory. When you load Bo > Products page, your browser requests image from your server. This requests contains REFERER http header, and your apache server use it to authorize request. If you have problems with this, it might be by string Referer-Policy -- your server might have instructed browser to never send this REFERER header, and that would couse your problems. For more info, see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy

The bug I fixed today in watermark module was not related to your issue. It only fixes specific situation when module did not properly clean up when uninstalled. Regarding your issue -- this is NOT A BUG. When you install watermark module, access to source image files is supposed to be blocked. This is, after all, the reason why anyone would use this module -- to protect their image assets. It doesn't make any sense to have watermarked images on product page, but allow access to source/high resolution version without any watermark image. The watermark section should be at the beginning of the .htaccess file, otherwise other rules have precedence

add <webp>1</webp> into your config.xml file. Should look like this: https://github.com/thirtybees/niara/blob/e8e7e46f18f5ff1b52df67b27382058be8af8537/config.xml#L221 Also, update to latest bleeding edge.

chex uses different payment discovery API that standard checkout page. Standard checkout calls hook 'displayPayment' that returns arbitrary html / js code that should be injected into the page. Chex does not do this, as it would not be able to control the page flow if it was constructed randomly. Instead, it uses hook 'displayPaymentEU', that returns list of payment options together with action to be performed. The result is the same as when you enabled 'Advanced EU Compliance' module checkout page.

I've just tested watermark module .htaccess modification functionality, and it seems to be working. Module correctly remove its section when uninstalled. If this did not happen for you, then maybe permissions or ownership of the .htaccess file has changed sometimes in between the module installation and uninstallation module wasn't uninstalled properly, but simply deleted somebody modified .htaccess file and removed or modified delimiters that watermark module uses to detect borders of the section.

??? I don't follow....

.htaccess rules, nginx settings, watermark module,.... this is deployment issue, not an application one.

We don't know shipping costs upfront. The actual costs depend on selected carrier, destination shipping zone, total cart price, or total cart weight, customer group, etc.

I'm afraid this module does not implement any other hook handler on product page, so it's not possible to transplant it

You have probably enabled feature Generate high resolution images recently. Your store now tries to display images in double-resolution: https://expomueble.info/7916-Niara_home/conjunto-tres-cuadros-audrey-hepburn2x.jpg instead of https://expomueble.info/7916-Niara_home/conjunto-tres-cuadros-audrey-hepburn.jpg You need to regenerate all images from your back office, so the 2x variants are created.

Looks nice. Please create PR, definitely something we want to support

If you update to bleeding edge, you can enable webservice logging functionality. This will tell you exactly what request / response looks like, and also logs all errors properly. Webservice on 1.3.0 does not report any error messages to server/tb logs, but sends them to the client instead.

What webservice are you talking about? Is it stanard webservice build in tb? Or is it some api exposed by their integration module?

https://crowdin.com/profile

Is your crowdin account assigned to 'thirty bees' cronwin project?

It's probably a good idea to unify it. When we switched from sql installs script to ObjectModel metadata, we converted the original script. We didn't really question if it makes sense or not, the intent was to generate the exact same SQL script from object model as had in install directory. Now we can definitely think about changes 🙂 this one seems like a good one. Can you create a PR?

I never understood why the theme have to mark if it is compatible with webp or not. I suspect this is because sometimes javascript makes some weird operations. I have seen js to implement zoom functionality by replacing the 'home' image type with bigger pictures (yes, manually constructing product image url). This kind of javascript code could break if the source image was webp. But, generally speaking, there is really no reason to defer decision whether to use webp or not to theme. I agree we could have some settings option to choose default image type. As you noted -- there are couple of places in the core where jpg are hardcoded. We would have to find them all, and replace them with proper way to generate image url. That would make the codebase much cleaner. Unfortunately, there are also a lot of modules that constructs image urls manually, forces jpg, etc... for these, we should have a fallback mechanism in place. NotFound controller could probably just return webp image content with correct Content-Type, and browser would understand that.