datakick

.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.

css is all about specificity. Proximity is only relevant if multiple selectors have the same specificity level. Since your intent is to 'override' things, I suggest you explicitly increase specificity of your overrides. For example, if the selector in core css file you want to override is .btn.primary span { color: black; font-size: 2em; } then you can create override selector to change the color, you can add this to override file: .overridable .btn.primary span { color: red; } You will also have to add class='overridable' to the <body class='overridable'>. This way, you can actually toggle the class in <body> to see the impact of your overrides. Alternatively, you can do it without template modification, for example by body .btn.primary span { color: red; } But here you have no easy way to debug the overrides. If you want to depend on proximity (==order of css files), then you will indeed have to create a module to modify the css list.

I'm not sure what you are trying to achieve. If you just need a mechanism to include another css file, then simply put it inside your theme's /css/autoload directory

That functionality is not implemented in core at the moment. We actually have this on our todo list. It's not only facebook that has issues with this, this also prevents proper GMC links for combinations, reviews associated with specific combinations, etc...