datakick

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

I offer few paid support packages. The minimum is 2-hour support. To fix issue like this would take just a couple of minutes (~20mins). You could use the rest of the time on other issues/bugs, of course. It's valid for 1 year

Strange, I can see the error code clearly: Anyway, the problem is this: The module tries to create temp/dummy address in order to calculate shipping cost to that address. Because ajax request didn't provided any zipcode: module ends up trying to create address with empty postcode, resulting in this error code. The best way to fix this is to modify php code and properly handle the situation when no postcode is provided. Alternatively, you can modify javascript code and pass some dummy zipcode, when none was entered yet.

You will have to modify the module code. Simply change this line to $category_products = $category->getProducts($this->context->language->id, 1, 100, 'price', 'DESC'); That should do the trick. If you do this modification, you can't update the module to newer version. The easiest way to ensure this is to change module version to some very high number, ie 100.0.0. That's a hack, though. It would be very nice to have an option to *lock modules* in tb core

You can do this: enable debug mode open javascript console click to Networks tab Find 500 post request and click on it click on Preview tell us what the page says