Kashir2000

TL;DR The rule here is different. It does not check how many would fit into a package, but if carrier can take that package. If you have Carrier A and it's max dimmensions are 30cm x 30cm x 30cm then this carrier would not take product that is 40cm x 30cm x 30cm But, same carrier can take 3 30cm x 30cm x 30cm packages It only checks if all could be taken by carrier, not if all will fit for one package. Many times i put one order and recieved 2-3 boxes with shipping number xxxx/1/3, xxxx/2/3 and xxxx/3/3. So it's rather common used solution. Longer version The thing you mean is "Box Selection Algorithm". TB (nor PS) does not support this. Many people solve this using weight system as "volume system". You could calculate weight for those. But it will not work in 100% cases. Still if your package is 30x30x30 (Volume 27000) then it would fit 2x 15x30x30 (2x 13500 = 27000 = it fits!) boxes. But if you had at last one 5x30x40 product, it would volume to 6000. So theoretically, you could use 30x30x30 box... but would it fit? For this case you would need 20x30x40 packaging box. So unless all your products come in exactly samame dimmensions its pointless.

If it's not easy to fetch by join, you can use callback parameter and fill field value by it.

Not sure if TB supports "ID" to "NOID" redirect for products. Would need to dig into code and/or maybe someone who knows more may answer that. But I'm not writing here for your problem, but more as a warning: Read above and then decide if you really want to disable URLs 🙂

Basically structure of Prestashop is as follows: Category id 1 is root category. This category should (or even must) exist. All other categories must have parent > 0\. So for standard Prestashop its 1 (Root) with parent 0; 2 (Home) with parent 1; (this - meaning value of 2 - should be set in your store as HOME category in settings for your shop) Things complicate if you have multistore and want a different category tree. Let's assume you want Category 123 to be home category of your second shop, then: 123 (Home of 2nd shop) should have Parent 1* and in Configuration of 2nd store HOME category should be set to 123. Note: * - It does not need to be 1... it may be 2 for example - but only if you want to - for example - setup second shop and use one of your existing categories and products in 2nd shop. For example, you may sell bikes and parts.... and you have Category tree like: 1 - ROOT (parent=0) 2 HOME (parent=1) 3 Bikes (parent=2) 4 Bike Parts (parent=2) 5 Bike Cloths (parent=2) 6 HOME2 (parent=1) 7 Laptops (parent=6) For SHOPID = 1 you may want to have 2 as HOME_CATEGORY - it will sell all products For SHOPID = 2 you may want to have 4 as HOME_CATEGORY - meaning it will only sell bike parts For SHOPID = 3 you may want to have 6 as HOME_CATEGORY - meaning it will use different tree Also note, that modyfing anything in category 4 will have effect in Shops 1 and 2 but not 3.

Wanted to quickly ask, if someoneknows if there has been anyc hanges to Advanced Stock management in TB comparing to PS? I have problem where sometimes in one of my client shops stock of a product jumps to millions... wonder if there was such bug fixed and/or got fixed in TB?

If you really want to disable caching, then one would replace return $this->display(__FILE__, 'productscategory.tpl', $this->getCacheId($cache_id)); with return $this->display(__FILE__, 'productscategory.tpl'); Trick is to remove cache_id from display and it will not write caches. Do it in all places where you want to disable caches. After doing so check if shop did not slow down.

@Traumflug Huge posting because I think Prestashop is one of the best eCommerce platforms out there, and 1.7 is a "Fall of Prestashop" 🙂 TB is my light in a tunnel 🙂 Sorry, for making ruckus, as I wrote in my second post, i had no idea it was backward compatible with {id} and that {id} had priority 🙂 - which is super fine 🙂

Acually it might be server misconfiguration. Too many workers are sitting in memory, consuming it and not running. Or... you acually have a very big traffic 🙂 Robots included 🙂 Server usage increases with google positions. Other hand, 2GB of memory is alot, and is not alot... if you want to run things switfly no amount of memory is too much, and as long as you don't exceed limit (exceeding it would mean hung server) you can consider that everything is fine.

My bad... I assumed, since: " id*, rewrite, ean13, category, categories, reference, meta_keywords, meta_title, manufacturer, supplier, price, tags " became id, rewrite*, ean13, category, categories, reference, meta_keywords, meta_title, manufacturer, supplier, price, tags It would only look by rewrite instead of ID. Just tested, even tho {id} is not required as identifier but {rewrite} TB has ability to search for products by id_product. Didn't investigate code untill now... and here is this small diamond 💎💎💎💎 if ($route['controller'] === 'product') { if (isset($m['id']) && $m['id']) { $idProduct = (int) $m['id']; } else { $idProduct = $this->productID($m['rewrite'], $uri); // <<<<<<<<<<<<<<<<<<<< if (!$idProduct) { $idProduct = in_array('id_product', $m) ? (int) $m['id_product'] : 0; if (!$idProduct) { continue; } } } $_GET['id_product'] = $idProduct; } Even with performance consideration from dev ❤️❤️❤️❤️ PS: Not sure why rewrite is required and not "either require or id is required", but it none of concern then 😉 @wakabayashi Thx for making me dig into code 🙂

I decided to post it here, but from what i saw on forums, it may not be seen as issue on TB. I'm a web developer and I'm working on Prestashop since late 1.3, I create and sell modules etc. I really like idea of TB, because I'm against where Prestashop is going and was considering of forking 1.6 myself, after finding out about TB i felt relieved I don't have to. After playing a little bit with TB I really like it, but there is one thing that is almost unacceptable for me. Meaning: Friendly urls in TB (I'm an enemy of all "remove id from link/url" modules). If you ask why, then: It does not improve SEO - I tested it... and alot of 1st places in google are with trashy links (like "/c/1" and "category-1" or "product/1" etc.) It forces shop users to acually remember every product to have unique ID (TB does not even notify about duplicates when adding new product) Cannonical Redirects stop working - Prestashop (didnt check code, but I belive it wasn't removed in TB) have built in cannonical redirects that automatically redirect product to new link (based on Product ID) Causes problems - especially while importing stuff automatically - in PS it works, cause it does not matter what I put into friendly url link and if it duplicates, to make my wholesaler integrations work I would need to create random rubish ids in URL's that deny whole purpouse of those "friendly urls" in first place. Can't imagine saying to client: Hey, TB is cool, but after every import of products remember to check "Duplicates" tab and fix duplicates by hand! GL HF! Disallows merchant to edit friendly urls or Requires him to write manual redirects From what I saw in Friendly url configuration, ID requirement was removed and TB requires "rewrite*" instead of "id*" I completly understand that some may want to enable those friendly urls, if they want to fix them "by hand" (yeah..right... especially after you import 10 000 products into shop) But (by me) it SHOULD be an option to enable and merchant should be informed of risks and additional duties. For example, while importing new products into shop I can think only about 2 ways: Add option "Prefix/suffix product name with md5 hash or something (Only needed on thirtyBees, and your links will be even uglier than with ID)" Add option to update product friendly url after saving product with generated product ID - "Dear Customer, our integration works slower in thirty bees, because we need to save each product twice!" Ignore problem and tell customers "Hey, you have very specific friendly links in your system, please edit them on your own/redesign url system/switch back to prestashop/live with it" Hope my essay will be heard and maybe it Will be considered in 1.0.9... PS: Wonder, what will happend if I migrate from Prestashop with "/1-productlink" urls to TB "/productlink". Seems any client I would convience to move to TB will lose all urls (Tested, adding ID to url does not redirect). As little as or as much as this... this "feature" (for me its a big flaw - can't say its a bug as it's intended... ) it's a dealbreaker. No matter how much I would want to move anyone to TB, It cannot ensure basic URL redirects. Maybe I'm missing something... enlight me if it's not a huge flaw/step back in TB design