datakick

New version of coreupdater module was released yesterday, and it contains one new functionality I'd like to talk about a little bit: Database schema comparator and migration What does it mean? It means that core updater will now look into php codebase and extract metadata from object model classes (like Product, Customer, or Order). These metadata describes exactly how database should look like -- what database tables should exists, what columns should they contain. It describes primary or foreign keys, column type, default values, collations, etc.. Core updater will use these collected information and compare them against your actual database schema. And if there are some differences, it will report them. And it will also allow you to fix them. This essentially makes php codebase single source of truth in regard to database structure. When you install your system from scratch you shouldn't see any database differences. But those of you that are running your thirtybees system for a long time now will see a lot of differences. It could happen for many reasons we developers tend to forget about implementing respective sql migration when we change php code when we actually implement such migration script, it can contain errors. After all, php devs aren't usually mysql experts also, some modules can change database schema for their needs Why do these differences matter so much? That's because PHP code operates under some assumptions. For example, it expects that order reference code can contain 11 characters. The php code that generates unique reference code for order can fail terribly if the actual database column can store only 10 characters. The error can occur right there during reference code generation (then it's easy to find). But it can happen much later. With these data consistency issues it's hard to figure out how they happend, and how to fix them. By aligning your database structure with expected database schema, you are much closer to (my favourite) vanilla thirtybees installation. Thirtybees core code will run more smoothly in such environment. I'm not saying it will not run OK on modified database schema, just that there can be some very strange behaviour sometimes. How to use this new tool Please be aware this is experimental feature, and requires some database knowledge. It's not very user friendly. And some messages will probably scare you -- but that's intended behaviour. It is very powerfull tool, but we should use it very carefully. There is new tab named Database schema (for developers). This tab will display you all (relevant) database differences. Note that thirtybees core needs to support this functionality. At the moment, this is supported in bleeding edge only. In current version 1.1.0 or older, this tab will simply inform you that the database comparison functionality is not supported. So, if you want to test this new functionality, please migrated to bleeding edge. This is how the list of database differences looks like. You should review all differences, starting with those marked as critical While it says critical, the reality is usually not so grim. Obvisouly, missing columns or tables are indeed very serious issues, and you should fix these immediately. But different column type is not such a big deal. All database differences can be fixed. You can simply click on Apply fix button to adjust database. Please make sure you understand what this means!!! Some database differences can be actually valid and wanted. For example, some module might have changed database structure of core table in order to provide some additional functionality. *Fixing* this table back to original state might break the module. One such module is *Multiple feature values* -- this module drops unique key for one core database table in order to actually save multiple feature values into the database. If unsure, please ask here -- it also gives us opportunity to learn more about different type of customizations. And some video:

I've just released new version 0.6.4 -- there was a bug related to vatnumber module / vat exemption feature. This should be fixed. Also, new settings option was added - you can now choose if the cart should float during scrolling, or not.

@x97wehner please file an issue for this on github. Otherwise it will be forgotten again. Forum is really not the best place to report bugs. Edit: I have created the issue myself: https://github.com/thirtybees/thirtybees/issues/1115. The fix will be in bleeding edge shortly

I've narrowed this down to this issue: https://github.com/thirtybees/thirtybees/issues/1114 Doesn't look like 1.1.x injection, though. So it might not be fixed in upcoming release yet.

It would. There's actually a bughancement request for this https://github.com/thirtybees/thirtybees/issues/1024 already

do you mean media servers?

Hello everyone, it's been a while since the release 1.1.0, and it's time for another one. Version 1.1.1 should be released by the end of November. This new version is all about code quality -- there aren't many new enhancement or dazzling features. Instead, a lot of bugs and errors were fixed. For more information about this release, you can read here. Right now, I would like to ask you all for cooperation with pre-release testing and bug huntint. If you can, please use core updater to forward your store to latest bleeding edge 1.1.x, and test your store properly. If you find any bug, please report it to github. If the bug is an newly introduced problem, or if it's a seriousone, we'll try to fix it before the official release. Other bugs will be tracked and fixed in the next version(s). Thanks in advance for helping this project!

Yes, it's part of 1.1.x. But I found and fixed it only after you raised this issue. Thanks for that.

Looks ok. Anyway, this settings is for FPC. I don't think you have it enabled

No, not yet

That is a good question. I have encountered this behaviour a few times already. - there used to be an exception for hookBackOfficeHeader -- this hook was intentionally called for every module, even disabled one. This was fixed in 1.0.8. I never really understood why this was enabled in the first place -- my suspicion is that ps guys implemented this 'feature' for their onboarding/tracking module - even if the module is disabled, it is sometimes instantiated. This means that module __construct method is called by php runtime (and also the module file is loaded, which provides another opportunity for code execution). If module constructor contains some side-effect code, anything can happen. There are multiple reasons why (even disabled) modules are instantiated. Some of them can be fixed, like this one. - overrides -- when you disable module, all its overrides stay put, and continue to be executed. It's up to module developer to check whether the module is enabled/installed or not. This is obviously a bug.

hookActionXXXUpdate is called when object model properties are changed. So, when you save Product from your back office then hookActionProductUpdate is called. Unfortunately, at this point, only product properties has been saved to database. Category associations weren't saved yet, because they are not property of an object. Controlelr will save them a littile bit little bit later. That means your Product::getProductCategories(intval($id_product)) is probably retrieving old set of categories

try to apply this fix, hopefully it will solve the issue: https://github.com/thirtybees/thirtybees/commit/70f02721bc8ffae1e82c34a1b160ac3aee856cf8

what does your url look like?

Works fine for me: However, I'm running on 1.1.x -- so maybe that's the difference. And, of course, if you modified routes for other pages, that can make a difference as well.

Try this one: {categories:/}{manufacturer:/}{rewrite}

Google analytics module is for tracking - it adds google tracking code to your pages. Google Analytics API is for retrieving collected infromation from google servers back to your store. Without this module, the dashboard will still show zero

If you are trying to use value 7100640000 as a product primary key then the mysql will probably complain - id_product column is defined as unsigned int, which can store max value = 4294967295

That's not an error. This dashboard shows data fetched from your google analytics account -- for this to work, you need to install and configure Google Analytics API module.

Clear all caches. Browser, server, and cdn (cloudflare??)

The thing about multistore configuration is that there exists multiple layers of configuration. for specific shop for shop group for all shops When some configuration key is not found for specific shop, it will fall-back to more generic settings. In your case, you have configuration on All Shops level set up the same as for your shop B, and (some) configuration key for specific shop A weren't set up correctly. So, thirtybees merged these settings, and resulting mix was not valid stmp configuration. The same probably happens with logo

Are you asking when the next release will be? Probably by the end of this month

Then you have some override installed, or modified core code. There is actually a test that verifies behavior of this method, and it runs on every git commit.

Let's fix this newly discovered bug, where we are at this topic: https://github.com/thirtybees/bankwire/commit/51e3afb916fdc83111628ca04de254dbbc0a2674

No, it's not. I've just tested it. I tried to save this string: Hello <strong>there</strong> With false, it's saved as Hello there With true, it's saved correctly: Hello <strong>there</strong> Note that you have to re-load the page, because this module (like most of them) shows last $POSTed value, instead of what was actually saved into db. That can be, of course, considered as another bug. This is probably why you thought it is always called with `true` parameter.