datakick

not thirty bees core / theme related

That's true, chex does not have such functionality. Newest version of stripe let you sort stripe payment methods, so that can help.

I'm afraid none. As far as I know, there's hardcoded logic for PS_OS_CANCELED and PS_OS_ERROR statuses, and that's it. https://github.com/thirtybees/thirtybees/blob/6c9db328c27a93be59b7ed8d32cef8deb0169105/classes/order/OrderHistory.php#L174-L217

There is some (probably module/override) code that access this property on front-office controllers. You have to figure out what code is that, and fix it -- it should probably work with back-office controllers only. Look at stacktrace for this error to figure out what code attempts to access the property.

First line should look like this: public function &__get($name)

At the time of payment order does not exists yet. We could store cart id there, though.

Latest module of stripe uses api 2023-10-16 -- if you use stripe only with thirty bees, you should set this version as default in your stripe dashboard

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.