datakick

As Smile wrote -- adding new field to db, and implement basic CRUD operation on top of it, is quite simple. Anyone who really need it can can implement this functionality. Hoverer, to add this properly to the core, is more complex. We have to considerer other aspects as well, for example: support this field in CSV import expose this field in Webservice, both read and write access impact on themes -- should this be exposed to theme? Do we need to update community-managed themes? since this is a classification field, maybe we should have a new table with all possible values instead of free-text? If that's the case, we need to populate this table during install AND during store update, and make sure the table values are up-to-date (which means future work is needed) and who knows what else It would take a few hours, maybe even days, to do that. It was not worth the effort at the time - no real demand for this field, and if anyone really needs they can create a limited implementation themselves.

Yes, you should install collectlogs module, and let it collect errors for a few days. You have to fix all deprecation warnings - core code should be ok, but you will get some errors from modules and theme. After all warnings are fixed, you can safely update to higher version of PHP. Always update to next PHP level only - from 7.4 to 8.0. When you later want to update to 8.1, you will have to repeat this process again.

You have to set permissions for this webservice key in Advanced Parameters > Webservice

Your hosting provider suspended your account for some reason. Maybe you didn't pay, or maybe your site was sending spam emails,... Contact your hosting provider

When I tested it yesterday it indeed displayed the robots.txt error. I assume that google used, at that time, some old (cached) version of robots.txt that blocked the access.

My guess is that your server is blocking requests from google servers (maybe you have some firewall or something that block it) This is not an application issue. You can verify this by checking your server access log

It was not possible to load csv/excel file for some reason. Maybe incorrect file permissions, maybe missing php library, ... Please contact module author for assistance

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