datakick

PHP 8 is not supported. I guess this will be the source of the problem.

Did the ajax request failed, or just took a long time to process?

In my opinions these are indeed critical. System expects that database columns can store more data than they actually can. There are two possible things that can happen when system tries to store longer strings data truncation -- entered data will be silently truncated by the system. Loss of user entered data is a serious problem, imho an error can be thrown -- sometimes data are not truncated, but an actual exception is thrown. For example, see this issue: https://github.com/thirtybees/thirtybees/issues/1056. Yes, these are serious issues, hence the critical flag

This is actually a first time issue only. This was always a problem with bleeding edge. When you updated your store to bleeding edge, we never actually saved information about the exact git commit that 'bleeding edge' referred to. Without that information, core updater couldn't really check what files were modified. It always used files from latest stable version (1.2.0), and compared files on your server agains them. Obviously, any and all modifications to core files performed between 1.2.0 and git commit that was used for bleeding edge would be marked as 'modified by user'. Which is not correct. From now on, core updater will store the exact revision inside _TB_REVISION_ constant. _TB_REVISION_ can contain either specific tag (1.2.0), or exact git hash like a09146c3db421e1604dd45dc8d63925c4aee7c4f. Core updater can use this information to compare your files with proper git commit.

I have uploaded new version of module (attached in the first post), which fixes some issues with 500 errors logging, and also with the incompatible modules

Nah, theme switching will not create such mess. If I remember correctly, back in the day when we were updating from 1.0.3 to 1.0.4 manually, the instruction was to remove these modules from filesystem. But that did not remove references in the database, obviously. I had problems with these modules once, so I had to create consistency check module. That can help you to get rid of these easily.

Yeah, that's unfortunate. I'll extend the core updater module to automatically remove reference to these non-existent modules from db.

This table is created during module update / installation. Thirty bees automatically executes module update sql scripts/php scripts when the newly uploaded version is higher than current version. My guess is that you had merchantsedition version on core updater installed previously. That module has version 2.0.0. When Overriden by tb version 1.4.0, thirty bees decided no to apply update scripts.

@Mark thanks for the info. Could you copy the error message and send it to me via PM. Or, alternatively, give me back office access so I could test? Thanks

The main issue I have with this concept is the different level of support of these elements/components by themes. Third party commercial themes would not come with templates for these components at all. Some themes might support only subset of components (maybe new components were introduced after the theme was released). The only way I can see this to work is for every component to have some default, theme agnostic, template. And this might be hard to do, because such template would not be able to use any framework css, any framework js,... Themes could, of course, override these default templates. But even if they did not override them, the components would still work to some extent. Is this aligned with your vision?

utf8 encoding is basically utf8mb3, and as such it can't store some utf8 characters. While most merchants will not encounter any issues with this, it's still recommended to update to utf8mb4 to be sure no data will be lost when saved to database. Most importantly, without utf8mb4 encoding, you can't enter emojis into your product descriptions. And we can't allow that. /s

Hi everyone, I would like to ask your for your cooperation with testing new version of core updater module. The module had an extensive overhaul in order to support multiple php builds, initialization callbacks, new server api, improved logging and error handling, etc. This new version allows you to update to latest bleeding edge (current core update does not allow this), and latest stable version (currently 1.2.0). Before I release the module officially, it would be very nice if somebody could help me test the functionality. If you have test server, local installation, or similar, please download this version of module and try updates. Please report any issues here, or via email. Thanks in advance coreupdater-wip.zip

https://github.com/thirtybees/thirtybees/commit/d8fc1d5d015c18a062e55066b6b98d35be50e63d

This is definitely something that would be interesting. I always thought that thirtybees/prestashop is not a real MVC because there is no real (V)iew layer. Your idea with reusable elements sounds quite interesting. However, I'm not sure how easily that could be implemented so they would work with all themes. Do you think it's possible?

Are you saying that the same product sometimes has shopping option and sometimes not? Or are you saying that random products does not have shipping options at all?

Hi @SeaSky, unfortunately this is not possible with the current module. This kind of data are not exposed Petr

It works properly, or at least it works as it was designed. There are couple of gotchas. make sure you 'Save direct traffic' enabled, otherwise your testing will not work. When you test by entering url into browser, it's considered direct traffic -- there's no referral http header. When you define request uri include key, you need to surround it with '%', as it is basically a sql subexpression. For example, if you want to attribute links with &referrer=123, you should use '%referrer=123%'. You can't simply write 'referrer=123', because it would not match -- the resulting sql looks something like this 'AND url LIKE "referrer=123"' Every time you change the referrer, you should rebuild the index. And you need to refresh the cache regularly, or the list will not display up to date informations. I must say, this is one of the most f*cked up feature in the core. It's way too complicated, depends on caches and other transient data, it's hard to set up and debug,... and nobody is using it. This it the prime candidate for removal, or at least to transfer to

What I meant with PHP is that module developers might not opt for using templates for some views. Sometimes it makes sense to generate html markup directly from PHP. For example, I've seen markdown interpreter module -- this allowed you to write your product description in markdown language, and the module converted it to html. For that, some php library was used, only customized to inject proper css classes to the output. Bootstrap css classes, mind you. Such module would not work properly on different tech stack, not without rewriting this php customization. With js -- a lot of modules use javascript to construct and replace DOM tree dynamically. In that case, bootstrap classes and building blocks are hardcoded inside javascript code. How hard it would be to rewrite this functionality to work properly with different css framework depends on how similar these frameworks are. For example, bootstrap's rows/columns abstraction are not always available.

Almost all frontend modules will be affected, if the new theme will be based on different technology stack. I assume some of them will be easy to adjust -- simply rewrite the views and use scaffolding blocks from new framework. For some modules it will be much harder, as it might require rewriting parts of js and/or php. It's not reasonable to think that module authors will do this kind of modifications, at least not until the theme is well adopted by the community. Will this new group provide technical support for all these modules, and help with views/js adjustments? If not, I'm afraid the new theme would not be adopted by general audience. Technical people like @wakabayashi might have no problems adjusting those few modules they are using for the new theme, but ordinary merchants wouldn't know how to modify module templates. They want something that works out of the box. Just my 2 cents

I don't think there is any such mechanism in the core. You might have some module installed (blackhole for bots, for example). Maybe some security apache module. Or the crawler could be flagged by couldflare or similar proxy you might be using

The module is quite nicely written. It logs a lot of interesting information if enabled. Make sure logging is enabled, and then look into Advanced Parameters > Logs, there might be some hints

One of the problem is module compatibility. You can create a nice new theme based on new technologies, like Tailwind, but you will have hard time integrating it with third party modules, as they expect the basic setup to be available - bootstrap and jquery. Which means that you will have to modify/adjust a lot of modules templates

The module depends on a PS settings that was never implemented in thirtybees. In prestashop there is a flag named PS_SSL_ENABLED_EVERYWHERE, because for some reason PS_SSL_ENABLED is not enough for them. In prestashop world, you need to as the system 'Please use SSL. Thank you, that's so nice that it works on standard front controllers. And now, if you could, please use SSL everywhere, even for modules controllers'. Anyway, my rant about this will not help much. To fix this issue, simply run this SQL command -- it will add this flag to configuration table (you might need to change tb_configuration and adjust db prefix). The module will use it, and the rest of the system will ignore it insert into tb_configuration(name, value, date_add, date_upd) values ('PS_SSL_ENABLED_EVERYWHERE', true, now(), now()); Note that this is not the 'true' compatibility issue. The module would now work with ps version 1.6.1.11 either (this is the compatibility baseline), but only with latest 1.6.1.24. But that doesn't mean we shouldn't do something about this. Quick search in github shows that a lot of modules are using this switch, so we might emulate it dynamically to make the life easier and avoid unnecessary problems.

Please PM me the module, I can have a look. It might be just incorrect checking

You can download my Consequences module and use it to block the outgoing email. I'm using it myself.