How can we help you?

My VAT number is FR86838143592

I'm a freelance in France so as a very small business I don't pay the VAT (Article 293 B of french tax law). If you check the price you will see that there is no VAT or tax included in it. 

These fake users are created by Page Cache Ultimate to anonymize the cache (new method). You must not delete them (they will be created again).

There will not have a lot of these fake users, probably less than 5, it depends on the number of groups and the differences in display between them.

They are not active so they will not disturb your statistics.

If you have an Anvato theme, here is what to do to avoid the cart to open each time it is refreshed.

Copy the file /modules/an_theme/views/js/sidebarcart.js in your theme so you can continue to update it without loosing modifications, in /themes/<your_theme>/modules/an_theme/views/js (create folders if needed)

In this file, replace the ligne:

if (prestashop.page.page_name != 'cart' && prestashop.page.page_name != 'checkout') {

By

if (prestashop.page.page_name != 'cart' && prestashop.page.page_name != 'checkout' && requestData.action!='refresh') {

Then clear the cache in Performances page and the cache of your browser so you can test.

If your theme uses the tag "widgetblock" as Warehouse theme does, then you need to clear the cache in Performances page after you enable Page Cache so the template is compiled again.

All our modules can run on LiteSpeed Web Server since it supports the Apache .htaccess file.

However, the HTML cache feature (Page Cache Ultimate) is not compatible with the LiteSpeed Cache Plugin since they are both working on the same layer of cache.

Which one should you choose?

LiteSpeed Cache is a generic cache which does not handle all different contexts of Prestashop. Which taxes are applied? Is there a flash sale comming up? Should I display a different content for this user because he belongs to a specific user group? Did this visitor accept cookies? etc.

Page Cache Ultimate has been created for Prestashop and it is only dedicated to this platform, it handles all different contexts and can also upgrade fast if a new Prestashop feature is out.

If you are using Nginx, then make sure your configuration is as follow:

"Proxy mode" must be ON, other options must be OFF.

If you are using the PageSpeed Apache module developped by Google (x-mod-pagespeed) then you must disable the following option so it does not override the browser cache directives added by Page Cache:

<IfModule pagespeed_module>
ModPagespeedModifyCachingHeaders off
</IfModule>

You can find your invoice in your JPresta account in the "Order history and details" menu.

If you don't see it make sure you registered an address in your account so the invoice can be generated.

No, it is highly recommended to keep the Smarty cache enabled. This will speed up pages that are not cached and also pages where the cache is not yet generated.

To get your styles back you just need to clear the cache of "Page Cache Ultimate".

To avoid this issue you can go in "Advanced mode", in the configuration of "Page Cache Ultimate", then in "Cache key" enable "Insert CSS and JS version in cache key".

To avoid the cookie notice to appear 1 second, then disappear, you must override the javascript file of the iqitcookielaw module.

To do it, create a file with the following content:

$(document).ready(function () {
 if (getCookie('cookielaw_module') != 1) {
  $("#iqitcookielaw").addClass('iqitcookielaw-showed');
 }
 $("#iqitcookielaw-accept").click(function (event) {
  event.preventDefault();
  $("#iqitcookielaw").removeClass('iqitcookielaw-showed');
  setcook();
 });
});

function setcook() {
 var name = 'cookielaw_module';
 var value = '1';
 var today = new Date();
 var expire = new Date();
 expire.setTime(today.getTime() + 3600000 * 24 * 14);
 document.cookie = name + "=" + escape(value) + ";path=/;" + ((expire == null) ? "" : ("; expires=" + expire.toGMTString()))
}

function getCookie(cname) {
 var name = cname + "=";
 var ca = document.cookie.split(';');
 for (var i = 0; i != ca.length; i++) {
  var c = ca[i];
  while (c.charAt(0) == ' ') c = c.substring(1);
  if (c.indexOf(name) != -1) return c.substring(name.length, c.length);
 }
 return "";
}

And place it in the theme (or child theme if you have one): /themes/warehouse/modules/iqitcookielaw/views/js/front.js

Then clear the cache in the Performances page.

When the cache is created, the page is anonymized, that means it is displayed without any information about the visitor displaying the page.

Modules that display content relative to the current visitor can be marked as dynamic, that means the content will be refreshed (replaced) by a background request (Ajax) in the browser that will carry the context of the current visitor.

If you check the option "Display nothing in cache" then the module will not be called to display its content in this hook during the creation of the cache. However, the content will be displayed as other dynamic modules (with a background request (Ajax)).

If the products list is reloaded each time you display a page with a products list then you can fix this by modifying the file /warehouse/modules/ps_shoppingcart/ps_shoppingcart.js as follow:

Replace this line:

prestashop.emit('updateFacets', window.location.href);

By:

if (event.reason && event.reason.linkAction != 'refresh') {
    prestashop.emit('updateFacets', window.location.href);
}

Update your "Cookies - GDPR Cookie law (block before consent)" module to version 1.5.6 minimum.

Update "Page Cache Ultimate" to version 7.9.39 minimum for full compatibility with the cookiesplus module.

For Prestashop 1.7

1. Disable the 2 modules (this also works if they are not yet installed)
2. In the file /modules/cookiesplus/override_17/classes/Hook.php rename the coreCallHook function to coreCallHook_off and the coreRenderWidget function to coreRenderWidget_off (in fact, Page Cache Ultimate will execute the appropriate processing if the cookiesplus module is activated).
3. You can reactivate (or install) the 2 modules.

If, after installing the module, some images on your store, such as the logo, CMS page images, back office images, etc., no longer display, it's likely due to a .htaccess file in the /img and /img/cms directories. This file blocks all PHP scripts, even if it's just a redirection (the script isn't actually in this directory).

To fix this issue, you need to add an exception for our webp.php converter as follows:

# Disable PHP globally unless explicitly re-enabled
<IfModule mod_php5.c>
    php_flag engine off

    # Enable PHP execution only for avif.php and webp.php (used by Speed Pack)
    <Files "avif.php">
        php_flag engine on
    </Files>
    <Files "webp.php">
        php_flag engine on
    </Files>
</IfModule>

# Apache 2.2 access control
<IfModule !mod_authz_core.c>
    Order deny,allow
    Deny from all

    # Allow access to static image and video files
    <FilesMatch "\.(jpe?g|gif|png|bmp|tiff|svg|pdf|mov|mpeg|mp4|avi|mpg|wma|flv|webm|ico|avif|webp)$">
        Allow from all
    </FilesMatch>

    # Allow access to avif.php and webp.php (for image conversion)
    <Files "avif.php">
        Allow from all
    </Files>
    <Files "webp.php">
        Allow from all
    </Files>
</IfModule>

# Apache 2.4 access control
<IfModule mod_authz_core.c>
    Require all denied

    # Allow access to static image and video files
    <FilesMatch "\.(jpe?g|gif|png|bmp|tiff|svg|pdf|mov|mpeg|mp4|avi|mpg|wma|flv|webm|ico|avif|webp)$">
        Require all granted
    </FilesMatch>

    # Allow access to avif.php and webp.php (for image conversion)
    <Files "avif.php">
        Require all granted
    </Files>
    <Files "webp.php">
        Require all granted
    </Files>
</IfModule>

Ou pour /img/cms/.htaccess

<IfModule mod_php5.c>
    php_flag engine off

    # Enable PHP only for avif.php and webp.php (Speed Pack)
    <Files "avif.php">
        php_flag engine on
    </Files>
    <Files "webp.php">
        php_flag engine on
    </Files>

</IfModule>

# Enable avif.php and webp.php (Speed Pack)
<Files "avif.php">
    Order allow,deny
    Allow from all
</Files>
<Files "webp.php">
    Order allow,deny
    Allow from all
</Files>


deny from all
<Files ~ "(?i)^.*\.(jpg|jpeg|gif|png|bmp|tiff|svg|pdf|mov|mpeg|mp4|avi|mpg|wma|flv|webm|avif|webp)$">
	order deny,allow
	allow from all
</Files>

Modifications done in a module, in the theme, in CSS or in Javascript cannot be automatically detected so you need to clear the cache to see the changes.

There are 3 ways to clear the cache

1. In the configuration of the module "Page Cache Ultimate", go in "Statistics" menu. You can filter pages that are concerned by your modifications. Then click on the button "Clear cache" at the bottom of the table.
2. Click on the button "Clear cache" in the configuration of the module "Page Cache Ultimate" on top and right of the screen, this will clear the cache all pages.
3. Use the URL that you will find in the "API" menu in the configuration of the module "Page Cache Ultimate"

In the configuration of the shopping cart, in section "Add to Cart Action", disable the option "Open the cart".

If you are using the module "SuperTinyMCE PRO" developed by Liewebs then you must add an exception in the configuration of this module for the controller "JprestaThemeConfiguratorLive". Also make sure to have at least version 1.2.2 of module "JPresta - Theme Configurator".

Yes, all images of your shop will be automatically converted into the WEBP format. Even images from CMS or other modules like blog.

This is normal, when the cache is not available the display is as slow as without the cache.

You should only empty the cache when necessary (CSS or Javascript modification, for templates choose the option "Recompile template files if they have been updated" in the "Performance" page).

YES you still need a WEBP module for Prestashop! Because the feature has a bug in PS 8.0. It should be fixed in PS 8.1 but I will check this as soon as it is released because I don't know if JPG images will be displayed to browsers that cannot read WEBP format like Safari (iPhone).

This has been very tricky to find a configuration that works fine. I'm not expert in the configuration of nginx so I guess there is an other way of doing it. If you want to improve this configuration then contact me, I will be happy to update this post to help other people!

Here is my solution (be kind).

Before the section "server", place this code:

map $http_accept $webp_enable {
	default 0;
	"~*webp" 1;
}

It will tell us if the browser of the visitor can read WEBP images.

You probably have multiple lines of "rewrite" for all images, place the following code just before it:

# Jpresta Speedpack
if ($webp_enable = 1) {
	# Rewrite images URL using a specific extension ".webp_compressor" so we can have specific rules to compress the image/svg
	# if the webp file is not already created.
	rewrite "^/c/([0-9]+)(\-[_a-zA-Z0-9-]*)/(.*)\.(jpg|jpeg|png)$" /img/c/$1$2.webp_compressor last;
	rewrite "^/c/([_a-zA-Z-]+)/(.*)\.(jpg|jpeg|png)$" /img/c/$1.webp_compressor last;
	rewrite "^/([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$1$2.webp_compressor last;
	rewrite "^/([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$2/$1$2$3.webp_compressor last;
	rewrite "^/([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$2/$3/$1$2$3$4.webp_compressor last;
	rewrite "^/([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$2/$3/$4/$1$2$3$4$5.webp_compressor last;
	rewrite "^/([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$2/$3/$4/$5/$1$2$3$4$5$6.webp_compressor last;
	rewrite "^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$2/$3/$4/$5/$6/$1$2$3$4$5$6$7.webp_compressor last;
	rewrite "^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$2/$3/$4/$5/$6/$7/$1$2$3$4$5$6$7$8.webp_compressor last;
	rewrite "^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$2/$3/$4/$5/$6/$7/$8/$1$2$3$4$5$6$7$8$9.webp_compressor last;
	# all other images
	rewrite "^(.+)\.(jpg|jpeg|png)$" $1.webp_compressor last;
}

location ~* ^(.+)\.webp_compressor$ {
	# Indicates to proxies that the file content/format depends (Vary) on the "Accept" header
	add_header Vary Accept;

	# Indicates to proxies that the file can be cached for the max duration
	add_header Pragma public;
	add_header Cache-Control "public, must-revalidate, proxy-revalidate";
	expires max;

	# Indicates to nginx not to log access
	access_log off;
	log_not_found off;

	# Try to serve the WEBP file directly or compress the image
	set $url_webp_compressor "/modules/jprestaspeedpack/controllers/front/webp.php?src=$1.jpg";
	try_files $1.webp $url_webp_compressor;
}

WARNING: if you are using the standalone WEBP compression module then you must replace 'jprestaspeedpack' by 'jprestawebp'.

Contact me if you need help or if you can improve the script!

If the currency selection list does not work anymore, check these 2 options:

The option "Ignore URLs matching this regex" must include ".*SubmitCurrency=1.*", e.g. ".*[\?&]q=.*|.*SubmitCurrency=1.*"

The option "Ignored URL parameters" should not include "submitcurrency,id_currency"

You may also want to disable the browser cache, because if the visitor changes the currency after displaying several pages, if they return to these pages, the original currency will be displayed.

Don't forget to clear the module and browser cache after these changes.

Unable to get cache-warmer informations from the shop (maybe the module is disabled or uninstalled): Read timed out

If you see this error in the log of the cache-wamer, that means there is a timeout when the cache-warmer retrieves the pages to warm up. To avoid this timeout, in the configuration of Page Cache Ultimate, click on "Advanced mode", then in the menu on "Options" and set a lower value for "Max execution time in seconds".

​Yes, browsers that cannot read WEBP format will get the original format (JPG/PNG).

When you modify a product, a category, a CMS page, a price, the stock, etc. the cache is automatically refreshed.

When you add, delete or modify a module, then you need to clear the cache manually because this cannot be automatically detected. For exemple, when you modify the slider of the home page.

When you modify the CSS or a template of your theme, then you need to clear the cache manually because this cannot be automatically detected.

When you synchronize or modify your catalog, your prices and/or your stocks using an external application, you will probably need to clear the cache manually or with a script because hooks of Prestashop are not executed.

To clear the cache of specific pages, you can use the CRON/API URLs that you will find in the "API" menu in the configuration of Page Cache Ultimate. You can also use the statistics table to filter pages that you want to refresh, then click on button "Clear cache (only files)".

Also be aware that the browser cache cannot be cleared, this is why it is limited in time.

This happens because the sign in link is loaded dynamically and so the "back" parameter which referers to the current URL is set with the URL of the dynamic modules.

To avoid this problem, go in the configuration of Page Cache Ultimate, in menu "Dynamic modules and widgets", at the bottom add the following javascript code to the field "Javascript to execute":

if (!prestashop_pc.customer.is_logged) {
  $('header a').each(function() {
    $(this).attr('href').replace('ajax%3Dtrue', '').replace('page_cache_dynamics_mods%3D=1', '')
  });
}

Clear the cache and it should fix the problem.

​These directories are created when the cache cannot be fully deleted in PHP because it's too long and will failed with a timed out error. So instead of deleting the cache directory, it is simply renamed with this suffix.

You can delete all these directories with suffix please_delete_me but I recommend to do it directly in a server console because it will be too long to do it by FTP.

These hooks are for developers of modules, contact the support if you need help.

Here is an exemple of how to implement the hooks' functions:

    /**
     * Called each time a page is displayed so this must remain very fast!
     * @param $params Empty array
     * @return mixed The datas you will need in hookActionJPrestaRestoreSpecificCacheKeyInfos()
     */
    public function hookActionJPrestaGetSpecificCacheKeyInfos($params) {
        // Let's say that the cookie 'test' modify the content of the page, we indicates to the cache manager
        // to generate a cache key that depends on the value of this cookie
        return $_COOKIE['test'];
    }

    /**
     * This function is called by Page Cache Ultimate when the cache-warmer service want to generate the cache of a
     * specific context. In this case we must restore the context so the content is the good one.
     * @param $params $params['specifics'] contains the datas returned by the hook 'ActionJPrestaGetSpecificCacheKeyInfos'
     */
    public function hookActionJPrestaRestoreSpecificCacheKeyInfos($params)
    {
        // Here we will just modify the $_COOKIE value, we don't need to send the cookie to the browser with function
        // setcookie, we just want the remaining PHP code to execute to get the correct value of the cookie.
        $_COOKIE['test'] = $params['specifics'];
    }

Warmup duration depends on 3 factors:

• The number of pages to generate: the first warmups generally contain a lot of pages, which is normal, and this number will decrease with each warmup
• The maximum number of bots you've defined: this is 30 by default, but you can reduce it to 5 bots to lighten the server load, but this obviously extends the time of each warmup
• Page TTFB without cache: if server response time is long without cache (> 3s), you may need to analyze Prestashop's slowness

Cache-warmer bots are probably considered as SPAM bots by your hosting provider. To make it work, you need to indicates in the settings of your hosting provider that the user-agent "JPresta-Cache-Warmer" is allowed.

Compared to the number of products and categories you have, you didn't think you'd have so many pages to generate, and that's normal!

The cache-warmer will generate the pages of your Prestashop store in different contexts. For example, you'll have one context for cell phones, another for computers, one for visitors and another for connected customers, and so on.

So the number of pages is multiplied by the number of contexts.

If your subscription includes only one warmup, then yes, you can specify the time of the warmup.

If your subscription package includes several warmups, then you can specify the start time of the first warmup, and subsequent warmups will be run at regular intervals.

JPresta-Cache-Warmer uses Amazon servers (AWS) to ensure a stable and efficient service regardless of the number of subscribers. 

If you want cache-warmer robots not to be banned by your hosting provider then you must authorize requests from the following IPS : 18.119.72.109 and 18.189.172.189

When using native Prestashop statistics, to avoid the cache-warmer to be included into the statistics just add this override in /override/classes/Connection.php:

class Connection extends ConnectionCore
{
    public static function setNewConnection($cookie)
    {
        if (isset($_SERVER['HTTP_USER_AGENT'])
            && preg_match('/JPresta-Cache-Warmer/i', $_SERVER['HTTP_USER_AGENT'])) {
            // This is the cache-warmer : don't log connection
            return false;
        }
		return parent::setNewConnection($cookie);
	}
}

The Creative Elements module allows you to edit parts of your store with links/buttons displayed directly on your shop when you are logged into your Prestashop admin. To preserve this functionality, the cache is deactivated with the reason "editing-with-creative-element". Rest assured, your visitors do benefit from the cache, it's only users connected to the admin who have no cache. To get the cache, simply display the store in a private tab of your browser.

The first thing to do is to make sure you have the latest version of the module, as I'm constantly improving it to reduce memory consumption, both on the database side and on the hard disk.

The second thing is to run a purge periodically (every 2 or 3 days). A purge removes the cache of pages that no longer exist or whose context no longer exists. This does not affect cache performance. You can perform a purge manually via a button under the cache statistics table, or by scheduling a CRON task with the URL displayed in the "API (CRON URLs)" menu of the module configuration.

Finally, if there are directories in /var/cache/pagecache ending in "please_delete_me", you can delete them. These are old caches that PHP was unable to delete completely (too long).

When you try to install Page Cache Ultimate you get the error message "This file does not appear to be a valid module .zip file"? This is normal, as the zip file contains several zips that allow you to install this module depending on your Prestashop version: PS-1.5/1.6, PS1.7/8 and Thirtybees.

You'll need to extract and install the appropriate zip for your store.

The module does not call the Hook which allows the update.

You must modify the imageResize() function in the /modules/prestablog/prestablog.php file:

Replace this

         return ImageManager::write('jpg', $dest_image, $file_after);

By this

         $ret = ImageManager::write('jpg', $dest_image, $file_after);

         Hook::exec('actionOnImageResizeAfter', ['dst_file' => $file_after, 'file_type' => 'jpg']);

         return $ret;

​​Afterwards your images will be updated.

​

Static caching can only be used if the visitor's context is known. The context contains a great deal of information that cannot be deduced from the URL alone: currency, user groups, choice of cookies, taxes to be applied, etc. This context is stored in a cookie called "jpresta_cache_context".

This context is stored in a cookie named "jpresta_cache_context", which is added when the user displays a 1st page. Once the cookie is present, the static cache can be used.

Go in the configuration of the module, in menu "Caching system" make sure "Prestashop Static!" is selected. If it is already selected, then select "Standard file system" and save, after that select "Prestashop Static!" and save again. This will reactivate the static cache.

The "customer-specific-prices" message means that you're connected to a user who has specific pricing rules, so there's no need to create a cache as only he will be able to benefit from them. It's better to create groups of users and create pricing rules for these groups.

Perhaps you're simulating a phone screen using the console of your browser, which explains why you're seeing this mobile view despite having a desktop screen.

This occurs because a cookie called 'jpresta_cache_context' stores the visitor's context in the browser. This context includes information about whether the view is 'mobile' or 'desktop'. Therefore, if you initially view pages in desktop mode and then switch to mobile mode, the cache will continue to deliver the desktop view.

If you wish to test the mobile view using the console of your browser, ensure you delete the 'jpresta_cache_context' cookie beforehand.

No, our module is designed to convert JPG/PNG images to WEBP format. It is recommended to import images as JPG due to compatibility issues with certain browsers that cannot load WEBP files. Additionally, using JPG as original images ensures better quality since Prestashop creates multiple formats and sizes of images based on the original, emphasizing the need for good-quality originals.

If you are using the module "Google Tag Manager Enhanced Ecommerce" created by "Comptoir du code" then make sure to get the latest version of the module and enable the specific option for use with full page cache modules.

In any case you don't need to mark Google Tag Manager modules as dynamic.

The scores calculated by Pagespeed and GTMetrix include a very large number of parameters whose importance varies depending on whether you are on a mobile phone or a computer.

The Prestashop Speed ​​Pack module allows you to correct the following points reported by Pagespeed Insight or GT Metrix:

• Reduce server response times (TTFB)
• Defer off-screen images
• Serving images in next-generation formats

Other parameters like LCP cannot be corrected by a module. For example, this LCP indicates the display delay of the largest element displayed first; it is often degraded by the use of a carousel which displays images in lazy loading or because the javascript code which initializes it is too slow. This kind of problem can only be fixed manually.

Also, to be sure that the score calculation was done with an available cache, run it twice.

I invite you to read my article to fully understand this Pagespeed score for Prestashop .

When you validate the configuration steps, make sure to run the auto-configuration at step 4. This configures the Page Cache Ultimate module for all known modules like the shopping cart. You should rely on this auto-configuration and only do manual modifications when something does not work as usual when the cache is enabled.

The score calculated by Pagespeed and GTMetrix include a very large number of parameters whose importance varies depending on whether you are on a mobile phone or a computer.

The Prestashop Speed Pack module allows you to correct the following points reported by Pagespeed Insight or GT Metrix:

• Reduce server response times/TTFB  (Page Cache Ultimate)
• Serving images in next-generation formats (WEBP compression of images)
• Defer off-screen images (lazy loading of images)

Other parameters like the LCP cannot be corrected by a module. For example, this LCP indicates the display delay of the largest element displayed first; it is often degraded by the use of a carousel which displays images using a lazy-loading system or because the javascript code which initializes it is too slow. This kind of problem can only be fixed manually.

Also, to be sure that the score calculation was done with an available cache, run it twice.

I invite you to read my article Understand and improve the Pagespeed score of your Prestashop store  

A page can have multiple cache versions depending on the context of the visitor. This context includes information such as the selected currency, the user's group, the visitor's preferences concerning cookies, applicable tax rules for the visitor, the visitor's country if relevant, and more. Therefore, you might not receive a cached page when you display a page because your context is different.

Modules like "Creative Slider" use short codes to make it easy to display contents. This is usually done in the hook "actionOutputHTMLBefore" so just make sure that the cache module is placed after all modules in this hook. Go in "Design" > "Positions", check the option "Display non-positionable hooks", search for the hook "actionOutputHTMLBefore" and move Page Cache Ultimate or Speed Pack module to the end.

​Once done you need to clear the cache.

This error is due to a new security restriction implemented by my hosting provider (OVH) on all their servers.

To resolve it, you need to upgrade my modules to the latest version.

You won’t be able to do this using the JPresta Easy Upgrade module, as it also requires an update.

To perform the upgrade, go through the Addons or download the zip file from your JPresta account. For Page Cache Ultimate and Speed Pack, you’ll need to extract the zip to find the one that matches your PrestaShop version. Once you have the correct zip file, install it as a new module to upgrade your current version while preserving the configuration.

Don’t worry, after this, you’ll be able to continue upgrading with JPresta Easy Upgrade as usual.

Error code 524 usually means that the request to retrieve the list of URLs to generate took too long.

To avoid this error:

1. Go to the configuration of Page Cache Ultimate (or Speed Pack).
2. Click on Advanced mode and then on Options.
3. Set the option Max execution time in seconds to 90 seconds (or less if it is already 90s).

To avoid caching certain pages in your store, you can use a regular expression.

Go to the module configuration, click on "Advanced mode" and then on "Options". You'll find a "Ignore URLs by regular expression" field. This field is pre-filled by default with the following regular expression:

.*[\?&]q=.*|.*SubmitCurrency=1.*

With this regular expression, the module will exclude all searches from the cache (using the "q" parameter) as this is not efficient, since the number of identical searches is very low. It will also deactivate the cache when a currency change occurs.

To add a page to exclude, you can add another expression with a "|" character after it. For example, if you want to exclude the page https://shop.com/85-foo :

.*[\?&]q=.*|.*SubmitCurrency=1.*|.*85-foo.*

For more information on regular expressions, please consult this documentation: https://www.php.net/manual/en/reference.pcre.pattern.syntax.php

To test your regular expression, use this tool: https://regex101.com/

When the cache is enabled, the JavaScript (JS) variable "prestashop" does not contain information about the current visitor/customer. Indeed, the cache is anonymized.

You need to wait until the dynamic modules are refreshed for this information to become available.

Here is a script that will allow you to access the information as soon as it is available:

if (typeof jprestaGetCacheType == 'function') {
    // jprestaDynamicContentLoaded will be triggered
    prestashop.on('jprestaDynamicContentLoaded', function() {
        // Here, the variable 'prestashop_pc' can be used like the variable 'prestashop'
        // Everything defined in Media::addJsDef is also updated
        console.log('The jprestaDynamicContentLoaded event has been triggered and received');
        if (prestashop_pc.customer.is_logged) {
            console.log('Customer ' + prestashop_pc.customer.email + ' is logged in.');
        } else {
            console.log('No customer is logged in.');
        }
    });
} else {
    // Normal processing, no cache
    // jprestaDynamicContentLoaded will not be triggered
    console.log('This page is not cached');
    if (prestashop.customer.is_logged) {
        console.log('Customer ' + prestashop.customer.email + ' is logged in.');
    } else {
        console.log('No customer is logged in.');
    }
}

The number of pages to generate varies because the module only generates pages that either don't have a cache, have an expired cache, or have a cache that will expire within 24 hours.

You may notice periodic spikes in the number of pages to generate as the cache expires, this is normal.

The percentage you can adjust in the module corresponds to a quality level rather than a compression percentage. 100% means maximum quality with no loss, while 50% represents reduced quality with greater compression.

As a general rule, 80% offers a good compromise between quality and file size. However, the choice depends on your needs and the type of image used. That is why we provide a comparison tool directly in the Prestashop module.

The cache warmer generates the cache for pages in multiple contexts. By default, these contexts are automatically selected (recommended) based on the number of affected visitors.

Once the warmup process has completed, if you notice that the cache is not generated for you, it means your context was not included by the cache warmer. To understand why, you can check your context by opening the browser console.

• On Windows/Linux: Press F12 or Ctrl + Shift + I
• On Mac: Press Cmd + Option + I

Look for a line that says: "Page Cache Ultimate - Displaying the page with context <Your Context ID>".

Next, go to the cache module's configuration, open the Statistics menu, and find your context in the table. This should help you understand why it was not generated by the cache warmer (check the number of visits).

This warning occurs when the module detects that the shop has been duplicated, typically for testing purposes. While this is perfectly allowed, it can interfere with the cache warmer service. To prevent any issues, you need to confirm whether this PrestaShop instance is a clone. This allows the module to correctly apply the license and cache warmer subscription.  

Go in the configuration of the module, in the "License" menu

• If this is a copy of another PrestaShop instance, click "Yes, it is a clone"
• If it is the same PrestaShop instance, click "No, it is the same PrestaShop"

For your information, the detection is primarily based on database information.

Some security systems, such as Imunify360, may block the module’s ZIP file, mistakenly identifying it as malware.

If you are unable to install or update the module via the Modules tab in PrestaShop or with JPresta Easy Upgrade, try temporarily disabling your anti-malware solution before retrying.

Technically yes, but in practice you need an "Enterprise" subscription — the one without a listed price, so probably over €2400/month at the time of writing.

Indeed, you need to be able to configure the cache key, and that’s only possible with an "Enterprise" plan. If you have one, feel free to contact me — I can help you set up the cache rules.

AVIF is a new, high-performance image format that is more recent than WEBP. It significantly reduces image file sizes while maintaining excellent visual quality.

On average, AVIF compresses images up to 50% more efficiently than WEBP, which already reduces file sizes by 30–40% compared to JPEG. This means a faster website, a better user experience, and improved SEO.