datakick

This can be set per country in Localization > Countries

This is very strong indicator that the culprit will be override override. Anyway, it's impossible to tell you what's wrong without this third-party module source code.

It's hard to explain, because it was a result of few different things. 1) Theme references to page Theme can reference different pages in its config.xml file to set appearance of left/right columns. This display layout settings is saved in tb_theme_meta table. But this table needs existing parent record in table tb_meta. There used to be a bug in 1.0.8 -- if tb_meta record didn't exists, then this layout display settings was not saved during theme installation. What this meant? Let's say that some theme specifies that page 'All reviews' of module 'revws' should be displayed with left column enabled. If you installed this theme before you revws module, then this settings would be lost during theme installation -- that's because this 'All reviews' is not yet known thirtybees at the time of theme installation. If you later install revws module, it's All reviews page will be displayed without left column. If you, however, first install revws module, than the result would be different. During theme installation, this page is already know, so the display preference would be stored. And this page would be displayed with left column. As you can see, we got two different outcomes, depending on order of installation. That's not good. So, in 1.1.x, there's a fix for this issue -- if the page is not known yet, new placeholder entry is created in table tb_meta. And that allows us to register display preference for this page, even before it's known to thirtybees. If you later install revws module, everything will work as expected. If you dont -- well, we only wasted one table row. 2) Missing entries for standard pages in tb_meta There were many missing records in tb_meta table for standard controllers. That meant that you weren't able to specify left/right display column. But also, you weren't able to specify friendly url for these pages. Again, in 1.1.x, these records were added to data pack -- if you install 1.1.x from scratch, all known controllers are represented by their tb_meta records. However, if you upgraded from 1.0.8, these controllers don't have these tb_meta records. But, because of #1, these records will be automatically created. But they are different than those created during installation. Most notable, these automatically generated records don't have friendly url assigned. 3) bug in robots.txt When robots.txt file is generated, system use data from tb_meta table to genrate disallow rules. This mechanism always contained bugs, but they manifested differently in 1.0.8 --> meta table didn't contain all records --> these missing records were NOT represented in robots.txt by respective disallow rules in 1.1.x migrated from 1.0.8 --> because meta table now contains automatically generated placeholder entries for standard pages (with empty friendly url) --> this results in Disallow / rules in 1.1.x installed from scratch --> meta table contains entries for all standard pages --> robots.txt have correct results As you can see, this is a quite a mess. By fixing 2 long-standing bugs, another one is created / discovered. Unfortunatelly, this is the reallity of legacy software.

Should be fixed in bleeding edge

Can't reproduce. If you are testing this using non-admin employee then make sure the permission profile has access to this functionality.

You should run this sql statement to (somewhat) align your database with 1.1.0 version UPDATE tb_meta SET configurable = 1 WHERE page IN ('addresses', 'address', 'authentication', 'cart', 'discount', 'footer', 'get-file', 'header', 'history', 'identity', 'images.inc', 'init', 'my-account', 'order', 'order-opc', 'order-slip', 'order-detail', 'order-follow', 'order-return', 'order-confirmation', 'pagination', 'password', 'pdf-invoice', 'pdf-order-return', 'pdf-order-slip', 'product-sort', 'search', 'statistics', 'attachment', 'guest-tracking'); This will show the missing entries in the list. Then, you can edit them and assign friendly url to all missing entries (except the module-* ones, and index) Then the robot generation will work correctly again.

Hmm, weird. Looks like some sort of data corruption. Could you run this sql and paste the results here? SELECT m.page, ml.url_rewrite, l.iso_code FROM tb_meta m INNER JOIN tb_meta_lang ml ON ml.id_meta = m.id_meta INNER JOIN tb_lang l ON l.id_lang = ml.id_lang WHERE l.active = 1 AND m.page IN ('addresses', 'address', 'authentication', 'cart', 'discount', 'footer', 'get-file', 'header', 'history', 'identity', 'images.inc', 'init', 'my-account', 'order', 'order-opc', 'order-slip', 'order-detail', 'order-follow', 'order-return', 'order-confirmation', 'pagination', 'password', 'pdf-invoice', 'pdf-order-return', 'pdf-order-slip', 'product-sort', 'search', 'statistics', 'attachment', 'guest-tracking')

Do you have url-rewrites set up correctly for your languate?

hmmm, what? I don't know the module and I don't know how the setup is supposed to look like, but this seems ok to me...

What does it mean "messed up"? Some error message, or what?

The first problem is known issue related to niara theme. There's pull request with the fix, kindly provided by @zen. You can apply the fix manually, or wait untill it's integrated into the next version of the theme. Regarding second issue -- I don't know what you mean. But please create a separate topic to discuss it -- and include more information

There is something very wrong, 8425 files is too big number. Even if I try migration from 1.1.x to 1.1.0 it would only modify around 2000 files. Mind giving me access to your back office, so I could test what's wrong?

I'm sorry, but these are just not reproducible. If I do this on my local installation --> it works. If I do this on my demo server running BE --> it works (by the way, did you test it on my demo server?) I even logged into back office of 2 clients of mine running on bleeding edge 1.1.x --> could not reproduce, it works. This means that the same code runs flawlessly on 4 installations, but does not run on yours... What should I infer from these information? Most likely it's an issue at your side. It may be something trivial, such as stale cloudflare cache returing old javascript file, or your browser cache. It can be some third party module throwing js error on your admin page, blocking other javascripts, including the one responsible for save buttons. Or it can be browser issue -- for example, I never tested how it worked on edge, since I don't have windows. It can be anything. If you give me access to your back office I might be able to aswer these questions. If you don't give me access, and are unable to provide steps to reproduce this problem on other installations, then there is nothing anyone can do to help you.

The problem is that there is some module with long controller name. Controller name is used to compose page key in form: module-<module_name>-<controller_name> for example module-paypal-plussubmit Thirtybees has limit 64 characters for these meta page entries. If (( module name lenth + controller name length + 8 ) > 64) then this error is thrown, because the resulting page key can't fit database column. This limit is obviously too small, we should increase it for the next version of tb. I've created github issue to increase this limit. Meanwhile, you can do this to fix the situation: Edit file classes/Meta.php and change size of the page property to 128: 'page' => ['type' => self::TYPE_STRING, 'validate' => 'isFileName', 'required' => true, 'size' => 64], to 'page' => ['type' => self::TYPE_STRING, 'validate' => 'isFileName', 'required' => true, 'size' => 128], You will also have to connect to your phpadmin and modify table schema (you might need to change table name tb_meta according to your database prefix): ALTER TABLE `tb_meta` MODIFY `page` varchar(128) NOT NULL;

You can click on column header to check/uncheck all

Looks really nice. I hope it will grow 🙂 First couple of small issues: Notice on line 255 in file /Users/tyruk/sites/thirtybees/modules/thememaster/thememaster.php --> [8] Undefined property: thememaster::$_html <div id="slogan"> is rendered inside <head>, it should be inside <body> You should not save Show blockcategories footer block and similar to configuration table, but derive current settings based on module hook. Right now, when I click not to show it, it correctly unhook blockcategories from footer. But I can go to modules and reset blockcategories module --> it once again shows in footer block, but your module claims it does not. Just a small glitch

Awesome. Is this opensource? Is there a github we can contribute pull requests?

This is normal when you have profiling enabled. Disable it in Advanced Parameters > Performance

Never hear of that one. If you test it, please share your thoughts with the community

We can fix only things that can be reproduced. I support lots of thirtybees shops, and not one of them has this issue. If you don't believe me, you can test it on my demo server account here. This problem is also not reproducible on vanilla installation. That all lead to conclusion that this is issue with your specific installation - some third party module, server issue, or what not. We are happy to fix bugs that can be reproduced, ideally on vanilla installation. If you can describe the steps how to reproduce the issue, it will be fixed. It is true that *serious bug* regarding ever-spinning button was commited into 1.1.x branch - bleeding edge. It affected only those people who upgraded to bleeding edge after Oct 8. (Note that the problem originally reported in this forum thread was NOT caused by that bug. Simply because the user did not run on bleeding edge, and also it was reported on Oct 7). This bug was discovered (reported to github) on Oct 21. I guess not many merchants updated to bleeding edge between Oct 8 and Oct 21 - I would assume such a serious bug would be reported sooner. The fix was implemented on Oct 21 -- yes, it took whole zero days to fix this, since it was reported. I don't know, but I don't think this is *blaming something else instead of providing solutions* Of course, this kind of bug should never made it into 1.1.x branch in the first place. But it did. We devs are only people, and things like this happens sometimes. Thankfully, this was never *officially* released, as bleeding edge is not an official release version. Sorry to hear that

No, this is a bug. Unfortunately not easy to fix -- that's because it's another entry item that can affect total price. I'll try to fix this issue in one of the upcoming versions. Thanks for reporting it I believe you are talking about modifying \Chex\Manager::getCart() method, right? Well, there doesn't exists any way to override this file. Thirtybees allow you to override only module primary file (chex.php), but it's not possible to override other classes in the module. So, unfortunately, answer to your question is "no, there isn't any better way to do this". You will have to apply this modification manually every time you update the module. And hope that I'll implement your request soon 🙂

That's funny and sad

Thanks for reporting this. Tracked under this github issue https://github.com/thirtybees/thirtybees/issues/1087

The fact that there is extra javascript file on the page doesn't mean it delays page load. In this case it does not -- the paypal checkout.js is included using async and defer keywords, which instruct browser to load this asset asynchronously, and execute it after the page is parsed and rendered. Of course, your customer browser must load unnecessary data, which is not optimal. But it does not hurt your page load time <script async defer type="text/javascript" src="//www.paypalobjects.com/api/checkout.js"></script> Why is this script loaded on every page? Well, that's because paypal module does not know which controller (page) is used for checkout. So, it includes it on every page, just to be sure I have seen many payment modules to use conditional asset loading. Something like this: public function hookHeader() { $pageName = $this->context->controller->php_self; if ($pageName === 'order' || $pageName === 'order_opc') { $this->context->controller->addJS(static::JS_FILE_URL); } } And it works ok, but only for standard order and opc page. If you install some third-party checkout module (for example my chex), then this check would make the module unusable -- that's because controller name is not 'order' anymore, but it's 'module_chex_checkout'. This is actually one of the reasons why in ps17 it's forbidden to include assets conditionally. They will actually reject module from prestashop store if they find out it is using conditional asset loading. What is the best way to tackle this problem? I don't know. While it is possible to to use different hook to include this js asset (some hook that is triggered on checkout page only), it's not the best solution either. This would work only if *all* opc modules triggered this hook. And that's not guaranteed at all. By using header hook we can at least be sure that it will be triggered on every page, even on custom OPC.

I bet you are talking about paypal's checkout.js script -- this one is included using on all pages, even though it is needed only during payment. It uses header hook to do that -- but you can't simply remove this hook, as it would disable paypal functionality on your checkout page as well. What you can do is to define hook exceptions, blacklist all controllers except checkout