datakick

That's server configuration issue - maybe php8 does not have pdo_mysql driver enabled. Contact your hosting provider again.

You can create module that implements actionGetNotificationType hook. As an example implementation, I can refer you to productcomments notifications: https://github.com/thirtybees/productcomments/commit/ad70c1b0505bbeac8fc57ccb588fbdd8a4962191

It shouldn't be a problem. You just need to uninstall ME core updater install latest TB core updater from here: https://github.com/thirtybees/coreupdater/releases/tag/1.6.5 edit /config/settings.inc.php and change _TB_VERSION_ constant from 1.9.2 to 1.1.0 Now, core updater will think your installation is modified thirty bees 1.1.0, and will raise a lot of warnings about modifications. You can ignore these warnings if you didn't made any modifications, and update to latest thirty bees.

Probably some javascript error. Look into your browser console

I don't think that there is any new code that broke this functionality, but of course I might be wrong. When customer is not logged in, there is no specific address thirty bees can use to calculate shipping costs. If that happens, thirty bees will try to calculate shipping costs for currently selected country. In most cases, this is shop default country, set in Localization > Localization. But it can be different, for example if you use some geolocation module, which can resolve customer country (and language) First of all, check Localization > Localization > Default Country Don't forget to delete cookies during testing!

Columns New client in order list is not stored anywhere. It just shows if the order is the first order created by this customer id. Every guest account has its own customer id, so it will indeed show true. You can merge customer accounts with the same email addresses if you wish.

It works fine for me. Check that your niara theme has this code: https://github.com/thirtybees/niara/blob/d469fcb47b589783deebe847b77bc8d1c0a1d242/footer.tpl#L17-L21 if the code is there, check that Community Theme Configuration module is enabled (in all stores contexts, in case of multistore) if it's enabled, check that Disable non thirty bees modules settings is not on check Customer group module Authorized Modules - maybe your Visitor group has this module unchecked reinstall module to ensure all hooks are properly attached

Niara already has copyright section. You can edit content using Community Theme Configuration module

https://github.com/thirtybees/niara/commit/15e5338e628fca184a339d6cde66c961bfeb8169

Validate::isValidEmail is called very often, in many contexts. Changing it is not a good idea. If you indeed have a need to validate email addresses, you can use hook actionBeforeSubmitAccount and do your validation there. I personally think it is not a good idea, as you will loose sales. Note that there are third party api that you can use to validate email addresses. For example, mailgun verification service works very nicely. They do a lot of tests - check that domain exists, test that MX records for domain exists, check that recipient email server is accepting connections. And apart from this, they have their own huge database of 'alive' emails, because their service send millions/billions emails monthly and they process result/bounce responses/etc. Still, I use this service to validate emails in my marketing list only. I don't care if address for transactional emails are invalid, I send the email anyway. If my customers don't want to tell me their real email address, they should be allowed to do so. As long as they complete the purchase, I'm happy. They won't be able to retrieve forgotten password, and they will not receive order processing emails, but why should I care.

There are modules for accepting crypto, but they usually work with some provider using third party api. If you want to implement crypto payments yourself, you can. 1) simply create custom currency (bitcoin, ethereum, etc), and set conversion rate (either manually, or via script). Then you can create custom payment method, and set currency restriction in a way that only this payment method can be used with crypto currency. 2) again, a lot of ways how to solve this. For example, my conseqs module can be used to change order status after some period of time. Or you can create simple cron script.

I understand your frustration. However, it's simply not possible to maintain 100% backwards compatibility, and yet move this project forward. Some of the compatibility changes were forced upon us. For example PHP8 reserved new Attribute class forced us to change core class name, without any way to provide BC polyfill A lot of libraries thirty bees core depended on, like minification, http requests lib, template, made their own changes and API modifications. Old versions of these libraries are not PHP8 compatible, so we had to adopt the new one. Again, this cause BC compatibility problems if some module uses them. To maintain compatibility in these areas, we would have to abandon PHP8 completely. And we don't want that. Even for a price that some older modules stop working. Then there are those minor incompatibilities you talk about. some of these are caused by new feature developments (new column in tables, new indexes, additional parameters to some methods). We try to implement these changes to be as BC as possible. For example, most of the new columns are nullable. Sometimes, it's not possible, though. changes in code structure - basically refactoring. We very rarely change signatures of public or protected methods, mainly to maintain BC with overrides. Sometimes we do this, but not very often. changes in semantics - again, we do this very rarely. For example, change return value of some method from 'array or null or false or zero' to return only array. These changes are sometimes forced to fix php8 issues caused by older modules. For example, some module can have code foreach (SomeClass::someMethod() as $row) {...} if someMethod returns false/null, this would throw an exception in php8. We might decide to fix this problem by making sure this method never returns null/false, and it always return array (maybe empty). But that can cause BC as well, if some module have strict comparison checks like this if (SomeClass::someMethod() === false) {...} So we now have to make a decision to prevent exception (500 error page), or potentially cause some minor compatibility issue. It's not an easy decision. And whatever we decide, somebody will blame us for doing it wrong. bug fixes -- yes, some modules depends on bugs in core. Some bugs were there for years, so module developers embraced and worked around them. When we finally fixed those bugs, modules stop working properly. Should we keep bugs in the core? I don't think so So yes, there are some (maybe lots of) backwards compatibility issues. Still, it's orders of magnitude less than what ps17 forced upon their user base. The only way to not have backwards compatibility issues is to stop development.

yes, there is new column in table tb_feature_lang. If you use coreupdater to update your store, it should be automatically created. If you updated your store manually, you can still use core updater to fix database differences.

I don't understand why this should bother you just now, as this was the case from the very start of thirty bees. This was the way tbupdater module extracted the modules it downloaded from api server. Module directory was indeed deleted, and replaced with new dir. If you uploaded the module manually, this didn't happen -- content was merged. In thirty bees 1.5, this is not an issue anymore, since we don't use tbupdater for updating modules from api server anymore. How is that a compatibility issue? We simply display information about extra column. We don't delete the column from db. We also display that removing this column is 'Dangerous'. I would expect that nobody would click on it, unless they know what they are doing. This is similar to previous point. Some module decided to change database schema for core table, and didn't bother to inform core code about this change. You are saying that core is breaking the module by enforcing database indexes it depends upon. I say that module is breaking core by changing database indexes. The core code depends on unique indexes a lot. PHP code expects database to enforce these indexes. If some module changes the index structure, all these assumptions in core code stops working. Exceptions and 500 error pages follows. Ahh, finally some compatibility issue. Thankfully 99.5% of modules uses lowercase-only in their names, so this one is not critical. I agree it should be fixed, though. We do accept Pull Requests -- feel free to fix this bug if it causes trouble for you. Should be fairy easy.

I'm afraid this is not easily doable, as back office login is performed by ajax call. That would probably require template override.

If you apply it recursively it should be enough (if it's the right folder) There can be other issues other than permissions. For example open_basedir php settings. Or misconfigured apache modsecurity. Or any other. Look into your browser network tab to see what your server response was for the ajax request that failed (the one with generateSettingsFile=true). There might be some clues there. In my case it completed without errors, I guess in your case there will be some error displayed

You are not supposed to create it, installer will create it itself. The first message means that installer failed to create settings.inc.php file for some reason (probably folder permissions)

Yes, as long as the schema remains the same - for example {categories:/}{rewrite} If you change the schema, then the old urls will stop working.

This functionality is kinda weird. If you have product ID in your url schema, for example {categories:/}{id}-{rewrite}, then system will use the product id directly and it doesn't matter what is entered in categories portion of path (even product rewrite can be wrong, it is not checked) For example url https://domain.com/en/a/b/c/d/2-whatever will automatically redirect to url of product with id 2 - for example https://domain.com/en/gifts/2-soap However, if you don't have ID in your url schema - for example {categories:/}{rewrite} then system will try to resolve the product ID by looking into db if product with given rewrite exists if it exists, then check that url matches The step #2 seems to be unnecessary, and is causing troubles. Without it, the system would automatically perform redirect for url for product with matching rewrite https://domain.com/en/a/b/c/d/soap but now it returns page not found, because the url for soap does not match expected url https://domain.com/en/gifts/soap I will probably fix this in bleeding edge / 1.5 @30knees with this change, you shouldn't have to do anything. Your old urls will be automatically redirected to new ones.

This compelled me to set up static subdomain for my website as well. Everything seems to be working correctly. Could you check with your chrome version https://store.getdatakick.com/ if it works fine for you?

No, I can't. It's likely browser version issue, or server configuration (maybe too strict cors policy, etc) Could you PM me your domain, so I could test on your site?

I guess thirty bees will have to emit some additional responses headers to mark media servers as trusted sources. I will have to read up on that. @the.rampage.rado can you create github issues, and enter any information you have found so far regarding this are? Media servers do not really help you that much if you point it to the same server as your primary domain. The only benefit is that requests to static assets on media servers will not contain cookies, so each request will save ~2k of data each way. Another benefits is that you can apply more easily caching rules (for example in cloudflare) If you had another server, and set up data sync between your primary server and your media server, then the benefits would be much bigger. On the other hand, you would have to solve issues with out-of-sync data

The only thing that exists is this: https://github.com/thirtybees/thirtybees/blob/e25be2ffb57ff6d98ea28b65ac3aa3bc6e621d0a/classes/ConfigurationTest.php#L180-L195 That should NOT run during installation time, because constant _DB_SERVER_ is not defined yet. If this test is executed during install time, that means that you defined this constant somewhere - most likely in in settings.inc.php file. Double check that this file does not exists.

Apache might have similar settings / issue with big headers. See here, for example: https://bz.apache.org/bugzilla/show_bug.cgi?id=64919 This is all just guessing. You have access to your server, so look into your apache/nginx/php error logs. It will tell you what is wrong, that's what they are for.

This looks like issue with small nginx header buffer (if you use nginx in front of your php) Look into your nginx error logs if you see messages like this one: upstream sent too big header while reading response header from upstream By default, nginx support only 4k of http headers. Sometimes it's not enough - all cookies, Location header, custom HTTP headers, etc must fit into this, which can be a lot. Especially if you have multiple cookies. For example, my PHP server returns 959 bytes in headers with single cookie. If I'm logged into back office, this would be around 2k. HTTP/2 200 server: nginx date: Tue, 11 Jul 2023 06:30:39 GMT content-type: text/html; charset=utf-8 x-powered-by: PHP/7.4.33 expires: Thu, 19 Nov 1981 08:52:00 GMT cache-control: no-store, no-cache, must-revalidate pragma: no-cache powered-by: thirty bees set-cookie: PHPSESSID=5ng3b7o88aktkk43uktrvnb645; path=/ set-cookie: thirtybees-52c547b202be54b989b7b16314b81de3=def5020083e391b99d2b735eec52301c2b655e1aa64110a7382a792b9e548322f81599d1c6480e39ee0f24a9ea1cf5ddfc502241d446f14065f449cae12783db1ad8db942d281e8dcabb67239a3d8592c77b8da9a5294caf3af5a8c974eccb9b8609801ebb9809971eef3f56eff88cd3c639d8150b737a21e13ac9507afd57ea3b67cfe39a89edda5f125ce2b0ff7c1bb617efee261f71f4df37f3a412be793c9d025d90b5439e0d90a0cd6409eb3d8d420ce601d72e682ba9578e7f451015be1be55afd7259a70f5db9a10e9e068cb418315637648413fada4e12c4; expires=Mon, 31-Jul-2023 06:30:38 GMT; Max-Age=1727999; path=/; domain=***.com; secure; HttpOnly x-powered-by: PleskLin If you use modules that creates their own cookies, this can easily reach 4k limit. If that happens, nginx will then drop the response from PHP, and returns 502 error page instead. The fix is to modify nginx configuration and increase buffer size. For example, I use this: fastcgi_buffers 8 64k; fastcgi_buffer_size 64k;