datakick

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

Out of curiosity, why are IDs in url such a big deal for you? Friendly urls have zero impact on SEO. Google and other engines really don't care at all They are interested in content only. The only reason to have friendly url is type-in traffic. And be realistic -- nobody will ever going to type in url to your blog post into the address bar...

I don't agree. The export functionality should export theme with the current settings. How it looks now, not how it looked at the time when you installed it. Example: You define new product image type named 'homepage-featured-product'. Then you modified index.tpl file and displayed your featured product using this new image type. Now, when you export the theme, you want config.xml to contain this new image type. Otherwise the featured product would not be displayed correctly. The same applies to hook positions, installed modules, etc. This is ideal tool for transfering your work/modifications from one environment to another, say from your staging server to production one.

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

hmmm, not really. When I investigate some bug, I need back office access in order to upload new (slightly modified) version of the module in order to receive debug information (of course, I do it in a way that only I can see that, simply by adding condition to my IP address) I run series of sql queries using Advance Parameters > SQL Manager after every test I have to switch from log to another (mail logs, error logs, system logs, console, network tab,...) I can do this pretty fast when I'm hands on. I mean, I'm usually done investigating in 5-10 minutes. If I were to navigate you over skype call and tell you what to do, it would take hours. If you want *free* help, you don't get to dictate *how* should people help you.

It's really hard to tell. If you give me access to your back office, I can probably tell you more

Thanks, I'll look at your module sometimes. Maybe I'll borrow some of the code from there

At the moment it's not possible, because the product name is treated as a string, and escaped properly. For this to work, I would have to modify the (minified) js code and remove the escaping. Then you could enter any html content you need. It does, however, have slight security risks. If you need this, I can prepare a special module build for you with this modification. And then you can test if you can achieve what you need.

But for the multi-stores, these checks make the code works correctly. What should we strive for -- the speed, or correctness? For me, this is no brainer. If we were discussing this in 1.4 I would probably say don't implement multistore. But we are not there. Thirtybees inherited this feature, so we have to support this.

New version 1.1.0 Added new test: Finds records that are not associated with shops Inspired by this thread. This new test goes through (most) multistore enabled records in the system and verifies that for every record in primary table there exists at least one record in primary_shop table. If no such record exists, it is most likely a bug. You should either associate the record with some store, or delete it completely.

This is either caused by multiple languages, or by multistore. Also, I don't understand why it exports *all* hooks, and not only positionable one (the one that starts with display...) Let's create an issue for this https://github.com/thirtybees/thirtybees/issues/1103

There is no place in the core that queries information schema in this way. This must come from some module. My guess would be some module that generates custom order reference numbers, and it probably can't handle situation when there are no orders in the database yet...

This really peak my interest, so I tried to remove some tb_group_shop entries. And indeed, all functionality I have tested worked correctly. Well, it worked. I can't say it worked correctly, since it should not have worked 🙂From this point of view, one might conclude that this table is indeed 'too much'. On the other hand, there are users that uses multistore who actually need this functionality to work. For example, the commit above was provided by community member, because he needed the option to show only customer groups associated with particular shop. Overall, it looks to me that there are plenty of forgotten places in the codebase where group/shop association check is missing. That should be fixed. Of course, this will create problems for you guys that migrated from 1.4 -- but the problem is there even now, so it's not a big deal. The fix is easy, and I don't think there are many uses that don't have entries in group_shop table. I will create github issue so this not gets forgotten. I don't think it will be fixed anytime soon, though https://github.com/thirtybees/thirtybees/issues/1102

I think you are over complicating the task at hand. What you really want is to force your customers to choose attributes. You don't need to create any special attributes values, or create dedicated default combinations for your products. That's just crazy. And a lot of work for something that should be pretty simple to do by modifying your template. Also, this *virtual* combination would make other tasks in your store a lot more complicated (data import, export to google merchant center,... ) Here's something to get you started: Edit file product.tpl in niara theme, find this code {if ($group.group_type == 'select')} <select name="{$groupName}" id="group_{$id_attribute_group|intval}" class="form-control attribute_select no-print"> {foreach from=$group.attributes key=id_attribute item=group_attribute} <option value="{$id_attribute|intval}"{if (isset($smarty.get.$groupName) && $smarty.get.$groupName|intval == $id_attribute) || $group.default == $id_attribute} selected="selected"{/if} title="{$group_attribute|escape:'html':'UTF-8'}">{$group_attribute|escape:'html':'UTF-8'}</option> {/foreach} </select> {elseif ($group.group_type == 'color')} and replace it with this {if ($group.group_type == 'select')} <select name="{$groupName}" id="group_{$id_attribute_group|intval}" class="form-control attribute_select no-print"> <option value="0" selected="selected" title="{l s='Choose'}">{l s='Choose'}</option> {foreach from=$group.attributes key=id_attribute item=group_attribute} <option value="{$id_attribute|intval}" title="{$group_attribute|escape:'html':'UTF-8'}">{$group_attribute|escape:'html':'UTF-8'}</option> {/foreach} </select> {elseif ($group.group_type == 'color')} This code changes the dropdown attribute selector: adds new item named 'Choose' with value 0 -- non-existing attribute value id make this item pre-selected by default using selected="selected" attribute remove selected="selected" attribute from default attribute -- inside {foreach} cycle I've tested it, and it works quite nice. If you are using other types of attributes (color / radio) you will need to modify these as well, in similar manner.

I personally prefer docker containers. That's the best way to ensure my production environment is the same as my dev environment -- the same database version, the same php version, the same services (cron, task queue, elasticsearch, redis). With docker-compose I can build and deploy the same stack anywhere, within few minutes. If there is a bug in my production environment, I can (almost) always reproduced it my testing environment. Because they are identical. Of course, there's a learning curve...

I take it back. This commit is not a fix, it is a brand new bug 🙂 The proper fix would be if ((int)$this->id && !Currency::checkPaymentCurrencies($this->id)) { ... }