datakick

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.

Weird. If you PM me access to your back office I can have a look

cache?

There's a bug in in beesblog module - it emits invalid metadata to the page. To fix this, you will need to modify templates and apply this fix

Configuration::updateValueRaw method exists in core. If your server claims it doesn't exists, it's probably caused by badly-written override, or some manual modification to configuration.php file.