datakick

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.

Neither of these messages are errors. They are merely notices without any impact on processing. Without an actual error message, nobody can help you. It might be. It might not. PayPal module tries to convert cart to an order. To do that it uses standard core functionality - PaymentModule::validateOrder method. This method triggers a lot of hooks that other modules can subscribe to. It's quite likely that some of these modules throws an exception that causes the validation process to fail. For example, there can be some module that synchronize data, sends an email, or whatnot. And I'm not even talking about overrides. Without error message we don't know what is wrong, and we can't even assign blame to a specific module (paypal). I know it's frustrating, but that's the way it is.

This is not an application issue. Check your .htaccess or other server configuration.

Couple of ways to achieve this. Easiest solution is to edit your theme/template and just add your css file in there. Of course, this will not survive the theme update other solution is to create a module, that registers displayHeader hook, and adds your custom css file. You will have to ensure your module is LAST in the position list (Modules & Services > Positions) create override for the FrontController::initContent method and do your preprocessing there I still think that the 'proximity rule' approach is not best way to handle this problem, as it does not really solves it. Your override *can* stop working when theme author changes html markup or specificity of css rules. So after any theme update you should check that all overrides still works. As an example, let's say that in version 1.0 of the theme the css file contains this rule: .btn { color: blue } You override it by .btn { color: red } This works, because of the proximity rule. Now, let's say that theme author, for some reason, changes theme css rule in version 2.0 to span.btn { color: blue } Now, your override will not work, because specificity of new css rule is higher than your override. So even though your rule is 'closer', it is not picked up, and you have to modify it anyway. From my point of view, overriding using proximity or higher specificity are basically the same. After all updates somebody have to check that rules still applies. That's why I don't see much sense in trying to 'bend' thirtybees core to include some css file as last. But it's your decision

I have a vague memory that something in this area was fixed for 1.4. I run my store on that version, and dashboard dates work fine for me. Just remember to select valid period, and the dates should change every day to match it.