datakick

Native mollie modue is coming soon. It will have it's library dependencies namespaced / prefixed, so the problems I wrote above will not be present. The module is based on latest mollie version for prestashop backported to thirtybees - some functionality had to be stripped because they utilized ps17 features, but most of it survived.

Mollie module, like many other modules, depends on third party libraries. These libraries are part of module zip file. And module contains some specific version of the library. For example, mollie it can contains on guzzle v6.0 while stripe can contain guzzle v7.0. These libraries are load on demand using autoloader. The first module that is used will load its version of library. For example, if the stripe module hook is called first, then system will use guzzle v7. If the mollie hook is called first, system will use guzzle v6. What's worse, system can use different library versions for different requests. So, if the module works on not may depend on existence (and installation order) of other modules in the system. Crazy. There is nothing tb core can do to prevent this. We can implement some detection mechanism and warn user if there are two (or more) versions of the same library on classpath. But that's about that.

Anybody having issues with new version of stripe module so far? I personally encountered problem with P24 payment method -- sometimes stripe redirects customer back before the payment is marked as processed. Redirect handler then fetches payment status from stripe api, and fails because the transaction is not validated yet. In my opinion, this is bug on stripe side -- they should redirect only after the payment process is finalised, but sometimes they don't do that. My store successfully processed few P24 payments already, but yesterday there was one that failed. We will need to implement more robust validation methods (cron / webhooks) and not rely on redirects so much in the future. That will take some time to implement, though

inspect zip file if it's valid theme. Sometimes it contains doc + another zip file with actual theme zip file.

I personally don't like this kind of blanket/site wide solution. What if there is some module that actually want to prevent scroll events, for example some module that implements infinite scroll functionality? This could easily break it.

Webservice can use different types of authentication. By default, basic http authentication is used. But you can use ws_key parameter as well, simply pass it in the url: https://www.domain.com/api?ws_key=KEY

Sure, here: https://github.com/thirtybees/stripe/commit/4483f54e17742744b001800c91e1f90d80a20cd2

No, not automatically. If the payment does not contain required order reference code, then it will not be automatically linked. There will, however, be a list of received payments, and you will be able to link it from there

yes, the delay depends on cron frequency. If you run it every minute, the longest delay should be a minute. You can also set additional delay per queue, if you need some emails to be send later. For example, to decouple order confirmation email and bank wire email.

Plese file a github issue

Maybe your PHP server is behind reverse proxy, and the ipv6 address you are seeing is address of that proxy server. Check HTTP headers, one of them might contain original IP address. If that's the case, you will have to create an override or module to teach your installation to use info from that header.

It's not per month, it's 50 connected bank institutions at any given time - if you have Checking and Savings bank account at Bank A, and checking account at Bank B, you need 2 connections to synchronize all 3 bank accounts. Once connected, you can fetch transactions as often as needed, for example every 15 minutes. There are some api limits, but they are quite high.

Yes. The process will be like this you will have to create a (free) account with gocardless - they provide bank integration you copy api keys to the module in module, you will choose bank to connect with you will be redirected to bank authorization page, whre you will have to authorize the connection. This will use standard authorization process from your bank -- sms, mobile app authorization, or whatnot. after you grant access, the gocardless will be able to retrieve data from your bank for 180 days thirty bees module cron job will periodically call gocardless api to return data from all connected banks after 180 days, you will have to reauthorize connection, or the data synchronization stops working with gocardless free account you can connect up to 50 bank accounts, which should be enough 🙂

around €40

Hi, I'm currently developing module for my internal needs, but I believe it could be useful for others as well. The module basically connects to your bank account, download transaction informations, and try to match them with your pending orders. If the transaction contains order id, and amount also matches, the order is automatically switched to Paid status. I have basic functionality working, but without any fancy stuff like configuration, transaction overview etc. I personally don't need it because I can access data in db directly, but it would definitely be needed for paid modules. So I'm just gauging interest to see if I should invest more time into this. Note that this module is able to work with more than 2500 banks, from EU mostly - https://gocardless.com/bank-account-data/coverage/

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