obewanz

I finally got a chance to look at this issue again - briefly. I don't have a code answer to post for this - yet... but I do believe this behavior is inherited by the module as the OOS flag in the database table ps_stock_available is 0, 1, or 2. 0 = deny 1 = allow 2 = default I suspect that the "fix" will be found in either the module's /view/product.tpl file OR the /theme/product.tpl file where it likely "tests" for one of the above values to determine if the "notification box" should be displayed. One last point of clarification: IF you are logged in as a customer, the module will NOT display a block for you to enter your email - it uses the email in the customer table, so it will only give you a link to click as the method to request a notification.

I know this is a long time after the original question and answers presented then, but for those folks who are STILL running PS 1.6.x Maybe this code will be of assistance (because Prestashop documentation is really useless). I will not upload the php or template files because at this point, either YOU need to learn how to do these minor modifications, or your developer does, so here are the instructions: Step 1: Copy your /classes/pdf/HTMLTemplateDeliverySlip.php file to the override folders at /override/classes/pdf/HTMLTemplateDeliverySlip.php (this is the easiest way to get there if you are new to php object oriented programming) Step 2: Search for the following line in that file: $carrier = new Carrier($this->order->id_carrier); Step 3: Modify the code to read like this: /* following line retrieves Customer Order Message */ $customer_message = $this->order->getFirstMessage(); $carrier = new Carrier($this->order->id_carrier); Step 4: Find this block of code: $this->smarty->assign(array( 'order' => $this->order, 'order_details' => $order_details, 'delivery_address' => $formatted_delivery_address, 'invoice_address' => $formatted_invoice_address, 'order_invoice' => $this->order_invoice, 'carrier' => $carrier, 'display_product_images' => Configuration::get('PS_PDF_IMG_DELIVERY') )); Step 5: Modify the code to read like this: $this->smarty->assign(array( 'order' => $this->order, 'order_details' => $order_details, 'delivery_address' => $formatted_delivery_address, 'invoice_address' => $formatted_invoice_address, 'order_invoice' => $this->order_invoice, 'carrier' => $carrier, 'message' => $customer_message, /* adds customer_message to smarty variables */ 'display_product_images' => Configuration::get('PS_PDF_IMG_DELIVERY') )); Step 6: Find this block of code (right after the last one): $tpls = array( 'style_tab' => $this->smarty->fetch($this->getTemplate('delivery-slip.style-tab')), 'addresses_tab' => $this->smarty->fetch($this->getTemplate('delivery-slip.addresses-tab')), 'summary_tab' => $this->smarty->fetch($this->getTemplate('delivery-slip.summary-tab')), 'product_tab' => $this->smarty->fetch($this->getTemplate('delivery-slip.product-tab')), 'payment_tab' => $this->smarty->fetch($this->getTemplate('delivery-slip.payment-tab')), ); Step 7: Modify the code to read like this: $tpls = array( 'style_tab' => $this->smarty->fetch($this->getTemplate('delivery-slip.style-tab')), 'addresses_tab' => $this->smarty->fetch($this->getTemplate('delivery-slip.addresses-tab')), 'summary_tab' => $this->smarty->fetch($this->getTemplate('delivery-slip.summary-tab')), 'product_tab' => $this->smarty->fetch($this->getTemplate('delivery-slip.product-tab')), 'payment_tab' => $this->smarty->fetch($this->getTemplate('delivery-slip.payment-tab')), /* creates a template file to display the customer_message in on the form */ 'message_tab' => $this->smarty->fetch($this->getTemplate('delivery-slip.message-tab')), ); Save changes and this file is ready to upload to your /override/classes/pdf/ folder AFTER you have completed the following files AND uploaded them. (If you are working on a non-live site, the order that you upload the files doesn't really matter.) A quick comment: It is absolutely true that you do not need to include the comment lines that describe the changes being made - however, it is my opinion that you should - because somewhere down the line might want to know what you changed, and if you don't work with this code on a daily basis, sometimes even if you do, these comments can provide critical information to refresh your memory why those changes are there, or in the cases of new methods, etc. the parameters and other information expected by the method. We're not quite finished yet, so moving on... Step 8: Create a /pdf/delivery-slip.message-tab.tpl file to setup your message display within the pdf template with the following content: {* * 2007-2015 PrestaShop * * NOTICE OF LICENSE * * This source file is subject to the Academic Free License (AFL 3.0) * that is bundled with this package in the file LICENSE.txt. * It is also available through the world-wide-web at this URL: * http://opensource.org/licenses/afl-3.0.php * If you did not receive a copy of the license and are unable to * obtain it through the world-wide-web, please send an email * to [email protected] so we can send you a copy immediately. * * DISCLAIMER * * Do not edit or add to this file if you wish to upgrade PrestaShop to newer * versions in the future. If you wish to customize PrestaShop for your * needs please refer to http://www.prestashop.com for more information. * * @author PrestaShop SA <[email protected]> * @copyright 2007-2015 PrestaShop SA * @license http://opensource.org/licenses/afl-3.0.php Academic Free License (AFL 3.0) * International Registered Trademark & Property of PrestaShop SA * * @author Obewan <[email protected]> * This is a private modification to prestashop 1.6.x to add the customer order message to the generated pdf delivery slip document. * *} <table id="message-tab" width="100%" cellpadding="4" cellspacing="0"> <tr> <td class="message center small grey bold" width="44%">{l s='Order Message' pdf='true'}</td> <td class="message left white" width="56%"> {$message|escape:'html':'UTF-8'|nl2br} </td> </tr> </table> Comments: There are a number of ways to effect this output, but I felt this not only gave you more information on how to modify pdf generated output for other possible future needs, it also tends to provide a much cleaner solution in the end as it leverages the template system to set this apart from the rest of the form code. Note: You can ALSO place this same file in your /themes/your-theme-name/pdf/ folder to lessen the possibility of it getting overridden as there is no provision made to create overrides for template files in Prestashop 1.6.x. Step 9: COPY your /pdf/delivery-slip.tpl file to something like "/pdf/delivery-slip-replaced.tpl (you will use this file to restore your pdf generation template if things go wrong! Step 10: Search for the following code in the /pdf/delivery-slip.tpl file: <tr> <td colspan="7" class="left"> {$payment_tab} </td> <td colspan="5">&nbsp;</td> </tr> <!-- Hook --> {if isset($HOOK_DISPLAY_PDF)} <tr> <td colspan="12" height="30">&nbsp;</td> </tr> <tr> <td colspan="2">&nbsp;</td> <td colspan="10"> {$HOOK_DISPLAY_PDF} </td> </tr> {/if} Step 11: Modify the code to read like this: <tr> <td colspan="7" class="left"> {$payment_tab} </td> <td colspan="5">&nbsp;</td> </tr> {* -- load message tab and display order message if one exists -- *} {if isset($message)} <tr> <td colspan="7" class="left"> {$message_tab} </td> <td colspan="5">&nbsp;</td> </tr> {/if} <!-- Hook --> {if isset($HOOK_DISPLAY_PDF)} <tr> <td colspan="12" height="30">&nbsp;</td> </tr> <tr> <td colspan="2">&nbsp;</td> <td colspan="10"> {$HOOK_DISPLAY_PDF} </td> </tr> {/if} Comments: I used the smarty comment method to indicate where the new code insert begins, I could just have easily used html comments as those that already appear in the above code snippet. While I prefer to use the smarty comment method whenever possible, the purpose here was simply to show you something new that you may not be aware of. {* comment *} After uploading the files above, the following image depicts the pdf output produced by the above modifications in the standard template: Note: IF you wanted a separator line between the payment and message elements, you could always add a border between them by either inserting a <tr><td class="separator"></td></tr> as the first row of the table in the /pdf/delivery-slip.message-tabl.tpl file OR by using/adding a css directive like table#message-tab {border-top:1px solid #000;} in the /pdf/delivery-style-tab.tpl file. Hopefully presenting the answer in this format will not only allow you to add something that SHOULD HAVE ALREADY BEEN IN THE RELEASED CODE of Prestashop 1.6, but it will also help you to learn more about how to modify your own Prestashop site in the future... or maybe even help out a new developer to the codebase.

I was about to purchase another module (Seo Redirects) from @vekia (mypresta.eu). I purchased his password reset module, which seems to work fine on my PS 1.6.x site, but he has not responded to my last two inquiries, so I've moved on.

Actually, there are things that CAN be done beyond any third-party CAPTCHA or touring test code to defeat spammers, and it's really not that complicated. I've actually been doing it now for about 2 years and my spam messages have dropped to about 1 manually sent spam message every 3 or 4 months, acceptible in my operation.... Way better than the 40 plus per day I was receiving before sitting down and figuring out these measures. Too bad the PS coders won't look back on their best software product PS 1.6. Of course, that would also imply that Prestashop support it's software and fix defective code algorithms for free, even for that disgusting, antiquated, outdated, feature rich - not stripped down 1.7 version garbage code, Red-Headed Step-Child variant Prestashop 1.6.x. But then again, I suspect that is WHY so many merchants have resisted moving to their 1.7 release - I know it has been the driving factor for me and at least 1 other shop owner that I personally know. Also, why rely on a third-party (google) to block advertising information when that is IN FACT their business model - selling advertising data?? I don't trust google, but since they are still king of the hill with regard to search engine traffic we have to put up with them - but that doesn't mean we have to give them more of our valuable data for free by activating their plugins or "services" on our webstores! That said, until I figure out a way to protect the code that actually does the testing (and do it for free), I can't release my solution. So why did I even mention it? Because I'm tired of hearing all of the pathetic excuses from software code managers, companies and their programmers about WHY they CAN'T FIX things that are wrong with their software without pushing you to a NEW version that either reduces the features you had (this seems to be a habit with the PS folks) or charging you additional monies (also a habit with the PS folks) or pointing you to third-party tools that will further enhance your dependence on someone else!... and I might add that Thirty Bees isn't much better, however the TB code base SHOULD have been the basis for a 1.6.4.x or 1.7 version of code for Prestashop - IMHO. Not the pathetic excuse for a release that 1.7 is - seriously, if you couldn't take the time to move the ENTIRE presentation layer over to Symfony and Twig, then why even bother?? Incidentally I don't like the Symfony platform - it's much more complicated than Smarty - and I don't see a valid reason to make such a drastic move in the code base. Thirty Bees actually proved that. Oh, you can make whatever claims you want about the change, but the fact remains that users of 1.7 really haven't gained anything except a much steeper learning curve in making custom modifications to the presentation layer of the software - ie. their templates, and a loss of essential features. But I digress... Now that I've bashed Prestashop for the shortcomings they can't seem to wrap their heads around, and the reason why many PS shop owners I've spoken with seem to have a love-hate relationship with Prestashop itself... Let me give you a few positives. The Prestashop 1.6 e-commerce system/platform is quite possibly one of the most comprehensive and complete solutions available, especially in Open Source, and if you can live with the few shortcomings that seem to be baked into the code base, it is far superior than the hosted Shopify, BigCommerce, OpenCart, etc. solutions that I know of - in my opinion. So who the heck am I to make these comments? Nobody really, just a Prestashop 1.6 Shop Owner whose shop handles a 16k plus item catalog with over 150k product images, averaging between 30GB and 40GB per month in data traffic, and a theme template that changes the look so much that you wouldn't even know the store was driven by a Prestashop codebase, and taking orders on a daily basis 24/7 -- all (currently) running on a shared hosting server - and the only reason I MAY be forced to move to a Virtual Private Server in the near future is because of PHP changes (also a thorn in my side) and that the PS folks have dropped the 1.6 code base, so no PHP fixes forthcoming - though I am seriously considering doing my own fork for this very reason. (I also forgot to mention I'm using Panda 1.2 theme, which is more like an "engine" over the core code - but they have also gone mad with supporting mobile first code in their 1.5.5 release that doesn't work as well on non-mobile devices and also obsoletes much of the css descriptors from previous versions.) That said, I don't want to be a programmer - I want to focus on running my business - and therein lies the whole problem with where we are now! -- -- PRESTASHOP ARE YOU LISTENING?? I didn't start this response off with the idea of bashing Prestashop, but I also didn't plan on promoting these two developers either. But as I wrote out my scathing commentary on the management/methodology behind Prestashop (note that I praised the product, just not the way the business is operated from the strategic and coding perspective) I felt it the right thing to do to offer up some sort of REAL solutions. So this is my recommendation -- There are TWO absolutely Great developers out there, I have zero connection to them other than having seen their free code and implemented some of it to my own websites, as well as purchasing a module from one of them, and those two folks are Fabio from http://nemops.com/ and Milos Myszczuk aka VEKIA from https://mypresta.eu/. You may have seen Vekia on the forums - solid guy! Anyway, go direct to either of these two developers' sites and engage them with your problem. Know up front that you WILL have to pay for their services, but I feel confident in saying that whatever they come up with for you, if you don't tie their hands, it will probably be quite affordable as they can also offer those new features or "fixes" to other shop owners, thereby reducing the cost to any single owner/operator. Based on my limited knowledge of their operations, that seems to be the way they operate - and I applaud that concept. Oh, and let's not forget about the problem that brought us all here in the first place... Spam Mail via the Contact Form - Here's Fabio's solution, though I have added my own modifications from my own codebase (some of my code for this particular override is provided after the link to his article on how to address the problem): http://nemops.com/blocking-spam-emails-in-prestashop/ class ContactController extends ContactControllerCore { public function postProcess() { if(Tools::isSubmit('submitMessage')) { $banned_in_email = ['.ru', 'qq.com', '.vn','ggsuppliesstock.com']; $banned_content = ['email marketing']; if (in_array(trim(Tools::getValue('from')),$banned_in_email)){ $this->errors[] = Tools::displayError('There is a problem with your email address - message not sent.'); } elseif (in_array(trim(Tools::getValue('message')),$banned_content)){ $this->errors[] = Tools::displayError('Junk Mail score exceeded - message not sent.'); } } parent::postProcess(); } } If you're going to attempt to apply this to your site by yourself, I would suggest that you refrain from providing error messages that tell the spammer exactly WHY their message was rejected. Why help them figure out how to defeat your protocols? I just simply use a message like "Junk Mail score exceeded..." to let them know they need to try, try, try again. Make THEM waste THEIR time with trying to communicate with you and they will go away, all by themselves - because like you, time is valuable to them as well. I no longer track the attempts to send spam content via my contact form but when I did, it cost them dearly, as in 100s (sometimes 1000s) of failed attempts before they would give up, and some of those you know they had to manually modify. I also have code that filters the form itself along with some other processing protocols, but that is the part I can't expose as it will only provide a method for them to eventually exploit the fix I have found. And NO you can't have it... Sorry, see earlier paragraph, but the code I provided here should go a long way in eliminating much of your spam. I could possibly be interested in further collaboration if someone writes the code to either read the arrays from a text file on the server or from the database, I do have a store to run. I know this post is lengthy, but I think it covers all aspects of why this should not be a problem, but is... and something you can do to curb the problem at least a little bit. Good Luck!

I know this is an old post, but for those who might happen to come across this post looking for that ever elusive update to the stock/backorder issue for their shopping cart - I have a comment: This feature is NOT part of the Prestashop core code and I am unaware of any free modules or other code that does what the OP is asking for. You will either need to PURCHASE a module or HIRE someone to make custom code modifications for you! More importantly - DO NOT attempt to circumvent the cart function by Decreasing the cookie session time - that will only annoy your potential and existing customers!

/config/defines.inc.php Should be line 29... Change the following: define('_PS_MODE_DEV_', false); ...to this: define('_PS_MODE_DEV_', true);

I noticed that the module options are all $84.99 or more... you can purchase a similar module at mypresta.eu for 29.99 euro or $51 usd. The prestashop marketplace seems to have been lined with gold and marble walls or something.

So I've come into this conversation a bit late, and I think I may have been convinced NOT to be concerned about the product/page IDs in my URLs... BUT... I think I may be getting penalized in some way (maybe for keyword stuffing) because my product URLs also contain my category string - ie: {category:/}{rewrite}-{id}.html I'm seriously thinking about changing that to {rewrite}-{id}.html and purchasing a 301 redirect module, if I can find one that would automagically create the 301 upon detection. My google search console reports that out of nearly 9,000 products indexed, only 57 of them rank at position 1. Thoughts?

Well, good luck with that upgrade. Seriously, I hope you have better luck than I did.

Well, you never responded, so I must assume you either got this fixed or you gave up. The above code is NOT sufficient to debug this problem - so for those who might have the same problem - try looking in your product.php class file or your ProductController.php file to make sure the $product.ean13 variable is being populated with data. Also, I don't have a gtin property being output in my theme and I believe when I added it, the problem remained so since google is all about being cryptic on what it was looking for, I removed it and only kept the mpn reference.

Do you have an HTML source output of the above referenced code? My first guess is your template is not populating the $product.ean13 value, but that's just a wild guess. I'll try to have a look this weekend and see how I fixed it in my code.

Looks to me as though you have a theme problem (or someone altered the theme incorrectly)... Within your leo_toys theme product.css there are multiple @import statements scattered throughout the stylesheet. Instead there should be ONE line similar to the following: /* primary_block ***************************************************************************** */ @import url('https://fonts.googleapis.com/css?family=Lato'); The @import rule must be at the top of the document (but after any @charset declaration). And in this particular case, later within the style sheet, the font should be called as follows: #usefull_link_block li a:before { font-family: 'Lato'; font-size: 16px; line-height: 24px; position: absolute; left: 0; font-weight: normal; } - - - NOT - - - #usefull_link_block li a:before { font-family: @import url('https://fonts.googleapis.com/css?family=Lato'); font-size: 16px; line-height: 24px; position: absolute; left: 0; font-weight: normal; } Since this mistake has been made, my guess is that fontawesome isn't being imported or loaded anywhere... a quick fix might be available by making sure that the font-awesome.css file is in the autoload folder of your theme (ie: /themes/leo_toys/css/autoload/). NOTE: You'll need to make sure that the url reference in the font-awesome.css file points to the folder where the fonts actually reside - you'll be looking for something like "fontawesome-webfont.eot", probably in a /themes/leo_toys/fonts/ folder.

Your theme must support rich snippets, and make sure your barcode is within a snippet tag with the - itemprop="mpn" - declaration... Google apparently does not recognize gtin as a valid declaration either... Hope this helps https://schema.org/Product

So I made an assumption that I should not have made and did not ask... What version of Prestashop are you running? The Technical Concepts: The Reference Number in the ps_orders table is NOT unique (see screencap below) and so duplicates would only stop an order from processing if the selected payment provider is being fed the Reference Number from the 'ps_orders' table and said provider requires that value to be UNIQUE. (This could possibly be addressed in the payment module.) Having said that, in order to replicate your issue, I believe one would have to have two browsers open and submit both orders at EXACTLY the same time. The solution requested to append a letter and disturb the natural sequential interval would not be acceptable to me, nor would I expect it to be for most other larger store owners. So at first glance, to fix the level of problem you explain, one would likely have to write a substantially more complex override that would actually store the order, grab the value in the 'order_id' field of the ps_orders table (since that IS a UNIQUE value), then return a prepended string of that value storing it in the 'reference' field and THEN allowing the process to continue within the Prestashop order flow. On second thought, THIS could (possibly) be accomplished with an override to the PaymentModule.php class, but the public function validateOrder is complex enough that I'm a little concerned with this approach given Prestashop's history with code patching, etc. With that in mind, I'll work to add a new override in a followup post with the changes needed to insure the reference number is as unique as the order_id. So the short answer is - off the top of my head - there is no simple solution to your dilemma other than to address the apparent latency issues or write a different override. Sorry!