datakick

the same fix applies, but this time replace all occurrences of dropDatabase with dropDatabaseCustom

I can't reproduce this issue. I've just tested on my demo account and it seems to be working correctly

Of course it should work with every OPC module, but unfortunately it's not that simple. It's because payment modules are (historically) based on hookPayment which directly returns html code. This html code is supposed to contain one payment button to submit the standard checkout form. And it's very hard to reuse this html code inside different flow, like in OPC. For example, while in standard flow click on payment button submits/completes the checkout, in OPC it usually only selects the payment method. Most OPC modules works because of some black magic. They usually render the original html code inside invisible section of the page, and in the same time they parse the html and scrape information (payment logo, text, etc). They then render their own html content using these information. When you click on final submit button, they must also perform virtual click on the (hidden) payment button. This is very complicated process, and it doesn't work in 100% of the cases. In this particular case, @haylau uses OPC module that doesn't do this job well enough.

Search and replace all occurrences of createDatabase with createDatabaseCustom in module php files

Definitely not. I was just answering your question why this happens. It doesn't mean that this is correct behaviour 🙂 Moreover, the two installation methods -- installing from zip file and installing from remote repository -- should be unified and work in the same way. Right now they use different code with different results. For example, if you update module from thirtybees repository, its directory is deleted and then re-created from scratch. This means that *any* assets that module might store inside its directory are lost (for example uploaded files). I'll create new github issue for this EDIT: actually there is already an issue for this: https://github.com/thirtybees/thirtybees/issues/522

Because the code to extract zip archive intentionally do that 🙂

That's weird. I've tested login functionality right now and it works. Could you try in incognito mode?

Well, I don't see what apache brings to the table. Nginx can take care of url rewriting, ssl, gzip, serving static assets, etc. There's nothing left for apache to handle. Unless you need some special mods (mod_security, etc). I don't need those, so I'm perfectly happy to not use it.

This problem is already fixed. If you want to continue testing, replace the `define` with `const`, as shown here

You can test using SCA test cards: https://stripe.com/docs/testing#cards

you mean earlier version of stripe module? That does not support SCA, so you wont be to receive payments past September

I've just retested the functionality on standard tb checkout flows (standard 5-step, standard one page checkout, advanced eu one page checkout) and it works fine. You can test it on my demo account as well

I don't think this is an issue with this module. I bet you are using some third party one-page checkout module, aren't you?

I don't understand at all what you are trying to say. Please elaborate

Nobody reported any issues or problems, so I'm going to officially release the new version

Well, it's not solved, it's just suppressed 🙂 But don't worry, this will be fixed in 1.1.x

Track here: https://github.com/thirtybees/thirtybees/issues/995

Have you updated your php version recently?

Do you have any cron tasks in your cronjobs module? If you do, then you need to setup external cron, otherwise these tasks will never run. What this external cron setup does is quite simply - it regularly opens specific url on your server, which gives cronjobs module opportunity to execute its tasks.

Oh, it's not related to this problem then. This is an issue with uploaded images that are stored inside /modules/<module>/ directory (instead of /img/ directory). When module is updated, its directory (including all upload images) is deleted and recreated from scratch. The root problem is in badly written modules, they need to be fixed to store their uploaded content outside of /modules/ directory.

900? Into which module did you upload 900 images?

You should double check that you have you modified the right template files (there are two you need to fix). Also, see my previous comment about theme templates that takes precedence over module templates. If you are sure that you changed the right files, then the issue must be in cache. Clear your server cache. If you use cloudflare or similar CDN, clear those as well

Simply file normal issue

Sure, that's what github is for. To track known bugs and enhancement requests

This is known bug, still not solved 😞 When updater updates a module, it removes the entire directory, and then unpacks the new module version. This deletes all files inside the module folder. Proposed solution is to update these modules so they do not store their content inside module directory. For more info, read here