datakick

you can use Matomo (piwik), its self hosted ganalytics alternative. There is native tb module for it.

yes

Hi everyone, I've releaesd new module MailQueue. This module uses latest thirty bees Mail Transport functionality, so currently it can be used in bleeding edge / 1.5.0 only. Link to the module: https://store.getdatakick.com/en/modules/mail-queue As the module name suggest, the main functionality of this module is to defer sending emails. Instead of trying to deliver email as part of business process, module will serialize and save it to storage (filesystem, redis, db). Cron or CLI queue processor (that runs in separate thread) will pick these queued emails and attempt delivery later. You can create multiple outgoing queues, and create conditions to determine which emails should go to which queue. For example, queue for 'contact' form messages. Queue for shop admin recipients. Queue for emails that contains words 'binance' or 'viagra'. Queue for transaction emails, queue for marketing emails,... Each queue can have different settings, of course (it wouldn't make it much sense otherwise) throttling -- how many emails can be sent per hour delay -- initial delay to send email failed delivery retry settings manual approval, etc retention policy -- how long do you want to keep email in the queue / after send sending channel -- every queue can be send using different email transport. You can send transaction and marketing emails through differnt SMTP servers Some benefits of this system original process is not blocked by email sending. Slow SMTP servers can block order creation process even for a few seconds. process is not interrupted by SMTP errors - if SMTP server was down, exception could be raised, and this could block process to be finalized (order not completed) this supports sending a large amount of emails easily -- enqueueing emails is fast, so you can generate a lot of emails during one request - useful for sending marketing emails to a lot of recipients retry option - cron/cli can retry deliver email later if SMTP error occurs you can view email content before it is sent, and even after it was sent (depending on queue retention policy) delaying some emails (for example you can delay review request email by 3 days) pause queue in case of some attack email priority different sending channels I'm currently looking for volunteers that would like to test this module, before I release it officially. And of course, if you have some ideas or questions, let me know. I'd love to hear them all.

Review request link looks like this https://domain.com/en/module/revws/EmailAction?id=<ID>&action=<ACTION>&product-id=2&rating=5&secret=<SECRET> When the link is generated and send by email, parameter <SECRET> is calculated as md5("<ID><ACTION><SALT>") where <SALT> is secret key stored in database, not visible to customer, When customer click on email, EmailAction controller once again calculates the secret using <ID>, <ACTION>, and then matches it with provided <SECRET> parameter. If the calculated hash value is different, link is rejected, and permission denied is thrown. This can happen only if one of the following is true: parameter <ID> in url has been changed parameter <ACTION> in url has been changed parameter <SECRET> in url has been changed secret <SALT> was changed (in the database -- for example by resetting module)

I believe this is causes by some module. There are only a few places in the core that call this function, and none of them is in the product controller area. Anyway, a lot of modules (for example modules to synchronize data or that generate feeds) uses on this function, because default 30seconds might not be enough. If your hosting provider can't disable this, I would consider changing server.

This controller is available only after you enable Multistore feature in Preferences > General

That will be fixed in next version of module https://github.com/thirtybees/tbphpmailer/issues/1

I'll look into it. I will probably not add an option to modify the address, but I could add link to admin address page where they can modify it. This also bring out the (generic thirtybees) question what impact has modifying address on existing orders. I think that when we modify address, invoices for old orders will reflect that. And there may be some weird issues when you add/remove vat number...

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)