datakick
-
Posts
2,911 -
Joined
-
Last visited
-
Days Won
438
Content Type
Profiles
Forums
Gallery
Downloads
Articles
Store
Blogs
Everything posted by datakick
-
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
- 30 replies
-
- 1
-
-
- free module
- theme configurator
- (and 3 more)
-
Awesome. Is this opensource? Is there a github we can contribute pull requests?
- 30 replies
-
- 1
-
-
- free module
- theme configurator
- (and 3 more)
-
This is normal when you have profiling enabled. Disable it in Advanced Parameters > Performance
-
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.
-
Order products in prodcutcategory module by price
datakick replied to Guido Buldrighini's question in Module help
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
-
I don't think these are related to your issue
-
Nobody. You have to check your server logs and find actual error message. Then we can help you
-
Apply following fix: https://github.com/thirtybees/niara/commit/b9719ea0cfbc96fb3be9d0cfd803f7b3a90633e7 Or download file js/tools/statesManagement.js
-
Your browser sends a lot of requests in parallel (14 or so), and your server evidently can't handle this. Your hosting (or maybe cloudflare or similar service) can (and probably do) throttle number of simultaneous connections per IP address, and drop some requests using 503 error code. I checked on my chrome, and it sends only 4 parallel requests -- maybe you can configure your browser to use fewer simultaneous connections per server. Now, I'm not sure if this is thirtybees problem or not. Of course, TB could use better queuing strategy to pre-load tabs via ajax... but the current works quite fine in most situation. Looks to me this problem is specific to your browser settings + your server limitations
-
No, it's server problem. A 503 Service Unavailable Error is an HTTP response status code indicating that a server is temporarily unable to handle the request. This may be due to the server being overloaded or down for maintenance. If you can overload your server just by opening product page and triggering couple of parallel ajax requests, you should consider switching hosting provider
