MisterPresta

Answered my own question. I feel kind of stupid, but I will "fess up" and admit my dumb mistake. I added the clone site to hosts, but I did it on the machine where I was accessing the site from my web browser and not on the web server. DUH! So, problem solved Thanks and apologies to anyone who looked at this.

I am having the same problem. Site is a clone of production site on local server and generates the same TCPDF error ("TCPDF ERROR: [image] Unable to get image: /var/www/my_site/cache/tcpdf/img_oardqY"). The clone site's domain name is in my hosts file. I cannot configure the domain in DNS because it's a test server and does not have a registered domain name. Database was updated with new URLs, all caches, etc. have all been cleared and .htaccess regenerated. Everything else works perfectly except for invoice generation. I checked all prestashop files for hard-coded domain name and there are none. The temporary image file that is reported as missing is not on the server. The .../cache/tcpdf directory is empty. Permissions allow read/write access to the directory (in fact, since this is a test server I set permissions for ALL directories on the server to "xrw" (777) and it still does not work. I would appreciate any suggestions. This is a showstopper because I can't have that error appear when a customer is finalizing payment.

I found the solution (answering my own question): Quick answer: I did not yet set up public DNS for the new site's domain so downloading the image by curl failed. The solution was to put the new domain into the server's hosts file (or set up public DNS for the new domain). (Suggestion to Prestashop: failure to download an image should not generate an error page that the customer sees, especially in the context of finalizing payment for a purchase. Maybe it's better to simply leave out the image in the .pdf or substitute an "image not found" image) Long answer for those who might want to learn a little more: To generate a .pdf invoice, an HTML version of the invoice is first generated (per invoice.tpl) which is then parsed and converted to .pdf by code in tcpdf.php. When images are added to the .pdf file, they are downloaded (using curl) from the URL specified in the src attribute of the <img> tag in the HTML version of the invoice. They are NOT retrieved directly from the local file system (which is how images are retrieved in most, or all, other contexts-- which explains why this is the only place where I was having a problem). I had not yet set up DNS for the new site's domain. Instead of failing the DNS lookup for the unknown domain, my ISP (Time Warner Cable) returns an IP address that generates an advertising page if it is requested by a browser. When the image is requested by curl from this IP address, it returns the 302 redirect that I saw. The redirect URL has the domain replaced by "localhost", but otherwise it is the same URL that was requested. Because the URL for the image is a "friendly name", it does not exist at the specified location. Normally, .htaccess handles the translation, but it only looks for the domain explicitly, not "localhost" so when I told curl to follow the redirection it still failed. The only thing I still don't understand is why the logo image (in header.tpl) was simply left out, but an image in the body of the invoice caused the ugly "TCPDF ERROR"

I cloned my test server by copying all the Prestashop files to the production server, imported a dump of the original database into the new database then updated all the URLs in the new database to point to the new URL. I also deleted .htaccess then re-generated it via the backoffice then cleared the caches, thus taking care of the usual things that cause this kind of migration to fail. Everything works beautifully (front office and back office) EXCEPT generation of .pdf invoices. Only the images (for example, the logo in the invoice header) are a problem. Some images cause an error others just don't appear in the generated invoice (all work fine in the test server). At this point, I can't go live because after a user pays with PayPal and clicks the final button on the last page of checkout, when an invoice is generated a page with "TCPDF ERROR..." is returned to the user. Ouch! Some (but not all) <img> tags in the smarty templates cause the error: TCPDF ERROR: [image] Unable to get image: ...etc. and no .pdf is generated. If I temporarily remove these tags, then some other images (ex. the logo in the header) just do not appear (but the .pdf is generated). After 8 painful hours I have so far determined that .pdf templates are initially expanded to HTML which is parsed then converted to .pdf in tcpdf.php. All the URLs for images (<img...> tags) in the HTML template end up populated with absolute URLs (for example <img src="www.newsite.com/26-small_default/product.jpg" />) which are the "friendly name" URLs. These are fetched using curl and stored in a temp file. The URLs get rewritten (because of .htaccess) in the server to something like www.newsite.com/img/p/2/6/26-small_default.jpg which is where the actual image is located. I verified the images are there and I can get the images in a browser from another computer using an absolute URL (either the friendly or re-written URL works). When the code in tcpdf.php issues a curl_exec to get the image (to a temp file in /cache/tcpdf), the server returns a 302 redirect with the header pointing to the same URL that was requested EXCEPT the server name is replaced with localhost. For example, www.newsite.com/26-small_default/product.jpg becomes http://localhost/26-small_default/product.jpg The redirect is not normally followed so the operation fails (instead of an image, a small HTML file with "302 Found", etc. is saved in the temporary file and the failure occurs when later code tries to read the temporary image dimensions). I temporarily added CURLOPT_FOLLOWLOCATION to the curl_exec and the redirection is followed but the generation of the .pdf still fails (I did not follow through to determine why it now fails-- I think the image is still not retrieved to the temp file). A few other things I tried (on a fresh copy of the installation): delete the smarty compile directory, put various hard-coded URLs for the images in the smarty templates (invoice.tpl, header.tpl). I also checked the database and config files for any reference to the old URL and grepped all installed files for the old URL (none found). Anyone have any idea why this is happening?

I can't get the Smarty debug console to open. I'm using Prestashop 1.5.6.0. I set $smarty->debugging = true; in smarty.config.inc.php, I set define('_PS_MODE_DEV_', true); in defines.inc.php. I added {debug} to my template. I turned caching off in the BO and set the debug console to "Always open console" (also tried "open with URL parameter" which also failed), I set my browser to allow all popups and restarted everything (browser) and reload my shop page. The debug console never opens. I had this working at one point so I know I'm just missing one thing. Anyone know what it is?

You said "that fixed it". WHAT fixed it? Where is the solution? I have the same problem.

I just added a couple of product categories to my site. Everything works fine on a desktop computer, but when I access via my tablet, there is NO WAY to use the menus because the touch screen does not have any hover. If I tap the triangle, instead of expanding the sub-menu it just goes to my home page. I tried removing the link for the HOME category, but apparently there is no way to do that (or even change the URL), at least not from the BO as far as I can tell (I looked in the top horizontal menu module configuration and in Products->Categories and can't find it. How do I make tapping the menu open a sub-menu instead of going to the link on a touch screen computer?

I realize this is an old thread, but if anyone is looking I am having this problem and would like some help. Since there does not seem to be many people having this problem, I have to believe there is some small detail I am overlooking. I'm using Prestashop 1.5.6.0 with the default theme. I have the data mining for statistics module installed and I have "save page views for each customer" and "Save global page views" both enabled (checked in the module configuration). Plugins detection is NOT enabled. I tried disabling this module then re-enabling it, then I completely uninstalled and re-installed it with no success. The ps_connections_page table remains empty.

The following tables are truncated to remove products, followed by the tables for customers and orders. This comes directly from pscleaner.php, and you should look there yourself because it also deletes files in some directories which I don't show here (such as product images). 'product', 'product_shop', 'feature_product', 'product_lang', 'category_product', 'product_tag', 'tag', 'image', 'image_lang', 'image_shop', 'specific_price', 'specific_price_priority', 'product_carrier', 'cart_product', 'compare_product', 'product_attachment', 'product_country_tax', 'product_download', 'product_group_reduction_cache', 'product_sale', 'product_supplier', 'scene_products', 'warehouse_product_location', 'stock', 'stock_available', 'stock_mvt', 'customization', 'customization_field', 'supply_order_detail', 'attribute_impact', 'product_attribute', 'product_attribute_shop', 'product_attribute_combination', 'product_attribute_image', 'attribute', 'attribute_impact', 'attribute_lang', 'attribute_group', 'attribute_group_lang', 'attribute_group_shop', 'attribute_shop', 'product_attribute', 'product_attribute_shop', 'product_attribute_combination', 'product_attribute_image', 'stock_available', 'manufacturer', 'manufacturer_lang', 'manufacturer_shop', 'supplier', 'supplier_lang', 'supplier_shop', 'customization', 'customization_field', 'customization_field_lang', 'customized_data', 'feature', 'feature_lang', 'feature_product', 'feature_shop', 'feature_value', 'feature_value_lang', 'pack', 'scene', 'scene_category', 'scene_lang', 'scene_products', 'scene_shop', 'search_index', 'search_word', 'specific_price', 'specific_price_priority', 'specific_price_rule', 'specific_price_rule_condition', 'specific_price_rule_condition_group', 'stock', 'stock_available', 'stock_mvt', For customers and orders: 'customer', 'cart', 'cart_product', 'connections', 'connections_page', 'connections_source', 'customer_group', 'customer_message', 'customer_message_sync_imap', 'customer_thread', 'guest', 'message', 'message_readed', 'orders', 'order_carrier', 'order_cart_rule', 'order_detail', 'order_detail_tax', 'order_history', 'order_invoice', 'order_invoice_payment', 'order_invoice_tax', 'order_payment', 'order_return', 'order_return_detail', 'order_slip', 'order_slip_detail', 'page', 'pagenotfound', 'page_type', 'page_viewed', 'referrer_cache', 'sekeyword',

I have some additional information/comments about this. I have version 1.5.6.0 installed. I think it is a bug (maybe not technically a coding bug, but it seems conceptually to not be quite right). I would like the opinion of someone with more experience with PrestaShop to agree or disagree with me. If it is indeed a bug,how do I report it? In /controllers/admin/AdminOrdersController.php, near line 430, the following call is made unconditionally whether the email type is TYPE_HTML, TYPE_TEXT, or TYPE_BOTH: htmlentities(Tools::getValue('message'), ENT_COMPAT, 'UTF-8'); Then if the email type is either TYPE_HTML or TYPE_BOTH, the following call is also made which adds HTML <br> tags: Tools::nl2br($customer_message->message) The resulting message is placed into the $varsTpl array (as '{$message}') to be used as replacement text in the email template(s). There are 2 problems. 1) HTML entities are always encoded for text mail (my current problem) 2) if TYPE_BOTH is selected, then the text mail ends up with <br> tags. I can think of several ways to solve both problems. I am not familiar enough with the design philosophy to know which is better, whether these cause problems I did not consider, or whether there are additional options. I prefer the second option because it preserves flexibility in hooks: 1) Don't manipulate the message text (i.e., what was entered into the form, not the template) until it is inserted into the email message (in mail.php). Insert the text version first (replace {message} in template.txt), then encode entities and add <br> to {message} before processing the html template. This centralizes the checking of the email type which is currently distributed. The drawback is that this negatively affects hooks by forcing everyone to do it the same way. 2) Code that calls Mail::Send(...) creates 2 replacement strings: {message} and {html_message}. This lets the caller (possibly in an override class) do things its own way (though you would expect most people to encode only {html_message}). The drawback is that you must change the HTML template to use {html_message} instead of {message}. Since the template text is loaded into memory (and already processed somewhat-- to remove HTML from the .txt template, for example), you could replace '{message}' with '{html_message}' in the .html template (do this in Mail.php) for backward compatibility. Any thoughts, anyone?

I am trying to send an email to a customer from the "View" page for an order (where is says "click here to add a comment or send a message to the customer"). I am using just text email, not HTML. When I insert a URL (link) in the email, it is HTML-entity encoded ("&" becomes "&", etc.). This makes the URL link I inserted unusable by the recipient. Why are text emails being encoded for HTML entities? How do I prevent this from happening?

I worked around this by editing the file /modules/pscleaner/pscleaner.php. I added "return true;" (at line 105) to bypass the check of whether or not you acknowledged the disclaimer. That change is only for clearing sales and orders history. You have to do the same thing around line 97 for clearing the catalog. WARNING: if you make these changes, your data will be cleared without any further warning or confirmation (just by clicking the button). I never figured out why the acknowledgement checkboxes are not displayed. Again, like I already stated in my original message, BE VERY CAREFUL with the "integrity check"-- it will delete things you don't expect!!

Is there nobody who can help with this????

I can't use pscleaner any more. I just upgraded today and when I click on "Delete orders and customers" it just pops up a message "Please read the disclaimer and click "yes" above". But there is no "Yes" anywhere to click. I am trying to put a new site on line and can't until I figure out how to delete my test data. I am accessing pscleaner from Modules->Modules, selecting pscleaner, then clicking "configure". I see 4 sections: Catalog, Orders and customers, Functional integrity constraints, Database cleaning. There is a button in each section, but no input elements to acknowledge the disclaimer. In pscleaner.php there is a reference to submitTruncateCatalog_on, but this element does not appear on the page. Also a comment on this module: You should warn people that running Functional Integrity Constraints will delete all messages that are not tied to a shopping cart. I ran this on another live site, never expecting that an integrity check would delete any data. But all non-order related messages are DELETED with no warning. This is really stupid-- I did not expect an "integrity check" to delete hundreds of messages (all inquiries made via the contact form that do not reference an order). Does someone at PrestaShop think these messages are not important? Now I can spend the next couple of hours restoring the lost data (yes "hours" because I have to do it in such a way that I don't lose new orders, etc. that are happening after the deletion and at some point I also must shut down the site temporarily and lose money).

I found some information concerning this problem which I posted to another thread: http://www.prestashop.com/forums/topic/287916-odd-email-characters/ Sorry, I do not provide a solution there, but I think it narrows down the true cause of the problem. I am too new to PHP and PrestaShop to give an authoratative solution and am waiting for someone with more knowledge than me to answer.