datakick

I've just officially released this module, you can find it here: https://store.getdatakick.com/en/modules/mail-queue This module requires thirty bees 1.5.0 or newer This thirty bees module can help you manage your outgoing emails easily. Instead of sending emails immediately, module will store them inside one of the mail queues. You can create rules to determine which queue will be selected for every email. Module cron job will later attempt to deliver emails from queues. This alone is a great performance improvement. Sending emails can take a lot of time. Because it is synchronous, it blocks response. By offloading this task from customer initiated request to backend thread, you will make your front office much faster. But there are other benefits of using mail queues: Failure recovery When attempt to send send email fails for any reasons, module will retry it later. Without mail queue moule, such failure would raise error/exception and would broke functionality. For example, email sending failure could block displaying order confirmation page, or processing payment. This will never happen again Email preview You can click on every email in your queues and see the content, download attachments, etc. You can easily see what will be, or what was actually sent to your customers. Sending delay You can specify initial delay -- minimum amount of time the email will sit inside the mail queue before module will attempt to deliver it. This can be useful, for example, to decouple emails - Order Confirmation and Bank wire payment emails are usually send together. You can create dedicated queue for bank wire payment email and delay these emails by few minutes. Manual moderation When you pause email queue, module cron will not send emails from that queue automatically. You can manually review all pending emails, and delete or send them. This can be useful tool to fight spam. You can create paused queue, and define conditions like "put email into this queue if it contains text 'online casino' or 'viagra'" Audit log You can set retention policy per queue. Sent emails can be immediately deleted from queue, or kept forever or for specified amount of days. Mass emailing Some modules can send many emails at once (for example email marketing modules). If implemented improperly, such task can timeout. With mail queues it will not, because saving emails locally is much faster than actually sending them. You can put hundreds or even a thousands of emails into the queue in one requests. Throttling You can set sending rate per queue, for example to send max 3 emails per hour. This can be useful -- sending many emails at once can put your domain on blacklist. By throttling outgoing emails you can prevent this Different email transports You can set different email transport for every queue. With this, you can use dedicated SMTP server for your transaction emails, and different one for you marketing emails. When your marketing emails are marked as spam, it will not have any impact on your transaction emails reputations.

I strongly believe the problem is not in the system, but somewhere in your tooling. Thirty bees core uses config.xml files inside module directory as a cache mechanism, in order to avoid loading module main php file into memory, just to find out basic information about module (name, version, etc) This cache file is loaded only when following conditions applies: config.xml file exists config.xml modification time is older than modification time of module primary php file related code https://github.com/thirtybees/thirtybees/blob/ef47fe6bc88d7cea713e27f91d6f469695b20217/classes/module/Module.php#L798 So, if you download new version of module from thirty bees repository, or if you upload zip file, or upload files directly using ftp client, then module main php file should be overwritten --> its modification time should be newer then modification time of config.xml --> config.xml should not be read but should be regenerated. This is how it behaves on all system I've seen so far. I believe you that you have these problems, but I don't think the issue is in the code. The situation that you are describing could happen, for example if you change modification time of config.xml to the future if ftp client you use to upload files incorrectly set modification time if you have some (security or whatnot) tool that touches files and thus changes their modification timestamp

Thanks everyone that tested this version. Because no major issues were found, I've just released these changes officially as version 1.9.0.

The code goes through following process: if the post request contains gift field with value 1, then gift_message must be set and valid -- non-empty string. So either make sure that gift input field is not present or is set to 0 or that post contains dummy gift message - for example <input type="hidden" name="gift_message" value="dummy"> or override ParentOrderController::_processCarrier and remove this condition

Let me start by saying that this is, most likely, caused by some module. But it is also possible that this is a side effect of hack attempt, especially since this is related to smarty cache. If attacker discovers an SQL injection vulnerability in your store, they can use it to read and write arbitrary data to your database - they can construct custom PHP script and save it inside tb_smarty_cache table. Old versions of thirty bees (<1.4.0) would then execute this custom script when the page is displayed. That's extremely dangerous, because it elevates SQL injection vulnerability to absolute PHP code execution. Because you are on 1.4, you can at least be sure that this attempt was blocked. However, the sql injection vulnerability might be there, so it's essential that you investigate further and find the root cause of this.

You can simply log in to your paypal account and check if the payment was indeed processed. If so, there was some problem during cart to order conversion. If there is no payment, then it can be scam (or simply confused customer)

Carts are converted to orders only after successful payment validation, and that depends on payment module used. And yes, sometimes validation process can fail, and there is dangling cart that has been paid but not converted.

I've fixed the bug and released new version of this module. You should be able to download see it in your back office

There's a bug in this module on line 217. It should read $this->_clearCache('blockadvertising.tpl'); Obviously, nobody is using that module, or at least never bothered to report this error on github.

APCu is most likely the most performant option, because it caches data directly inside php server shared in-memory object cache. There is no overhead to connect to cache server like in the case of memcache or redis. However, there are some things to consider: storing data directly inside php server can be somewhat risky. PHP server process can get pretty big over time. And when your server is low on memory, operation system may choose and kill your php server because it hogs all the memory. This is just hypothetical cache is not distributed. If you need multiple store fronts (== multiple php servers behind nginx proxy for load balancing) than this cache will actually cause a lot of headaches. For multiple php servers, use redis or memcache

Yes, this library introduced backwards incompatible changes. Version 2.8 used Mobile_Detect in global namespace. Since version 3.x, the classname was moved to \Detection\MobileDetect Old version 2.8 do not work on php7.1 and newer, so we had to update it You have to fix the module code that depends on old version of library. In fact, you should rewrite the module to use Context::getDevice / Context::isMobile / Context::isTablet

I've attached new version of module to the first post of this thread. Couple of small issues were fixed. I've also implemented two new payment methods - WeChat Pay and Sepa Direct Debit to test how flexible the new system is. I'm happy to note that it's quite easy to implement the methods now - it looks something like this: https://github.com/thirtybees/stripe/commit/a184785c0475310d7f72d2736d43b0c7e13fb219

Apple pay is displayed on embedded Stripe credit card form payment method. It is displayed only on devices that supports it. On Stripe Checkout, it should be displayed as well, if device supports it.

Yes, I believe it is. I also deployed it to my store already

Please see

Stripe is deprecating old source api soon, so we had to rewrite the module, and migrate all payment methods to use new PaymentIntents api. The rewrite is quite significant change, so I'd like to ask everyone to help with testing before we officially release it. This new version also fixes couple of old bugs (related to webhooks, refunds, etc) stripe-v1.8.2.zip

You have to use correct name for your override, otherwise system will not use it: class Module extends ModuleCore { ... }

Thanks for letting us know. I use stripe, but I don't use these payment options, so I wasn't aware about the api deprecation. We will investigate the effort needed to fix the module. If possible, we will fix it.

simple, update your thirty bees version

Module blockshopreviews is not compatible, it depends on old version of mobiledetect library. Disable this module, uninstall it, or fix it.

these are fields from core, not module. Please file enhancement request issue in github.

It's not commented out. If you beautify the result content, you will get this /* <![CDATA[ */ ;window.addEventListener('load', function () { if (typeof window.cookieconsent !== 'undefined') { window.cookieconsent.initialise({ "position": "bottom-right", "static": false, "theme": "edgeless", "palette": { "popup": {"background": "#004c99", "text": "#ffffff"}, "button": {"background": "#f1d600", "text": "#000000"} }, "geoip": false, "content": {"message": SOME MESSAGE FROM THE COOKIE MODULE} }); } }); ;window.dataLayer = window.dataLayer || []; function gtag() { dataLayer.push(arguments); } gtag('js', new Date()); gtag('config', 'G-R6CE3JK4G6'); ;(function () { function s() { var e = document.createElement('script'); e.type = 'text/javascript'; e.async = true; e.src = ('https:' === document.location.protocol ? 'https://' : 'http://') + 'cdn.fraudlabspro.com/s.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(e, s); } (window.attachEvent) ? window.attachEvent('onload', s) : window.addEventListener('load', s, false); })(); /* ]]> */ The all comments are closed. There is, however, syntax error in this javascript snippet, related to text SOME MESSAGE FROM THE COOKIE MODULE

Note: if you don't see core updater in the list of modules, you probably don't have tbupdater module installed. This module used to be used to download other thirty bees modules. Since 1.5, it is no longer needed. But on older tb version you still need it. You can easily install core updater from github repository - https://github.com/thirtybees/coreupdater/releases , and then update to 1.5.

I've already replied in the other thread you have created for this very same problem.

Unfortunately it's quite common that CSS or JS from one module impacts other modules. If you are using CCC, try to disable it -- sometimes that helps. If it won't help, then you look into your browser console, look for any errors or warnings.