Installation & Setup

Understanding Linux File Permissions

Every file and directory on a Linux server has three sets of permissions: one for the owner, one for the group, and one for others (everyone else). Each set controls three actions: read (r), write (w), and execute (x). These permissions are represented numerically using octal notation, where read equals 4, write equals 2, and execute equals 1. The values are added together for each set, producing a three-digit number like 755 or 644.

For example, a permission of 755 means the owner can read, write, and execute (7 = 4+2+1), while the group and others can only read and execute (5 = 4+0+1). A permission of 644 means the owner can read and write (6 = 4+2+0), while the group and others can only read (4 = 4+0+0). Understanding this system is fundamental to running a secure and functional PrestaShop store.

Beyond the numeric permissions, every file has an owner and a group associated with it. On a web server, the web server process (Apache or Nginx) runs as a specific user, typically www-data on Debian/Ubuntu or apache/nobody on CentOS/RHEL. The web server needs to read your PrestaShop files to serve them, and it needs write access to certain directories for uploads, caching, and configuration.

Correct Permissions for PrestaShop Directories and Files

The general rule for PrestaShop is straightforward: directories should be 755 and files should be 644. This gives the owner full control, while the group and others can read (and execute/traverse in the case of directories) but cannot modify anything. The web server user should be the owner of all PrestaShop files, or at minimum belong to the group that owns them.

To set these permissions across your entire PrestaShop installation, connect to your server via SSH and run:

find /var/www/html/prestashop -type d -exec chmod 755 {} \;
find /var/www/html/prestashop -type f -exec chmod 644 {} \;

Replace /var/www/html/prestashop with the actual path to your PrestaShop installation. The first command finds all directories and sets them to 755. The second finds all files and sets them to 644.

However, certain directories require write access by the web server. These directories need special attention because PrestaShop writes to them during normal operation:

/var/cache/ — Smarty compiled templates and Symfony cache
/var/logs/ — Application log files
/upload/ — Customer file uploads
/download/ — Virtual product files
/img/ — Product images, category images, CMS images
/modules/ — Module installation and updates
/themes/ — Theme cache files
/translations/ — Translation export files
/config/ — Configuration files (parameters.php)
/app/config/ — Symfony configuration
/app/Resources/translations/ — Symfony translations

If the web server user is the owner of these files (which is the recommended setup), then 755/644 permissions are sufficient. If the web server runs as a different user, you may need to adjust group permissions or ownership.

Setting Correct Ownership with chown

Ownership is just as important as permissions. The chown command changes the owner and group of files. For a typical Debian/Ubuntu server running Apache or Nginx, the web server user is www-data:

sudo chown -R www-data:www-data /var/www/html/prestashop

The -R flag applies the change recursively to all files and subdirectories. On CentOS or RHEL systems, replace www-data with apache or nginx depending on your web server.

A common alternative approach is to set the owner to your SSH/FTP user and the group to the web server user. This lets you edit files via FTP or SSH while still allowing the web server to read them:

sudo chown -R yourusername:www-data /var/www/html/prestashop

In this case, directories that need write access by the web server should be set to 775 (group write) and writable files to 664:

find /var/www/html/prestashop/var -type d -exec chmod 775 {} \;
find /var/www/html/prestashop/var -type f -exec chmod 664 {} \;
find /var/www/html/prestashop/img -type d -exec chmod 775 {} \;
find /var/www/html/prestashop/img -type f -exec chmod 664 {} \;

Shared Hosting vs VPS vs Dedicated Server

The hosting environment dramatically affects how file permissions work in practice. Understanding the differences is critical to setting up permissions correctly.

Shared Hosting

On shared hosting, you typically access files via FTP or a file manager in cPanel/Plesk. The PHP execution model varies by host, but most modern shared hosts use PHP-FPM or suPHP, meaning PHP runs as your user account rather than as the global web server user. This simplifies permissions significantly: since PHP runs as your user, it can already read and write to your files with standard 755/644 permissions. You rarely need to change ownership on shared hosting because everything already belongs to your account.

If you encounter permission errors on shared hosting, check with your host whether they use suPHP or PHP-FPM. If they use the older mod_php model, you may need to set some directories to 777 temporarily (though this is not recommended for security reasons). Most reputable hosts have moved away from mod_php precisely because of these permission complications.

VPS (Virtual Private Server)

On a VPS, you have full control. This is the most common setup for serious PrestaShop stores. You should ensure the web server user owns the PrestaShop files or, at minimum, belongs to a group that has read access. The recommended setup is:

Set the owner to www-data:www-data (or your web server user)
Use 755 for directories and 644 for files
Use SSH with sudo for making changes, or add your SSH user to the www-data group

To add your SSH user to the web server group:

sudo usermod -a -G www-data yourusername

Then set the group write bit on directories you need to edit:

chmod g+w /var/www/html/prestashop/themes/your-theme/

Dedicated Server

Dedicated servers follow the same principles as VPS setups. The main difference is performance: you have more resources, so you can run PHP-FPM with dedicated pools per site. Each pool can run as a different user, providing better isolation if you host multiple PrestaShop stores on the same server.

PHP Execution Models: suPHP vs mod_php vs PHP-FPM

The way PHP is executed on your server directly determines which user writes files and therefore what permissions are needed.

mod_php (Apache module)

This is the oldest and simplest model. PHP runs as part of the Apache process, meaning all PHP code executes as the Apache user (typically www-data or apache). The problem is that files created by PHP (cache, uploads, etc.) are owned by the web server user, not your account. This can make FTP management difficult and creates security concerns on shared hosts because all sites run as the same user.

With mod_php, PrestaShop files should be owned by the Apache user, and permissions of 755/644 work correctly. However, this model is largely obsolete on modern servers.

suPHP

suPHP runs PHP as the file owner rather than as the web server user. This means if your files are owned by yourusername, PHP also runs as yourusername. This is more secure on shared hosting because each account is isolated. Standard 755/644 permissions work perfectly with suPHP because the PHP process and the file owner are the same user.

One important caveat: suPHP actually rejects files with permissions of 777 or files owned by other users. If you set 777 on a suPHP server, PHP will refuse to execute those files, showing a 500 Internal Server Error instead.

PHP-FPM (FastCGI Process Manager)

PHP-FPM is the modern standard. It runs PHP as a separate process from the web server, with configurable user/group per pool. On a VPS, PHP-FPM typically runs as www-data. On shared hosting with CloudLinux or similar, each account gets its own PHP-FPM pool running as that account's user.

PHP-FPM combined with Nginx is the recommended setup for PrestaShop performance. The standard 755/644 permission scheme works well. Ensure the PHP-FPM pool user matches the file owner or has appropriate group access.

Why 777 Permissions Are Dangerous

Setting permissions to 777 means anyone on the system can read, write, and execute the file. On shared hosting, this means other accounts on the same server could potentially read your database credentials from parameters.php or inject malicious code into your PHP files.

Even on a VPS where you are the only user, 777 is unnecessary and indicates a misconfiguration. If the web server cannot write to a directory with 755 permissions, the solution is to fix the ownership, not to open permissions to the world. Here is what you should do instead of using 777:

Check who the web server runs as: ps aux | grep -E "apache|nginx|httpd"
Check file ownership: ls -la /var/www/html/prestashop/
Fix ownership: sudo chown -R www-data:www-data /path/to/directory
Set correct permissions: chmod 755 /path/to/directory

If you find a tutorial or forum post recommending 777 for PrestaShop, it is outdated and dangerous advice. The only legitimate use of 777 is for /tmp directories that have the sticky bit set (shown as 1777), which is a system-level configuration, not something you apply to PrestaShop files.

Docker Considerations for PrestaShop

Running PrestaShop in Docker introduces additional complexity to file permissions. Inside the container, the web server runs as www-data with a specific UID (often 33 on Debian-based images). On the host system, your user has a different UID. When you use Docker bind mounts to mount your PrestaShop files into the container, the file ownership is determined by the numeric UID, not the username.

This means files created on the host as your user (e.g., UID 1000) will appear inside the container as UID 1000, which is not www-data (UID 33). The web server inside the container may not be able to write to these files.

Solutions for Docker permission issues include:

Match UIDs: Create a user inside the container with the same UID as your host user, or change the web server to run as your UID.
Use chown in entrypoint: Add a startup command that runs chown -R www-data:www-data /var/www/html when the container starts. This is simple but can be slow for large installations.
Set group permissions: Add your host user and www-data to the same group (by GID), then use 775/664 permissions.
Named volumes: Use Docker named volumes instead of bind mounts. Docker manages permissions automatically, but you lose direct filesystem access from the host.

For development environments with bind mounts, the most practical approach is to run a chown command after syncing or deploying files:

docker exec your-container chown -R www-data:www-data /var/www/html/modules/your-module/

Be aware that operations inside the container (like installing a module) may create files as www-data, while operations on the host create files as your host user. This constant UID mismatch is the most common source of permission problems in Dockerized PrestaShop setups.

Troubleshooting Common Permission Errors

"Failed to open stream: Permission denied"

This error means PHP cannot read or write a file. Check ownership and permissions of the file mentioned in the error. The most common cause is that the web server user does not own the file or directory. Fix it with:

sudo chown www-data:www-data /path/to/file
sudo chmod 644 /path/to/file

"Unable to write to cache directory"

PrestaShop's Smarty template engine and Symfony framework both write cache files. If the var/cache/ directory is not writable, you will see this error. The cache directory must be owned by the web server user:

sudo chown -R www-data:www-data /var/www/html/prestashop/var/cache/
sudo chmod -R 755 /var/www/html/prestashop/var/cache/

After fixing permissions, clear the existing cache by deleting the contents of the cache directories:

sudo rm -rf /var/www/html/prestashop/var/cache/prod/*
sudo rm -rf /var/www/html/prestashop/var/cache/dev/*

"Cannot upload image" or "Cannot install module"

Image uploads go to the img/ directory, and module installations write to the modules/ directory. Both must be writable by the web server user. Additionally, check that the upload_max_filesize and post_max_size PHP settings are large enough for your files, as these can produce similar-sounding errors.

sudo chown -R www-data:www-data /var/www/html/prestashop/img/
sudo chown -R www-data:www-data /var/www/html/prestashop/modules/

"index.php is not writable" during updates

PrestaShop's auto-updater needs write access to nearly every file in the installation. Before running an update, set ownership of the entire installation to the web server user. After the update completes, you can restore more restrictive ownership if desired.

White page after changing permissions

If you see a blank white page after changing permissions, you may have accidentally removed execute permission from directories. Directories need the execute bit to be traversed. A directory with permission 644 (no execute) is effectively inaccessible. Always use 755 for directories, never 644.

You can also check the PHP error log for more details:

sudo tail -50 /var/log/apache2/error.log
# or for Nginx:
sudo tail -50 /var/log/nginx/error.log

Permissions reset after FTP upload

Some FTP clients set their own default permissions when uploading files. Check your FTP client settings for a "default permissions" or "umask" option. Set it to create files as 644 and directories as 755. Alternatively, run the permission fix commands after each FTP upload.

Security Best Practices Beyond Permissions

Correct file permissions are only one layer of security. Consider these additional measures:

Restrict config file access: The file app/config/parameters.php contains your database credentials. Ensure it is readable only by the web server user (640 permission), not by the world.
Disable directory listing: Add Options -Indexes to your Apache configuration or autoindex off; to Nginx to prevent visitors from browsing directory contents.
Protect .htaccess files: PrestaShop places .htaccess files in sensitive directories. Do not delete them.
Remove install directory: After installation, delete the /install/ directory completely. PrestaShop warns you about this, but it is worth emphasizing.
Set proper umask: Configure your web server and PHP-FPM with a umask of 0022 so new files are created with 644/755 permissions by default.

By understanding Linux permissions, matching them to your hosting environment, and following the guidelines in this article, you will avoid the most common PrestaShop permission problems while maintaining a secure server configuration.

For more details, read our guides: PrestaShop Security Hardening: The Complete Checklist and Choosing Hosting for PrestaShop: What Matters and What Is Marketing.

Read full answer

When Module Updates Go Wrong

You updated a PrestaShop module and now something is broken. Maybe the checkout stopped working, the homepage is throwing errors, or the admin panel has become unresponsive. Module updates can fail for many reasons - incompatible PHP versions, conflicts with other modules, database migration errors, or simply bugs in the new version. Whatever the cause, you need to roll back quickly to restore your store's functionality.

Unfortunately, PrestaShop does not include a built-in "undo" button for module updates. There is no native version history or automatic rollback mechanism for individual modules. This means you need to handle the downgrade manually. This guide covers every method available, from the simplest to the most complex.

Before You Begin - Safety First

Before attempting any rollback procedure, take these precautionary steps -

Put your store in maintenance mode - Go to Shop Parameters > General > Maintenance and enable it. This prevents customers from encountering errors while you work.
Create a database backup - Even though you are rolling back, the new module version may have made database changes. Back up your entire database before proceeding.
Document the current error - Note the exact error messages, which pages are affected, and when the problem started. This information helps if you need to contact the module developer.

Method 1 - Reinstall the Previous Version via Back Office

This is the simplest method and works when you still have access to the PrestaShop admin panel and have the previous version's ZIP file.

Step-by-Step Process

Navigate to Modules > Module Manager
Find the problematic module and click Uninstall (NOT "Delete" - uninstall preserves the module's data in the database)
Confirm the uninstallation
Click Upload a module at the top of the page
Upload the ZIP file of the previous working version
Install and configure the module

Where to Get the Previous Version

Your email - Most module sellers send download links with each purchase. Check your email for the original version.
Module marketplace account - On PrestaShop Addons and third-party marketplaces like mypresta.rocks, you can typically download previous versions from your order history.
Your backups - If you maintain regular backups (you should), you can extract the module folder from a backup archive.
Contact the developer - Module developers can usually provide older versions upon request.

Method 2 - FTP/SFTP File Replacement

When the admin panel is inaccessible (white screen, 500 error), you need to work directly with files via FTP or SFTP.

Step-by-Step Process

Connect to your server via FTP/SFTP using a client like FileZilla
Navigate to /modules/ in your PrestaShop installation directory
Find the module folder (e.g., /modules/mymodule/)
Rename the current folder to create a backup - e.g., rename mymodule to mymodule_broken
Upload the previous version's files into a new mymodule folder
Set correct file permissions - directories to 755, files to 644
Clear the PrestaShop cache by deleting the contents of /var/cache/prod/ and /var/cache/dev/

Important Considerations

When replacing files via FTP, you are only replacing the module's code, not its database entries. If the failed update included database schema changes (new tables, altered columns), the old code may not work with the new database structure. In that case, you will also need to restore the database (see Method 4).

Method 3 - Using the Command Line

If you have SSH access to your server, you can perform the rollback more efficiently from the command line.

# Connect to your server via SSH
ssh user@yourserver.com

# Navigate to PrestaShop root
cd /var/www/html/prestashop

# Backup the broken module
mv modules/mymodule modules/mymodule_broken_$(date +%Y%m%d)

# Extract the previous version
unzip /path/to/mymodule_v1.2.3.zip -d modules/

# Set correct permissions
find modules/mymodule -type d -exec chmod 755 {} \;
find modules/mymodule -type f -exec chmod 644 {} \;
chown -R www-data:www-data modules/mymodule

# Clear PrestaShop cache
rm -rf var/cache/prod/* var/cache/dev/*

Method 4 - Full Database Rollback

If the module update included database migrations that need to be reversed, you will need to restore a database backup from before the update.

When You Need a Database Rollback

The module created new database tables
The module altered existing table structures
The module inserted or modified configuration values
The old module code throws errors about missing or unexpected database columns

Step-by-Step Process

Identify which tables were affected - Check the module's install() and upgrade() methods in its main PHP file to see what database changes were made
Restore the relevant tables from your backup -

# Export only module-specific tables from your backup
mysql -u root -p prestashop < backup_before_update.sql

# Or restore specific tables
mysql -u root -p prestashop -e "DROP TABLE IF EXISTS ps_mymodule_data;"
mysql -u root -p prestashop < ps_mymodule_data_backup.sql

Warning - A full database restore will revert ALL changes made since the backup, including new orders, customer registrations, and product modifications. If possible, only restore the tables that the module specifically modified.

Method 5 - Manual Database Cleanup

If you do not have a pre-update database backup, you can manually undo the module's database changes. This requires understanding what the update changed.

Checking What Changed

Open the module's main PHP file and look for upgrade methods -

// Look for files like:
// modules/mymodule/upgrade/upgrade-2.0.0.php
// or methods in the main module file:
public function upgrade($version)
{
    if (version_compare($version, '2.0.0', '<')) {
        // Database changes made in 2.0.0
        Db::getInstance()->execute('ALTER TABLE `' . _DB_PREFIX_ . 'mymodule` 
            ADD COLUMN `new_field` VARCHAR(255)');
    }
}

To reverse these changes, you would run the inverse SQL -

ALTER TABLE ps_mymodule DROP COLUMN new_field;

Cleaning Module Configuration

Modules store configuration in the ps_configuration table. If the new version added broken configuration values, clean them up -

-- Find configuration values added by the module
SELECT * FROM ps_configuration WHERE name LIKE 'MYMODULE_%';

-- Delete problematic configuration entries if needed
DELETE FROM ps_configuration WHERE name = 'MYMODULE_NEW_BROKEN_SETTING';

After the Downgrade - Essential Cleanup

Clear All Caches

After any module downgrade, you must clear all caches to ensure PrestaShop loads the correct version -

Smarty cache - Delete contents of /var/cache/prod/ and /var/cache/dev/
OPcache - Restart PHP-FPM or Apache to clear the OPcache, or use opcache_reset()
CDN cache - If you use Cloudflare or another CDN, purge the cache
Browser cache - Test in an incognito/private window to rule out browser caching

Verify the Module Version

After downgrading, verify that PrestaShop recognizes the correct version -

Go to Modules > Module Manager
Find the module and check the displayed version number
Compare it with the version in the module's main PHP file ($this->version)

Test Thoroughly

Do not just check the homepage. Test -

The specific functionality the module provides
The checkout process from start to finish
The admin pages where the module adds content
Mobile and desktop views
Performance - does the store respond as quickly as before?

Preventing Future Update Problems

Always Back Up Before Updating

Create a complete backup (files and database) before every module update. This is the single most effective safety net.

Test Updates on a Staging Environment

Set up a staging copy of your store and test module updates there first. Only apply the update to production once you have verified it works correctly.

Read the Changelog

Before updating, read the module's changelog or release notes. Look for -

Breaking changes or compatibility requirements
Required PHP version changes
Database migration notes
Dependencies on other modules or services

Keep Previous Versions

Maintain an archive of all module ZIP files. Organize them by module name and version number so you can quickly find the previous version when needed.

Check Compatibility

Verify that the new module version is compatible with your PrestaShop version, PHP version, and other installed modules. Check the module developer's documentation for any known conflicts.

When to Contact the Module Developer

If none of the above methods resolve the issue, or if you are uncomfortable performing these steps yourself, contact the module developer. Provide them with -

Your PrestaShop version
Your PHP version
The previous module version and the version you updated to
Exact error messages (check the PrestaShop error log at /var/logs/)
A list of other modules installed on your store
Whether you made any customizations to the module

Most reputable module developers will help resolve update issues and may release a hotfix if the problem affects other customers as well.

For more details, read our guides: Module Conflicts: Why Two Good Modules Sometimes Break Each Other and Backup Your PrestaShop Store: Complete Data Protection Guide.

Read full answer

How to Test a PrestaShop Module on Staging Before Installing on Production

Installing an untested module on a live PrestaShop store is one of the most common causes of downtime, broken checkout flows, and lost revenue. A staging environment gives you a safe sandbox to validate every module before it touches your production store. This guide walks you through the complete process - from creating a staging copy of your store to performing thorough module testing and safely deploying to production.

Why You Need a Staging Environment

A staging environment is an exact copy of your live store that is not accessible to the public. It mirrors your production database, files, theme, configuration, and installed modules. Testing on staging lets you catch problems that would otherwise hit your customers.

Here is what can go wrong when you skip staging:

Module conflicts - The new module may conflict with an existing module, causing white screens, JavaScript errors, or broken functionality on specific pages.
Theme incompatibility - The module's templates may not render correctly with your theme, especially if you use a custom or heavily modified theme.
Performance degradation - Some modules add heavy database queries, additional CSS/JS files, or external API calls that slow down page load times.
Database corruption - Poorly written modules can modify core tables, add columns without proper migration handling, or create triggers that interfere with existing data.
Payment disruption - If a module breaks the checkout process or interferes with your payment gateway, you lose sales from the moment of installation until you discover and fix the issue.

Option 1 - Manual Staging Setup (Subdomain)

This is the most common approach and works with any hosting provider. You create a subdomain like staging.yourstore.com and copy your production files and database there.

Step 1 - Create the subdomain

In your hosting control panel (cPanel, Plesk, or DirectAdmin), create a new subdomain. Point it to a new directory, for example /home/youruser/staging.yourstore.com.

Step 2 - Copy production files

Connect to your server via SSH or FTP and copy all production files to the staging directory:

# Via SSH (fastest method)
cp -r /home/youruser/public_html/* /home/youruser/staging.yourstore.com/

# Or create a compressed archive first
cd /home/youruser/public_html
tar czf /tmp/prestashop-backup.tar.gz --exclude='var/cache' --exclude='var/logs' .
cd /home/youruser/staging.yourstore.com
tar xzf /tmp/prestashop-backup.tar.gz

Step 3 - Export and import the database

Create a new database for staging, then copy the production data:

# Export production database
mysqldump -u dbuser -p production_db > /tmp/production_dump.sql

# Create staging database
mysql -u root -p -e "CREATE DATABASE staging_db;"
mysql -u root -p -e "GRANT ALL ON staging_db.* TO 'dbuser'@'localhost';"

# Import into staging
mysql -u dbuser -p staging_db < /tmp/production_dump.sql

Step 4 - Update PrestaShop configuration

Edit the configuration files to point to the staging database and domain:

# Edit app/config/parameters.php (PrestaShop 1.7+/8.x)
# Change these values:
'database_name' => 'staging_db',

# Update the shop URL in the database
mysql -u dbuser -p staging_db -e "
  UPDATE ps_shop_url 
  SET domain = 'staging.yourstore.com', 
      domain_ssl = 'staging.yourstore.com' 
  WHERE id_shop_url = 1;"

# Update configuration values
mysql -u dbuser -p staging_db -e "
  UPDATE ps_configuration 
  SET value = 'staging.yourstore.com' 
  WHERE name IN ('PS_SHOP_DOMAIN', 'PS_SHOP_DOMAIN_SSL');"

Step 5 - Clear caches

rm -rf var/cache/prod/* var/cache/dev/*
rm -rf var/cache/smarty/compile/* var/cache/smarty/cache/*

Step 6 - Restrict access

Prevent search engines and unauthorized users from accessing your staging site. Add to .htaccess at the root of your staging directory:

# Password protect staging
AuthType Basic
AuthName "Staging Access"
AuthUserFile /home/youruser/.htpasswd
Require valid-user

# Block search engines
Header set X-Robots-Tag "noindex, nofollow"

Create the password file:

htpasswd -c /home/youruser/.htpasswd staginguser

Option 2 - Docker-Based Staging (Recommended for Developers)

Docker provides the most reliable staging environment because you can exactly match your production PHP version, MySQL version, and server configuration.

Basic Docker Compose setup

# docker-compose.yml
version: '3.8'
services:
  prestashop:
    image: prestashop/prestashop:8.1
    ports:
      - "8080:80"
    volumes:
      - ./html:/var/www/html
    environment:
      - DB_SERVER=db
      - DB_NAME=prestashop
      - DB_USER=prestashop
      - DB_PASSWD=your_password
    depends_on:
      - db
      
  db:
    image: mysql:8.0
    environment:
      - MYSQL_ROOT_PASSWORD=root_password
      - MYSQL_DATABASE=prestashop
      - MYSQL_USER=prestashop
      - MYSQL_PASSWORD=your_password
    volumes:
      - db_data:/var/lib/mysql
      
volumes:
  db_data:

Import production data into Docker

# Copy production files to ./html directory
rsync -avz --exclude='var/cache' production:/var/www/html/ ./html/

# Import database dump
docker exec -i your-db-container mysql -u root -proot_password prestashop < production_dump.sql

# Update URLs for local access
docker exec your-db-container mysql -u root -proot_password -e "
  USE prestashop;
  UPDATE ps_shop_url SET domain='localhost:8080', domain_ssl='localhost:8080';
  UPDATE ps_configuration SET value='localhost:8080' WHERE name IN ('PS_SHOP_DOMAIN','PS_SHOP_DOMAIN_SSL');
  UPDATE ps_configuration SET value='0' WHERE name='PS_SSL_ENABLED';"

Option 3 - Local Staging with XAMPP/MAMP

For quick module tests, you can run PrestaShop locally on your development machine. This is the fastest option for a single developer but does not replicate your production server configuration exactly.

Install XAMPP (Windows/Linux) or MAMP (macOS)
Set PHP version to match your production server
Copy your PrestaShop files to the web root (htdocs/ for XAMPP)
Create a local database and import your production dump
Update parameters.php with local database credentials
Update shop URLs to localhost/yourstore
Clear all caches

Testing Checklist for New Modules

Once your staging environment is ready, follow this systematic testing process for every new module.

Phase 1 - Pre-Installation Checks

Read the module documentation - Understand what the module does, which hooks it uses, and what its requirements are (PHP version, PrestaShop version, required PHP extensions).
Check file contents - Before installing, unzip the module and review the code. Look for suspicious patterns like eval(), base64_decode(), or external URL calls to unknown domains.
Create a database backup - Even on staging, take a backup before installing. This lets you quickly restore if the module makes irreversible database changes.

# Quick staging database backup
mysqldump -u dbuser -p staging_db > /tmp/staging_before_module.sql

Phase 2 - Installation Testing

Install the module via the Back Office (Modules > Module Manager > Upload a module). Do NOT install via FTP and then clicking "Install" - the upload method provides better error reporting.
Check for installation errors - After installation, check:
- The module appears in the installed modules list
- No error messages in the success notification
- The PHP error log has no new entries: tail -f /var/log/php-errors.log

Verify database changes - Compare database tables before and after installation:

# List tables created by the module
mysql -u dbuser -p staging_db -e "SHOW TABLES LIKE '%modulename%';"

Phase 3 - Functional Testing

Test every aspect of the module's functionality:

Configuration page - Can you access and save all settings without errors?
Front office display - Does the module render correctly on all relevant pages (home, category, product, cart, checkout)?
Mobile responsiveness - Test on mobile viewports. Many modules look fine on desktop but break on phones.
Multi-language support - If your store uses multiple languages, verify that the module's content displays correctly in each language.
Multi-shop compatibility - If you use PrestaShop's multistore feature, test the module's behavior across different shops.

Phase 4 - Conflict Testing

This is the most critical phase. Test for conflicts with your existing setup:

Check the browser console - Open Developer Tools (F12) and look for JavaScript errors on every page where the module is active.
Test the checkout flow - Add a product to cart, proceed through every checkout step, and complete a test order. This is the most sensitive area.
Test payment processing - If the module has any interaction with the checkout or order process, place test orders with each payment method you offer.
Check existing module functionality - Verify that your critical modules (SEO, analytics, shipping, payment) still work correctly.

Phase 5 - Performance Testing

Measure the module's impact on page load times:

# Before installing the module, measure baseline
curl -o /dev/null -s -w "Time: %{time_total}s\n" https://staging.yourstore.com/
curl -o /dev/null -s -w "Time: %{time_total}s\n" https://staging.yourstore.com/en/2-category.html
curl -o /dev/null -s -w "Time: %{time_total}s\n" https://staging.yourstore.com/en/product-1.html

# After installing, measure again and compare
curl -o /dev/null -s -w "Time: %{time_total}s\n" https://staging.yourstore.com/
curl -o /dev/null -s -w "Time: %{time_total}s\n" https://staging.yourstore.com/en/2-category.html
curl -o /dev/null -s -w "Time: %{time_total}s\n" https://staging.yourstore.com/en/product-1.html

A well-written module should add less than 100ms to page load times. If you see an increase of 500ms or more, investigate the module's database queries and asset loading.

You can also use browser DevTools Network tab to check how many additional CSS/JS files the module loads and whether they are properly minified.

Phase 6 - Uninstallation Testing

Test that the module can be cleanly removed:

Uninstall the module from the Back Office
Verify that all module-specific database tables are removed (or at least that data is preserved if you might reinstall)
Check that no orphaned hooks, CSS files, or JavaScript files remain
Verify that the store's front office returns to its pre-module state

Moving a Tested Module to Production

After successful staging tests, follow this deployment process:

Step 1 - Schedule the deployment

Choose a low-traffic period. Check your Google Analytics to identify when your store has the fewest visitors - typically early morning or late evening.

Step 2 - Create a production backup

# Full database backup
mysqldump -u dbuser -p production_db > /tmp/production_backup_$(date +%Y%m%d_%H%M%S).sql

# File backup (optional but recommended for major modules)
tar czf /tmp/files_backup_$(date +%Y%m%d_%H%M%S).tar.gz /home/youruser/public_html/modules/

Step 3 - Install on production

Upload the exact same module ZIP file you tested on staging. Do not download a new version or use a different file - use the exact file that passed your tests.

Step 4 - Apply the same configuration

Configure the module with the exact same settings you used on staging. Take screenshots of your staging configuration before you start so you can replicate them precisely.

Step 5 - Verify in production

Run through an abbreviated version of your testing checklist:

Front office pages load correctly
No JavaScript errors in the browser console
Checkout process completes successfully
Module configuration page is accessible

Step 6 - Monitor for 24-48 hours

After deployment, actively monitor:

PHP error logs for new errors
Google Analytics for unusual traffic patterns or bounce rate spikes
Order conversion rate compared to the previous period
Customer support requests about new issues

Keeping Staging in Sync with Production

Your staging environment is only useful if it accurately reflects your production store. Refresh your staging database regularly - at minimum before testing each new module.

# Automated staging refresh (run as cron or manually)
#!/bin/bash
# Export production database
mysqldump -u dbuser -p production_db > /tmp/prod_dump.sql

# Import to staging
mysql -u dbuser -p staging_db < /tmp/prod_dump.sql

# Fix staging URLs
mysql -u dbuser -p staging_db -e "
  UPDATE ps_shop_url SET domain='staging.yourstore.com', domain_ssl='staging.yourstore.com';
  UPDATE ps_configuration SET value='staging.yourstore.com' WHERE name IN ('PS_SHOP_DOMAIN','PS_SHOP_DOMAIN_SSL');"

# Sync files (exclude cache and logs)
rsync -avz --exclude='var/cache' --exclude='var/logs' \
  /home/youruser/public_html/ /home/youruser/staging.yourstore.com/

# Clear staging cache
rm -rf /home/youruser/staging.yourstore.com/var/cache/prod/*
rm -rf /home/youruser/staging.yourstore.com/var/cache/smarty/compile/*

echo "Staging refreshed at $(date)"

Common Staging Pitfalls to Avoid

Forgetting to update URLs - If you copy the database but forget to update ps_shop_url and the PS_SHOP_DOMAIN configuration values, your staging site will redirect to production.
Payment gateways in live mode - Always switch payment gateways to sandbox/test mode on staging. You do not want staging test orders to process real payments.
Email notifications going to customers - Disable email sending on staging or redirect all emails to a test address. Otherwise, your customers will receive duplicate order confirmations and other confusing emails from the staging environment.
Search engine indexing - Always block staging from search engines with robots.txt, meta noindex tags, and ideally HTTP authentication.
Cron jobs running on staging - Disable any cron jobs that were copied from production, especially those that send emails, process payments, or sync with external services.

Quick Reference - Module Testing Commands

# Check PHP error log for issues after module install
tail -100 /var/log/php-errors.log

# Check PrestaShop's own logs
ls -la var/logs/
tail -100 var/logs/*.log

# Find what database tables a module created
mysql -u dbuser -p staging_db -e "SHOW TABLES;" | grep modulename

# Check hooks registered by a module
mysql -u dbuser -p staging_db -e "
  SELECT h.name, hm.position 
  FROM ps_hook_module hm 
  JOIN ps_hook h ON h.id_hook = hm.id_hook 
  JOIN ps_module m ON m.id_module = hm.id_module 
  WHERE m.name = 'modulename'
  ORDER BY h.name;"

# Check module configuration values
mysql -u dbuser -p staging_db -e "
  SELECT name, value FROM ps_configuration 
  WHERE name LIKE 'MODULENAME%';"

For more details, read our guides: Module Conflicts: Why Two Good Modules Sometimes Break Each Other and Backup Your PrestaShop Store: Complete Data Protection Guide.

Read full answer

Cookie	Provider	Purpose	Duration
PrestaShop-*	PrestaShop	Session management and cart functionality	Session
PHPSESSID	PHP	PHP session identifier	Session
mprcr_consent	MPR Cookies Revolution	Stores cookie consent preferences	365 day(s)
mprcr_version	MPR Cookies Revolution	Tracks consent configuration version	365 day(s)

Cookie	Provider	Purpose	Duration
TawkConnectionTime	Tawk.to	Tracks chat session connection time	Session
__tawkuuid	Tawk.to	Identifies returning chat visitors across sessions	6 month(s)

Cookie	Provider	Purpose	Duration
_ga	Google Analytics	Distinguishes unique users by assigning a randomly generated number	2 year(s)
_ga_*	Google Analytics	Used to persist session state across page requests	2 year(s)
_gid	Google Analytics	Distinguishes unique users for 24 hours	24 hour(s)

Installation & Setup

Understanding Linux File Permissions

Correct Permissions for PrestaShop Directories and Files

Setting Correct Ownership with chown

Shared Hosting vs VPS vs Dedicated Server

Shared Hosting

VPS (Virtual Private Server)

Dedicated Server

PHP Execution Models: suPHP vs mod_php vs PHP-FPM

mod_php (Apache module)

suPHP

PHP-FPM (FastCGI Process Manager)

Why 777 Permissions Are Dangerous

Docker Considerations for PrestaShop

Troubleshooting Common Permission Errors

"Failed to open stream: Permission denied"

"Unable to write to cache directory"

"Cannot upload image" or "Cannot install module"

"index.php is not writable" during updates

White page after changing permissions

Permissions reset after FTP upload

Security Best Practices Beyond Permissions

When Module Updates Go Wrong

Before You Begin - Safety First

Method 1 - Reinstall the Previous Version via Back Office

Step-by-Step Process

Where to Get the Previous Version

Method 2 - FTP/SFTP File Replacement

Step-by-Step Process

Important Considerations

Method 3 - Using the Command Line

Method 4 - Full Database Rollback

When You Need a Database Rollback

Step-by-Step Process

Method 5 - Manual Database Cleanup

Checking What Changed

Cleaning Module Configuration

After the Downgrade - Essential Cleanup

Clear All Caches

Verify the Module Version

Test Thoroughly

Preventing Future Update Problems

Always Back Up Before Updating

Test Updates on a Staging Environment

Read the Changelog

Keep Previous Versions

Check Compatibility

When to Contact the Module Developer

How to Test a PrestaShop Module on Staging Before Installing on Production

Why You Need a Staging Environment

Option 1 - Manual Staging Setup (Subdomain)

Step 1 - Create the subdomain

Step 2 - Copy production files

Step 3 - Export and import the database

Step 4 - Update PrestaShop configuration

Step 5 - Clear caches

Step 6 - Restrict access

Option 2 - Docker-Based Staging (Recommended for Developers)

Basic Docker Compose setup

Import production data into Docker

Option 3 - Local Staging with XAMPP/MAMP

Testing Checklist for New Modules

Phase 1 - Pre-Installation Checks

Phase 2 - Installation Testing

Phase 3 - Functional Testing

Phase 4 - Conflict Testing

Phase 5 - Performance Testing

Phase 6 - Uninstallation Testing

Moving a Tested Module to Production

Step 1 - Schedule the deployment

Step 2 - Create a production backup

Step 3 - Install on production

Step 4 - Apply the same configuration

Step 5 - Verify in production

Step 6 - Monitor for 24-48 hours

Keeping Staging in Sync with Production

Common Staging Pitfalls to Avoid

Quick Reference - Module Testing Commands

Other categories

Still have questions?