datakick

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

Also, note that some themes (usually the one based on community theme) have their own copies of these template files located in /themes/<theme name>/modules/beesblog/views/templates/front/post.tpl /themes/<theme name>/modules/beesblog/views/templates/front/post_list_item.tpl and you need to fix these files as well. In fact, if these files exists, you don't have to worry about template files inside modules directory. Files located in theme directory have precedence over files located in modules directory.

Simply go to https://github.com/thirtybees/thirtybees/issues and file new issue. I'm afraid this one will have low priority, though. There aren't many merchants having more than 50 cms pages in sub-categories

The problem was found. There's a new configuration option named Maximum level depth When you install this module from scratch, it is initialized to value 2. But when you upgrade from previous version it has value 0, thus displaying only top-level entries. When you add non-zero value it works as expected.