datakick

You should ask duckduckgo this question, not me. If the robots.txt explicitly blocks the url, there shouldn't be any reason for them to index it.

We have custom sendylists module to synchronize thirty bees with lists in sendy. However, we had to modify the sendy installation itself, because it doesn't support bulk api call by default. So this module is not useful without that modification. That's one of the reasons why we didn't release it publicly.

Thanks. 1) We know about the the first set of warnings -- this is issue with legacy code, that stored transient information into objects during import. It will take a lot of refactoring to fix this, unfortunately. Currently it's not high on priority list, as it's still just a deprecation warning. This will be issue on php9, tough 2) Tools::getDateFromDateFormat - thanks, fixed in bleeding edge 3) consistency check module -- I haven't updated the module to check for all supported extensions -- do not use this module on bleeding edge yet

Hi, use core updater module to check (and fix) database differences. Your update probably failed before db was migrated properly.

Should be fixed in bleeding edge, please try

It's a bug in core, I've managed to reproduced on my dev env. I'll prepare a fix and let you know.

I very much agree with @the.rampage.rado From security point of view, it's much better to install thirty bees into standalone subdomain. I have seen thirty bees sites that were infected because of wordpress installation. Using subdomains has some additional benefits as well. For example, less cookies will be sent -- thirty bees will not receive wordpress cookies. Or misconfiguration in .htaccess within parent (wordpress) directory will not affect thirty bees web. And I'm sure there are more. Install in in standalone, isolated, subdomain.

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.