datakick

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.

That's true. If we were to remove the else branch, then Configuration::updateValue($key, $value) call would not remove html tags from values stored into configuration table. And that would be a HUGE security bug. In other words -- if programmer wants to store html code, he need to be very explicit about it. He must evaluate the context in which data are provided, and decide if it's safe to allow html code to enter the system or not. He needs to know where the data will go, and how it will impact rendered output of these pages.

Thanks @Jonny for the module. This is excellent support! I see that the modification of core Dispatcher class is needed for this to work properly. This actually points to a bug in the core. It assumes that controller with name 'category' is always core CategoryController, while in fact it can be controller in any module named 'category'. The same applies for other core controllers as well. This will be fixed in upcoming version of thirtybees.

Yeah, you are right. It still doesn't work. They use flock to lock the file, but it's not enough. Probably one of these kicked in (from php documentation): You should report this bug once again. And while you are at it, tell them to remove this 'cache' functionality completely. The extendCache method tries very hard to create var/paygreen/autoload.cache.php cache file. But they don't actually use this file at all - the module reads it in constructor into property $classNames, but this variable is never used for anything. This means that if we modify the file and delete: property $classNames constructor extendCache method and the call $this->extendCache we will end up with much smaller, faster code doing exactly the same. But without this race-condition bug. I'm attaching modified file, please pass it to the dev of the module when you report this issue. Autoloader.php

Yes, this is now in bleeding edge, and the maxmindgeoip2 module has been released as well. You can install it even in 1.1.0 and prior, but it will have no effect

Delete cache/class_index.php

There was a price rounding overhaul as part of 1.1.0 release. It's very likely your issue was solved as part of this overhaul. Upgrade. https://thirtybees.com/blog/prices-done-right/

Yeah, I was worried this will be the case. The only way such module can work is by overriding Dispatcher class. And tb one is very, very different to ps16/ps17 I'm afraid your only solution now is to modify the module. Or wait if @Jonny decides to support thirtybees in his SEO module. I don't think that's very likely, thought, as thirtybees users already have this functionality free of charge in the core.

Even if the module is compatible with tb (meaning you can use it instead of native url rewrite), you have to make sure this module can achieve the *same* url structure as you are using now for your products/categories/... I mean that all your current urls remains the same after you install the module. There could be few differences, so be aware

This module at least mentions the blog posts. But I'm really not sure how well will work tb native url rewriting mechanism. It can work, but it might not work at all... You should ask the author first before making a purchase

Let's agree to disagree here. This is not the place to discuss our believes in SEO. Back to your question: I don't think the module you mentioned will help you. It does not mention ability to rewrite blog urls at all, and the screenshots don't show it either. In fact, this module does pretty much the same thing as the build-in thirtybees url rewriting. If you want to remove the ids, you will have to rewrite the module. Look for moduleRoutes hook to change the way urls are composed. Then you will have to modify front controllers, and change the way it processes route parameters (since these will not be different). Then, you will have to implement some checks to avoid duplicate urls, make sure it works correctly in multi-lang environemnt, etc... My estimate is 4 hours of work minimum, for experienced developer. But it can easily take much longer... So this quest for pretty url might cost you ~ 200-400eur