Obi

ANSWER: 1) Copy /controllers/admin/AdminProductsController.php to /overrides/controllers/admin/AdminProductsController.php 2) comment out lines 820 and 821 as shown (actual line may vary) contained in the public function processDuplicate() //$product->link_rewrite = static::getUniqueLinkRewrites($product->link_rewrite); //$product->reference = Tools::nextAvailableReference(static::getBaseIdentifier($product->reference)); 3) Then ftp/copy /overrides/controllers/admin/AdminProductsController.php to your server. 4) go to your back office > Advanced Parameters - > Performance and click Clear cache in the upper right corner. You can then duplicate products without the link-rewrite value or reference value of the duplicate products being affected.

Ok, where can one remove the _NUM ("REF N_1", "REF N_2", "REF N_3", etc.) append "feature" in thirtybees to restore the ORIGINAL FUNCTIONALITY of Prestashop 1.6 when duplicating products in the back office? I don't want to waste time tracking down such a ridiculous change in core functionality - TB 1.4.0. Thanks in advance!

I seem to be wasting my time here.

We seem to be having a language barrier, because I can restore the ONE shop in LESS THAN HALF the time it takes to restore 4 shops IF it ever got hacked. I was responsible for more than one high profile website using server clusters and serving millions of visitors per day for more than one previous employer I've left (either for a raise or prestige), so you must understand that for someone to suggest to me that I need to split my website into FOUR websites for "security" purposes is nothing short of laughable in my mind - if that is indeed what you are getting at... And if so, I would probably suggest that you should take a few business classes somewhere. My current website runs just fine, thank you very much, provides my customers with a nice selection of product, all from a single location, ultimately making it easier for them to hit the free shipping threshold from my store with purchases they want (instead of trying to pad an order because there isn't sufficient selection), among other conveniences.

I don't have the supplier column, though I do have a barcode module that changed the list so that it now presents a printer icon for printing barcodes and a pulldown arrow next to that for access to edit/delete/duplicate/preview. I didn't like that arrangement at first, but have gotten used to it over the years. (The barcode mod might be why mine is different - I would have to look back through maintenance records to see when and what was actually changed.) This is what my product list line looks like at this moment:

Not sure what you mean to say here... My store has over 17,000 products, it is what it is. How else do you think people are going to purchase those products from me?

I've been running and programming high profile websites since before osCommerce... I'd have to go back and see when I became responsible for that first hi-profile website (probably around 1996 for the U.S. Government - USAF), but I've been responsible for some very high visibility websites over those years that received millions of visitors monthly if not weekly or in a few cases daily. (NASA, The US Military (including NIPR and SIPR systems), and Coca-Cola are the first ones to come to mind. And yeah, at no time while under MY watch were ANY of those systems ever compromised.) I did not fall for the chicken little "it's for security" claims back then and I won't be goaded into them now. That is NOT to imply that I disregard patches or updates altogether, but I want to see what's being changed before I apply any such patch or update. Do security issues exist in software - of course they do - virtually ALL software is defective the date it is published - how do you address that? (that's rhetorical) It really depends on a number of factors, but constantly rolling out "updates" which include NON-SECURITY related "enhancements" is EXACTLY the wrong approach, and in many cases careless coding trying to roll this crap out is what causes many of those updates to FAIL - SOMETIMES CATASTROPHICALLY! . . . Leaving the merchant screaming for help - because down-time is lost money for every merchant. I'm going to inject a KUDO (sort of) here for ThirtyBess before I make my next statement... I can see a lot of work has been done on the codebase, but I also still see a good number of simple crap issues like spelling errors for objects that really should have been FIXED as part of the 1st or 2nd evolution of distribution that weren't - "statut" is one that immediately comes to mind instead of "status"... one of numerous signs of lazy coding practices that you inherited, but still haven't fixed. 😩 . . . The very issue of Software Quality Control/Assurance is something I just recently experienced with a couple of ThirtyBees module updates because I allowed myself to get lazy and ASSUMED the updates had been fully validated (shame on me). . . A mistake I WILL NOT MAKE AGAIN! As for the security stuff... The Sky is NOT always falling, and it really irritates me when people use that behavior to "push" or goad other people to do things those people would not otherwise do of their own volition. BACKUPS ARE YOUR FRIEND!!! Take them often... (and make sure you can also restore them! . . . in whole or in part.)

I had similar opinions during my first 4 or 5 years using Panda... I passed a number of code fixes and things along to Jonny, but like most "Open Source" operations, I believe it turned into a how can I "push" people to pay more money. But as I said earlier - I'm done with ST-Themes anyway - full stop. After reading the TB 1.5 new release information - I see the platform going in a direction that is not compatible with my own, so I'll probably just fork 1.4.0 and be done. I'll develop my own theme system using that codebase and that will be all. I'm 60 now, so not far from retirement, which means I'm not interested in all the money being dumped to keep up with the Joneses... and at this point, that's sort of what I see with the "Premium" stuff being rolled into TB 1.5 as well as other issues that should have been addressed in 1.4.0 - which are mostly the good things happening in 1.5. But in the end, I'm not onboard with a number of major changes in 1.5.0 so I'll be ducking out. It's a shame because I did have high hopes for ThirtyBees. Oh yeah, let's sum this up - I WILL NOT RENT SOFTWARE - NOT NOW - NOT EVER!!! Adobe, Microsoft, and others that started that crap are what drove me to Open Source... now it's procreating like a disease throughout the "open source" community (probably thanks in no small part to companies drove "projects" like CRELoaded and Prestashop). I think this situation is WAY worse than what Adobe and MS did - because people who WANT to see everyone benefit are being USED! You help fix bugs and create top shelf software (mostly) only to have someone else profit off of YOUR work and efforts. EVERY single piece of software that has gone to the "rent/subscribe" model ends up costing 10x (OR MORE) than what it would cost if you just buy it up front - death by a thousands cuts, and because each cut isn't all that painful, you don't notice it so much... at least not until you bleed out!

I'm still done with Panda. The version I attempted to use with the TB platform was Panda v.1.5.5 (I know there was another one, but it would appear I deleted the files - probably because I was pissed.) I'm in the process of modifying the community-theme for my major production site. I'm already nearly finished deploying a modified version of this theme for my secondary e-commerce site (a lot less products and transactions). While that hasn't been without its issues, I'm not captured by a commercial entity selling "open source" software. Don't get me wrong, I still pay for code/customizations from time to time, because I don't have the time to write what I want when I want it, but I'm not going to pay multiple times for a "lifetime license" just because there's a technology PUSH to force me into doing this. Oh Yes, those bugs were related to mobile first modifications in the theme, mostly related to images, BUT they ALSO changed so many style descriptor names, I gave up tracking them all down. They didn't even make an attempt to provide docs or deprecation of any kind for these changes - effectively making my custom css code (only 2 revisions back) of about 2300 lines and just over 860 styles USELESS! under that "new" version. PPS: Renewing the "support license" was the same cost as purchasing the theme all over again!

I just realized this issue exists on a different production website running on TB 1.3.0, so it isn't something new. Block Categories v3.0.3 - by thirty bees = = = = = = = - - - - - I get this - - - - - = = = = = = = ...but when I click the "Richardson" text link instead of the button... I get this - which is what I should ALSO get when clicking the button:

Removing the ID was something in the old Prestashop world called "Pretty URLs" IIRC... and a lot of people were absolutely adamant that it was necessary for google rankings. Well I have top slot in quite a few google results that I want to rank in, with highly sought after rankings for those I haven't focused on - usually better than the manufacturers of the products I carry. But more importantly, in the last 10 years of using prestashop, now thirty bees, having that product ID in my urls has saved my bacon on a number of occasions because it provides an anchor point for a product, regardless of whether the purpose is searching, linking, or entering new products. Yep, one of the issues I ran into was an ever increasing number of "collisions" that caused noticeable slowdown of the site as well as an increase in 404 page errors (mostly misses from older links) in the logs. I presume this happened because I have a large catalog (17,000+ items) with a substantial number of "visits" (over 500,000/mo) and quite a number of similar products with same/similar names from different manufacturers. Not to mention the confusion that arises when you are posting external links or articles to the product and the link-url has changed because the "force update of friendly url" setting contributed to urls changing without realizing they had changed. After more than 20 years of administering and owning e-commerce websites, I would NOT have or operate an e-commerce website that did not give a unique fixed reference (ID) in the url for every product. I would rather a visitor actually FIND the product they were looking for because the url had a fixed unique reference that allowed the website to determine the product they wanted - even when the rest of the url didn't exactly match whatever link the visitor followed to get to my website(s). Just my .02 cents worth.

This module did not install on my TB 1.4.0 test site 😞

First is the original code that presented stylized div regardless of whether or not data is available, second is the modified code that keeps this element from being displayed at all when no data is available. I suppose I could have taken the approach to just hide the div instead of remove it entirely, but my particular coding style gives preference to not displaying an element if there is no need to do so. This approach was less work than correcting the php source files to address the issue. Here's the original code: {if $show_functional_buttons} <div class="functional-buttons clearfix show-if-product-grid-hover"> {hook h='displayProductListFunctionalButtons' product=$product} {if isset($comparator_max_item) && $comparator_max_item} <div class="compare"> <a class="add_to_compare" href="{$product.link|escape:'html':'UTF-8'}" data-id-product="{$product.id_product}"> <i class="icon icon-plus"></i> {l s='Add to Compare'} </a> </div> {/if} </div> {/if} Here's the code that corrects the issue so the div is not displayed if there is no data available to display - it keeps the rest of my product block code clean in the presentation: Note: Because the "comparator" code isn't part of the hook, an if/elseif test was required so that it gets displayed regardless of whether the hook contains data when the comparator is turned on in the configuration settings. {* EXTEND TEST IF FUNCTIONAL_BUTTONS SHOULD BE DISPLAYED - FOR CLEANER THEME CODE/CSS *} {if $show_functional_buttons} {capture name='displayFunBtns'}{hook h='displayProductListFunctionalButtons'}{/capture} {if $smarty.capture.displayFunBtns} <div class="functional-buttons clearfix show-if-product-grid-hover"> {hook h='displayProductListFunctionalButtons' product=$product} {if isset($comparator_max_item) && $comparator_max_item} <div class="compare"> <a class="add_to_compare" href="{$product.link|escape:'html':'UTF-8'}" data-id-product="{$product.id_product}"> <i class="icon icon-plus"></i> {l s='Add to Compare'} </a> </div> {/if} </div> {elseif isset($comparator_max_item) && $comparator_max_item} <div class="functional-buttons clearfix show-if-product-grid-hover"> <div class="compare"> <a class="add_to_compare" href="{$product.link|escape:'html':'UTF-8'}" data-id-product="{$product.id_product}"> <i class="icon icon-plus"></i> {l s='Add to Compare'} </a> </div> </div> {/if} {/if}

Thanks! . . . that was it. I'll paste the completed code in another post once I get everything wrapped up (the compare test presents another issue).

How can I test in a theme template file whether or not a display hook has data? Inside the /themes/themename/product.tpl file there is a hook to check for out of stock conditions and displays an input field, button, or nothing depending on whether not there should be a notification for mailalerts module. I used the following test just prior to $HOOK_PRODUCT_OOS in the product.tpl file to prevent the div from being displayed if the element wasn't supposed to be displayed as this disrupted my theme by having it display regardless: <div id="oosHook"{if $product->quantity > 0} style="display: none;"{/if}> I have run in to a similar situation with the /themes/themename/product-list-item.tpl file where the test gets populated regardless of any hook data using the following code: {if $show_functional_buttons} <div class="functional-buttons clearfix show-if-product-grid-hover"> {hook h='displayProductListFunctionalButtons' product=$product} {if isset($comparator_max_item) && $comparator_max_item} <div class="compare"> <a class="add_to_compare" href="{$product.link|escape:'html':'UTF-8'}" data-id-product="{$product.id_product}"> <i class="icon icon-plus"></i> {l s='Add to Compare'} </a> </div> {/if} </div> {/if} The reason this happens is because the variable/array $show_functional_buttons gets populated in the /themes/themename/product-list.tpl with this code: {$show_functional_buttons = $page_name != 'index'} As you can see, it only matters whether we are viewing 'index' or not - which really is not a valid test in my opinion. What I want to do is either unset this variable or change it to false if the hook named "displayProductListFunctionalButtons" actually has data - which it should not if the wishlist module or similar isn't active and I have set the "product compare" setting in [ preferences / products ] configuration page to "0".