datakick

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.

I'm not really familiar with the iquitcontenteditor module, but it looks like it doesn't allows you to pass any custom parameters to display hook. And you really need to pass review id. So I'm afraid this module will not work with this revws hook

Thanks for the confirmation. My test also suggests that all issues are solved, so I've officially released 3.0.4. Hopefully not many people upgraded to faulty 3.0.3 yet.

@cprats could you please test this new version of the module fixes the problems? Thanks blocktopmenu-3.0.4-pre.zip

Indeed, the new version of blocktopmenu doesn't work correctly. You should downgrade to version 3.0.2

Did anyone had a chance to test the release preview version?

Both methods must work. If you could test both module upgrade, and fresh installation, that would be great.

New version (release candidate): SCA support Here's a pre-release candidate of stripe module that implements support for SCA - new European regulation coming into effect on September 14, 2019. If you are collecting payments from EU customers, you will need to upgrade stripe module, otherwise you will see a huge increase in card declines. The changes to the module are substantial -- 3 core checkout flows had to be rewritten from scratch using new Payment Intent API. Therefore, before I release this version officially, I would like to ask you all to test it thoroughly. If you find any bug or problem, please report to this thread. Download: stripe-v1.7.0.zip

Ohh, you are right. This package contains constant (currency id) that is specific to my setup only. I will need to come up with some better package installation process -- ask user for information and use it to replace hardcoded values. Meanwhile, I've uploaded new version of this particular package that depends on currency with id 1. That one is more likely to exist that currency with id 3.

Yes, it's possible.The trigger part is tricky one -- since this changes with time, the only way to implement this is using measure - for every product in your specific category track if it is available or not. This is sql to define such measure: SELECT ps.id_product, 1 AS is_available FROM tb_product_shop ps INNER join tb_category_product pc ON (ps.id_product = pc.id_product) WHERE pc.id_category = 5555 AND now() > ps.available_date This will return list of every available product in category with id 5555 With this measure in place, you can use trigger Measure value changed that will react when the result of that sql changes. When some product in category 5555 becomes available, sql result will include this product, and rule will be triggered. You can now do whatever you want. To remove product from category, you will have to use custom sql action and execute this sql: DELETE FROM tb_category_product WHERE id_product = {id} AND id_category = 5555 Where {id} is a placeholder. You will need to bind this to product ID: You can have a look at my demo account, I've create this rule there (for category 2, not 5555)