GuusMichielsen

I came here looking for this exact problem. I assume the blocktags-module doesn't have a stylesheet in the [root]/modules/blocktags folder? (If it does, you should be able to override the css by using the same folder-structure in [root]/themes/your-theme/modules/blocktags - and place your css in the equivalent place.) What I ended up doing was: 1. Register the new stylesheet (Basically tell Prestashop there is a new stylesheet available) in a php-file that extends the module-php, and place it in the [root]/override/modules/module-name folder (You probably have to create this folder). It should look something like this: <?php class BlocktagsOverride extends Blocktags { public function hookHeader() { $this->context->controller->registerStylesheet('modules-blocktags', 'modules/'.$this->name.'/css/blocktags.css', ['media' => 'all', 'priority' => 150]); } } ?> 2. Create the new stylesheet and place it in [root]/themes/your-theme/modules/module-name/css (Or wherever you point when registering the stylesheet) 3. See the magic happen (if not; clear cache and pray) I have to add that I'm not super confident about this solution, it works, but I'm not sure this is how it is intended. What I would like is to override the php in the theme-folder (and not the [root]/override folder), because if the theme is swapped out, the css in the theme is gone which makes the override unnecessary. Guus

I'm sorry, I'm not trying to be rude here, and I appreciate the time you've spend trying to help me, but I don't believe this is true. I cannot believe it is by design that the comments left during checkout are not visible, why would the textarea be there if the messages left there won't ever reach me? However, I'll have a look at your module. Thank you!

Unfortunately, in my case, they don't. That is exactly my problem, and the reason I'm asking this question. I believe you, when you say they should be there, but somehow they aren't in my case. They are indeed send before the order is completed, because the order is finalized after the payment, but the payment happens after filling out the checkout-page. I believe this is the case with everybody, not me specifically. Or, should the order-confirmation assign an id_order to this message, and is this simply not happening in my case?

I'm searching for the messages left by the customer during checkout. On the checkout-page (I'm using one page checkout) there is a textarea with the title 'If you would like to add a comment about your order, please write it in the field below.' above it. The messages left in this textarea are stored in the ps_message table in the database. If they have a value in the column 'id_order', these messages show up in the Order Area in the backoffice, but if they don't have an Order ID, they are nowhere to be found.

ndiaga, thank you for the quick response. Could you elaborate on this? If you mean the Customer-area in the BO, they aren't showing up there. Comments left in the 'Customer Service'-form however do show up there. This area only shows messages stored in the ps_customer_message-table, but not the messages in the ps_message-table.

Hi all, I can't figure out how to get the comments a customer leaves when finishing an order to show up in the back office. (The comments left in the box: 'If you would like to add a comment about your order, please write it in the field below.') These comments are successfully stored in the database (table: ps_message), but in the BO they are nowhere to be seen. All the records in the ps_message-table with an id_order associated with them are visible, but since the missing comments are added to the db before the order is finalized they only have a cart ID, not an order ID. I seem to remember that in the past we got Push Notifications when a customer left these messages, but somewhere along the line these stopped coming. I'm sure I have myself (or a third party module) to blame for this, but I have no idea where to start looking. (Prestashop Version: 1.6.1.4) Thanks!

Ok, I'm making some progress... I'm starting to think there is something entirely different going on in my case, I think it's a third-party module that's playing fast and loose with the addresses. Storing temporary addresses, removing them later on, storing permanent changes, etc.. I think this causes problems while having APC activated. Not so much because I'm retrieving old cached results, but because the module is confused by the caching. I'll get back to you when I understand what is going on , because now I'm confused as heck.

In my case, the BO works as expected. It is the FO I'm worried about. It does indeed seem like the queries are cache, which as I understand it isn't bad behavior (or is it?). What I'm worried about, is that when personal information changes (i.e. the customers address), this should trigger a purge of the cached value. The code in for instance classes/address.php does reflect this (as far as I understand it). In the update-function for instance, before updating the information it calls Customer::resetAddressCache(...). Shouldn't this purge the cached query? It's very likely I'm interpreting things wrong, I'm far from an IT-expert. But I'm willing to learn . Thanks for taking a look at this.

Prestashop: 1.6.1.4 PHP: 5.4.45 APC: 3.1.13 (I've also tried PHP 5.5 with APCu, same issue there) I'm currently doing some extensive testing, I'll get back to you once I've got some more details.

I'm experiencing more or less the same problem. When I use APC cache, the address-information won't refresh until I manually clear the APC-cache. This happens when the customer creates a new address or updates an address. For instance, as long as the APC-cache isn't cleared manually after updating the address, the customer keeps seeing his/her old address.

In essence this is actually the same as the code I posted, only your version has no {}-brackets for opening and closing the if-statement. You'll have to apply the fix as follows: // if (!$this->isCached(_PS_THEME_DIR_.'product-list-colors.tpl', $this->getColorsListCacheId($product['id_product']))) $products_need_cache[] = (int)$product['id_product']; Add the two frontslashes (//) in front of the if-statement. Hope this helps.

I'm glad to read the problem is solved! Good luck with your shops!

JoseR and RamboRich, I'm fairly certain this problem has to do with caching and should be located in the function I suggested. Perhaps this could help you https://www.prestashop.com/forums/topic/471693-color-list-container-ne-saffiche-pas/?p=2227044. (It's in French, but if you don't speak French, Google Translate should be able to help you )

JoseR, Have to tried changing the FrontController like I suggested?

After browsing around a bit, I also couldn't figure out what the problem is. Have you tried temporarily turning on error reporting? When this isn't on, Prestashop doesn't show errors it encounters. This could point you in the right direction. If no errors show up, you'll have to drill down the code to pin-point the location where the problem is. The colors are added to the category-page in the products-list.tpl, somewhere inside this code (depending on your theme) there should be a few lines of code similar to this: {if isset($product.color_list)} <div class="color-list-container">{$product.color_list}</div> {/if} This part is working fine on your website, since the color-list-container - div is appearing. Therefore the {$product.color_list} - part is the problem. In the FrontController.php (here: your-ps-directory/classes/controller) the colorlist is generated. This is most probable the point where something is going wrong. In the FrontController.php, find the addColorsToProductList - function. You'll see this function works with cached values, this part is (as far as I can tell) a little buggy. When you browse the prestashop-forum, you'll see multiple fixes for this function. I think the problem will be solved when you find the right one. The first thing I would try is replacing this line: $tpl = $this->context->smarty->createTemplate(_PS_THEME_DIR_.'product-list-colors.tpl', $this->getColorsListCacheId($products[ $key ]['id_product'])); with this line: $tpl = $this->context->smarty->createTemplate(_PS_THEME_DIR_.'product-list-colors.tpl'); I believe this could solve your problem, if not: try googling for 'addcolorstoproductlist prestashop', you'll find multiple edited versions of this function. I'm confident one of the versions will fix it for you. An important sidenote: The best way to edit these controllers is by creating an override for the function instead of simply replacing the code inside the original file. This way, if you update your prestashop-version, the code-changes aren't lost. To override this function, create a file called 'FrontController.php' in 'your-ps-folder/override/classes/controller' and add this code to the file: <?php /** * Extend FrontController */ class FrontController extends FrontControllerCore { // YOUR CODE HERE!! } After creating this file, copy-paste the addColorToProductList-function from the original FrontController to this override (instead of // YOUR CODE HERE!!) and do the codechanges there. As stated above, I'm not an expert on this matters. If someone notices I've explained something wrong, please correct me. Guus