datakick

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)) { ... }

They already fixed this https://github.com/PrestaShop/cheque/commit/1401149dbb6fa08e65c2b43d9f88df970635a8f8

This was caused by this commit: https://github.com/thirtybees/thirtybees/commit/469a569f8c98660280e3921ae277fede7d9dedc1 I would say it's not a bug, it's an expected behaviour. The group list was correctly restricted according to current shop restriction. If customer groups are supposed to be displayed in some shop context, they must be enabled for that context. In this case, they weren't. Only one group was associated with the shop. Whether this was caused by faulty migration from 1.4 to 1.5 is irrelevant.

It's very strange that these missing shop associations would not give you any errors or issues. But sure, it's possible you have used your shop in a way that such a bug wasn't encountered. But that doesn't mean it was correct. In fact, that itself should be considered a bug -- since these groups were not associated with your shop, they shouldn't be visible, or usable at all. Definitely non on frontend. And in many context on backend as well.

I don't understand what the problem is. Obviously, when ps14 shop was migrated 1.5, only entries for shop 1 were created in all *_shop tables. That's because, at the time of migration, only one shop existed. So this migration seems totally legit to me. If your client created some additional shops afterwards, but failed to associate customer groups with these new shops,... then it's a human error, not a system one. Or did I miss anything?