datakick

@x97wehner Without error logs, it's not possible to say what is causing this. The module probably catch the exception, and returns this generic error message. You will have to modify the place where this happens, and add some additional logging -- display exception to output, or re-throw it and let collectlogs catch and log it. Or something similar.

the server responded with 500 error code. Check for errors in collectlogs module.

klarna payment method is now supported in stripe v1.9.4

Maybe you have nginx in front of your apache? Or some other caching server?

Yes, but since that note was written, the proper fix was released -- see the patch. That note is no longer relevant.

Can you point me to the place where it says that? I didn't see it anywhere. I found 4 CVE's related to this module, all 4 has been addressed and fixed already Sure, that's fair. Hopefully you will find something that you can use instead.

There was a critical security bug in the old version of the module, but it was discovered and fixed. Author of the module cooperated with the security advisory team and released a patch in timely manner. There's no reason to think that the new version is not safe -- the security team most likely tested it to verify the 'fix'. I obviously understand that you don't want to buy it again because of your bad experience with previous version. I'm just saying that there's no reason to think the product is unsafe. I would personally consider it more 'safe' now since it obviously went through a couple of hard breech-tests. Module author released security patch on 2023-11-15. There was some time for you to update to safe version of module, and prevent this whole issue. It's very important to keep the store (both core and modules) updated.

Yes, thirty bees does not utilize billing address entered in stripe checkout. We should probably remove this "Collect Billing Information" settings from the module. Before your customer is redirected to checkout, customer account, shipping and billing address needs to be resolved, and saved in thirty bees database. Address is used to calculate final price -- order final price depends on invoice country because every country can have different taxes. If we allowed changing billing address during payment step, we could end up with situation when the collected payment amount would not match invoice amount. Example: I sell digital product with base price €60 in EU. when my customer is from Czech republic, the final price includes 21% VAT, so I need to charge €72.6 when my customer is from Germany, the final price includes 19% VAT, so I need to charge €71.40 If I allowed changing billing address during payment, then I could collect only €71.40 while invoice displaying final price €72.6. Or it could be reversed -- I might collect €72.6 even though I should have collect only €71.40. It's just too late to change billing address information during payment step.

The error you are seeing is because your site returned html response for POST request to https://your.domain.com/index.php?controller=connect That should not happen -- it's probably some custom redirect, custom routing, etc. What accounts.thirtybees.com is trying to do is authenticate that you are the owner of the website. When you click on connect button in your store, your server generates one-time secret code and saves it locally. Then it performs redirect to thirtybees accounts server (this redirect contains this secret code + your domain url). Once you log in, accounts server send (server to server) request to your website to verify that the secret code matches. If it matches, your user account is associated with the domain. In your case, this verification request fails, unfortunately.

Looks like you have corrupted installation - some php files are probably missing. How that happened, that's a question. Most likely it's a user fault -- you or some of your employee may have deleted or moved some files of folder accidentally. Or you have some module that screwed up and deleted what it shouldn't have. Or your site was hacked. Or whatever. Anyway, to resolve this situation: First of all, try deleting cache/class_index.php file -- maybe it's just corrupted cache. After deletion, check the site again. If this didn't help, then download zip package for your tb version (and php version) from https://thirtybees.com/download-specific/ unzip it to temporary location delete install, themes, modules and img directories rename admin directory to match your current admin directory name, ie admin1234 move everything from the temp location to your server root -- override existing files delete cache/class_index.php That should fix the problem After you are back online, use core updater to check your installation, and fix any issues. And yes, you should think about updating to newer version of thirty bees.

Check javascript console. There will be some error, probably caused by some module.

Why would it be bad for SEO? The original image urls still works, and google will (over time) learn about the new urls.

I believe this will be a rewrite issue. The friendly-url links for product images changed, it used to look like /35-home/friendly-rewrite.jpg but now it contains /products/ prefix: /products/35-home/friendly-rewrite.jpg. You should regenerate .htaccess (or your nginx configuration if you are not running on apache). I believe this would fix the issue. If not, we could troubleshoot more. That's unfortunate, since we can't figure out what the root cause was now. Please test updates on dev/test site

Go to preferences > store contacts, and set Shop email to one that your SMTP server accepts.

use SMTP for sending emails

Look in the browser console network tab, find the ajax request that failed, and look what response contains. There may be some hints there

No, modules for ps17 are not compatible with thirty bees.

The only version of this library that exports \Mobile_Detect into global namespace is version 2.8.x. Library author claims, in docs and in composer package.json, that version 2.8.x supports only PHP >=5.0,<7.0. It may be that that version can actually run on php7.4 as well, I don't know. But I believe author when they say that it doesn't. Since thirty bees does not support PHP<7.4, we can't use that version of library.

This is unfortunate backwards compatibility issue, but there's nothing we can do about it. Your module directly depends on old version of MobileDetect library (<3.74) -- that version is not compatible with PHP7.4 or higher. Ask the module author to use method from Context class instead. Lines 165...171 should look like this: $layout = Context::getContext()->isMobile() ? 'mobile' : 'desktop';

As @wakabayashi wrote, it's somewhat simple to reduce multistore to a singlestore. You need to make sure that all db records are assigned with target shop first. Check all *_shop tables, and *_lang tables and that contains id_shop column, are associated. Once all records are associated, delete the source shop. There shouldn't be an issue. List of related tables: SELECT table_name FROM information_schema.tables t WHERE table_schema = database() AND ( (table_name like '%\_shop') OR ( table_name like '%\_lang' AND EXISTS (SELECT 1 FROM information_schema.`COLUMNS` c where c.TABLE_NAME = t.`TABLE_NAME` and c.`COLUMN_NAME` = 'id_shop') ) ); If you have two stores in separate installations (not multistore), then it would be much more complicated. You would have to probably use data export and import.

Thanks for letting me know. This module checks only existence of .jpg source file. With the image rewrite, we can now upload and store source files in different formats as well (webp, avif, png,...) I will have to update the module to check for those as well

That still doesn't rule out infrastructure/misconfiguration issue. For example, you can have nginx reverse proxy with low settings for buffer memory. If your php server returns bigger http headers that can be stored, nginx will drop the response and return generic/standard error message similar to yours. One of your thirty bees installation can return much smaller headers, for example because it contains less cookies, or cookie content is smaller. I think that you should really investigate the root cause of this problem. Because it's most likely not a problem with application. You can reinstall your tb from scratch, restore database, and then encounter the same problem once again. But if really want to migrate -- it's easy. Backup your database. Install thirty bees. Edit settings.inc.php and copy all encryption keys there. Restore your database. Then go to core updater, enable debug mode, and in developers tools run database migration and initialization callbacks. That should do it.

Well, something is returning 403 Forbidden response. I don't think that it's thirty bees / php application. Thirty bees wasn't most likely even invoked here. I'm 99% sure this is issue with your infrastructure nginx configuration apache config mod_security config firewall settings your server antivirus your computer antivirus your computer firewall your browser extensions some "security" thirty bees / prestashop module (not likely, but could be) ...

no, it's standard https

The solution is to demand that google fix this bug on their side. If your robots.txt instructs google to ignore some url, then google console should not display warning that the url is not crawlable.