datakick

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.

Yes, to fix this, we would have to add another option named Custom to range preselect: That would allow us to permanently set custom date ranges, without them being overwritten every day on midnight. I would appreciate this as well, as I don't like this Cinderella-like reset. But not a big priority

New version of vatnumber module was released. The validation check now works again using SoapClient. You have to make sure that you have 'soap' extension installed and enabled in your php server. There is also new tool in module configuration page to check if the validation works.

product.tpl template in your theme.

I'm not sure there is a bug at all here. First of all -- this is specific to some payment gateway / module. Most of the modern payment solutions do not send payment information in query / post parameters when redirected to payment gateway. Instead, payment intent is registered using back to back call (your server informs payment provider about the amount, items, etc), and redirect only contains unique ID of this payment intent. There is nothing that attacker can intercept and/or modify. If your module/payment provider send amounts in redirect request, you should consider switching payment provider. Other thing is -- thirtybees supports partial payment. You should always check order in back office to see if it is paid full or not. Note that payment status is not trustworthy indicator of this. Order can be, for example, in 'Payment accepted' status, yet still be partially paid. If attacker intercepted and modified redirect to payment processor, then the payment will not match the order total. This should be marked on your order in Payment section: If the payment is not registered correctly (order is marked as fully paid even though different amount was actually paid), then this is bug in the payment module. Payment gateway redirects user back to your website, and payment module is responsible to extract the information provided by gateway. Again, it will be either some ID and module will do direct server to server call to receive information about transaction, or the information should be (somehow signed) in redirect request itself. It's module's responsibility to resolve (and verify) the amount actually paid.

There is still an annoying issue that we can't use custom date range. Well, we can temporarily set the date ranges to any custom values, but they will be overwritten on midnight to reflect selected period. Probably not a big deal, but it would be useful to have this persistent custom option as well - for example for merchants that have fiscal year not aligned with calendar year.

We have investigated together with @Coachonko, and there indeed was a bug in PayPalPlus submit controller. Fixed by commit https://github.com/thirtybees/paypal/commit/cd4f8a5ff3062539d5ca013abf0158ffe467e5eb. Will be part of next module release

Try to downgrade paypal module, for example use version 5.4.5 - https://github.com/thirtybees/paypal/releases/tag/5.4.5. If that help, we know that the issue is new injection is 5.5 version. If that does not help, try updating your store to bleeding edge / 1.4 -- a lot of issues were fixed there. Might help. Might not.