PrestaShop Local Development: XAMPP, Docker & Linux

Why we never edit PrestaShop files on a live server

Every developer on our team has, at some point in their career, "quickly fixed" something on a live shop and taken the checkout down with it. We watch clients do the same thing every month. A local environment is the one piece of infrastructure that stops you from being the person who broke production at 11 PM on a Friday.

We've shipped 140+ modules out of this workflow since 2014, and the rule we hold ourselves to is simple: nothing reaches a client's shop that hasn't already passed through a local install of the exact PrestaShop version they run. Here's how we set it up, what we'd actually recommend, and where we've seen people get burned.

Safety. Try a theme change, a module swap, or a PHP version bump without putting orders at risk.
Speed. Save the file, refresh the browser. No SFTP, no cPanel file manager, no "let me clear the cache through the panel."
Offline. We've debugged on trains and during hotel WiFi outages. Local installs don't care.
Multi-version testing. We currently run PS 1.6, 1.7, 8.x and 9.x side-by-side. A module either works across all the versions a client might be on, or it isn't ready.
Real debugging tools. Xdebug step-through, full error reporting, slow query logs. Shared hosting won't give you any of this.

If you're editing PHP directly on the live server, you will eventually take the shop down. We've cleaned up enough of these incidents to be blunt about it: thirty minutes setting up locally is cheaper than one emergency rollback.

Windows vs Linux vs macOS — straight answer

We develop on Linux. Our whole stack is Docker on TrueNAS, and that's not going to change. But plenty of merchants we work with are on Windows, and we won't pretend XAMPP doesn't get the job done for what they need.

Windows

XAMPP and WAMP get you running quickly. For a shop owner who wants to preview a theme change or test a module install, it's fine. The friction shows up the moment you try to ship code from Windows to a Linux server, which is what every PrestaShop host on earth runs:

Case sensitivity. MyModule.php and mymodule.php are the same file on Windows and two different files on Linux. We've watched this break modules at deployment more times than we can count — works perfectly locally, 500 errors the second it hits the server.
File permissions. PrestaShop expects Unix-style 755/644. XAMPP doesn't really enforce permissions, so bugs that surface on Linux (writable directory not writable, cache files owned wrong) are invisible locally.
Line endings. CRLF in PHP files or shell scripts will give you "headers already sent" and broken cron jobs. Configure your editor to use LF.
Defender overhead. Windows Defender scans every PHP file PrestaShop loads. On a back office page that touches 800 files, you'll feel it.

Linux

Same filesystem, same permissions, same PHP build as your server. Docker runs natively without a VM in the way, so file I/O is real and container startup is instant.

No virtualization overhead.
PHP, MySQL, Apache, Nginx, Composer, Node, Git, VS Code — all free, all packaged.
If it works locally, it usually works in production. If it breaks in production, you can almost always reproduce it locally.

macOS

Unix underneath, so permissions and paths behave. Docker runs in a small VM, which means mounted-volume I/O is slower than Linux — noticeable on PrestaShop installs that load hundreds of files per request. Homebrew handles the rest cleanly: brew install php@8.2 mysql composer.

What we'd actually pick

If PrestaShop is your job, run Linux. We use Arch with KDE Plasma on developer machines, Debian on our server. If you don't want to switch operating systems, XAMPP on Windows is honest enough for store-owner testing — just remember it's a preview, not a faithful copy of your production server.

The best dev environment is the one you actually use every day. A messy XAMPP install you reach for daily beats a perfect Linux setup that's still in your Documents folder waiting to be configured.

Option 1: XAMPP (Windows, macOS, Linux)

XAMPP bundles Apache, MariaDB, PHP, and phpMyAdmin into one installer. It's the quickest way to get PrestaShop running on a desktop machine, and for clients who only need to preview things, this is what we tell them to use.

Installation

1. Grab it from apachefriends.org. Match the PHP version to your PrestaShop: 7.2-7.4 for PS 1.7, 8.0-8.2 for PS 8.x, 8.1-8.3 for PS 9.x.

2. Install it (Windows defaults to C:\xampp, macOS to /Applications/XAMPP). Start Apache and MySQL from the control panel.

3. Open http://localhost/phpmyadmin, create a database called prestashop with the utf8mb4_general_ci collation.

4. Download PrestaShop from GitHub releases and extract to C:\xampp\htdocs\prestashop\.

5. Visit http://localhost/prestashop, walk through the installer (host: localhost, user: root, password: empty), and delete the install/ directory afterwards.

The php.ini changes you'll need

Open php.ini from the XAMPP control panel (Apache > Config). The defaults won't get you through a PrestaShop install:

memory_limit = 512M              ; default 128M is not enough
max_execution_time = 300         ; default 30s too short for imports
upload_max_filesize = 64M        ; default 2M too small for module ZIPs
post_max_size = 64M
max_input_vars = 20000           ; default 1000 — critical for PS admin forms

Uncomment intl, gd, zip, curl, and mbstring by removing the leading ;. Restart Apache. Skipping any of these is the most common reason a fresh XAMPP install refuses to run PrestaShop — intl in particular catches almost everyone.

Where XAMPP bites you

Port 80 is taken. Skype, IIS, or Windows itself grabbed it. Change Listen 80 to Listen 8080 in httpd.conf and use http://localhost:8080.

Settings won't save, combinations vanish. The famous max_input_vars issue. Default is 1000; PS admin forms can post 5000+ vars on a product with many combinations. Set 20000 in php.ini.

White page. Always check C:\xampp\apache\logs\error.log first. It's almost always a missing PHP extension or memory exhausted.

Option 2: WAMP (Windows Only)

The one thing WAMP does better than XAMPP is server-wide PHP version switching from the tray icon. Useful if you're poking at one PS version this week and another the next.

Setup

1. Download the 64-bit installer from wampserver.aviatechno.net. Install the Visual C++ Redistributables it asks for or it won't start.

2. Install to C:\wamp64. Tray icon goes green when Apache and MySQL are both up.

3. Add extra PHP versions from the WAMP addons page; they slot into the version switcher automatically.

Virtual hosts

WAMP includes a virtual host manager (tray icon > Your VirtualHosts > VirtualHost Management). Point ps17.local and ps8.local at different directories — WAMP handles the hosts file and Apache config for you.

WAMP switches PHP server-wide, not per virtual host. You can't run PHP 7.4 for one shop and PHP 8.2 for another at the same time. The moment you need that, you need Docker.

Option 3: MAMP (macOS)

The Mac equivalent of XAMPP. Free version: one document root, Apache, PHP, MySQL. MAMP Pro at $59 unlocks multiple hosts, SSL, per-host PHP versions, and Nginx.

Install from mamp.info, drop PrestaShop in /Applications/MAMP/htdocs/prestashop/, open http://localhost:8888/prestashop. If Docker volume mounts feel painfully slow on your Mac (a common complaint), reach for Homebrew instead — native PHP and MySQL with no VM in between.

Option 4: Native Linux setup

Install Apache, PHP, and MySQL straight onto the OS. Most control, fastest, closest to whatever your hosting provider runs.

Ubuntu / Debian

sudo apt update
sudo apt install apache2
sudo apt install php8.2 php8.2-fpm php8.2-mysql php8.2-gd php8.2-intl \\
  php8.2-curl php8.2-zip php8.2-xml php8.2-mbstring php8.2-bcmath
sudo apt install mysql-server
curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer

Arch Linux: sudo pacman -S apache php php-fpm php-gd php-intl php-sodium mariadb composer, then initialise MariaDB and bring services up with systemctl.

Apache virtual host

Create /etc/apache2/sites-available/ps8.local.conf with a VirtualHost pointing ServerName ps8.local at your PrestaShop directory. Set AllowOverride All, hand PHP off to FPM. Enable with sudo a2ensite ps8.local.conf && sudo a2enmod rewrite proxy_fcgi && sudo systemctl reload apache2. Add 127.0.0.1 ps8.local to /etc/hosts.

File permissions

Own everything as www-data, directories 755, files 644, and the writable dirs (var/, cache/, img/, upload/, config/) at 775. We've debugged white pages on Linux a hundred times and the answer was permissions in 90 of them. Check the Apache error log for "Permission denied" before anything else.

Option 5: Docker — what we actually use

Each PrestaShop version gets its own container with its own PHP and MySQL. Nothing conflicts, nothing leaks between shops. We run our entire 25-container fleet this way. There's a full Docker guide covering multi-version setups, but the starting point is this:

A working docker-compose.yml

services:
  prestashop:
    image: prestashop/prestashop:8.2
    ports: ["8085:80"]
    environment:
      DB_SERVER: db
      DB_USER: prestashop
      DB_PASSWD: prestashop
      DB_NAME: prestashop
      PS_DOMAIN: localhost:8085
      ADMIN_MAIL: admin@yourshop.com
      ADMIN_PASSWD: your_secure_password
    volumes: [ps-files:/var/www/html]
    depends_on: [db]
  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: root_pass
      MYSQL_DATABASE: prestashop
      MYSQL_USER: prestashop
      MYSQL_PASSWORD: prestashop
    volumes: [db-data:/var/lib/mysql]
volumes:
  ps-files:
  db-data:

Bring it up with docker compose up -d, open http://localhost:8085.

We run more than 25 PrestaShop containers on one TrueNAS host (PS 1.6 through 9.1) for module testing. Trying to manage that with anything other than Docker would be a full-time job. Even at two or three versions, Docker pays for itself the first time you would otherwise have hit a PHP version conflict.

Configuration that applies to every method

The PHP extensions PrestaShop won't run without

intl — currency, locale, date formatting. The single most commonly missing one.
gd — image processing, thumbnails, watermarks.
curl — payment gateways, webservice API, anything outbound.
mbstring — UTF-8 string handling. Without it, multibyte text breaks silently.
zip — module installs read ZIPs through this.
xml — import/export and the webservice.
pdo_mysql — database connectivity.
opcache — technically optional, but on a real shop the difference is measurable in seconds per request.

Check with php -m | grep intl, or drop a temporary phpinfo() file and delete it as soon as you're done.

Friendly URLs

Apache: sudo a2enmod rewrite, set AllowOverride All in your vhost. Nginx: try_files $uri $uri/ /index.php?$args;. Then turn the toggle on in Shop Parameters > Traffic & SEO.

Email testing with Mailpit

Capture every outgoing email locally instead of accidentally mailing a customer from your dev box:

docker run -d --name mailpit -p 8025:8025 -p 1025:1025 axllent/mailpit

In PrestaShop SMTP settings: server localhost, port 1025, no encryption, no auth. Read captured mail at http://localhost:8025.

IDE setup

VS Code (free): PHP Intelephense and PHP Debug extensions. Xdebug on port 9003 with pathMappings from the container path to your workspace. PHPStorm (paid): built-in PHP support, Xdebug, database tools and Docker integration. We use both — PHPStorm pays for itself if PHP is what you do for a living.

Importing a live shop locally

Testing against a fresh PrestaShop install only catches the easy bugs. Real bugs live in the theme overrides, the 80 installed modules, and the 12,000-product catalogue. Pull it down and reproduce locally.

Database export and import

# Export from production (via SSH — phpMyAdmin times out on large DBs)
mysqldump -u db_user -p database_name > prestashop_backup.sql

# Create local database
mysql -u root -p -e "CREATE DATABASE prestashop_local CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;"

# Import
mysql -u root -p prestashop_local < prestashop_backup.sql

Copy files and rewrite the URLs

Pull the directories that actually matter — img/, modules/, themes/, config/, override/, upload/: rsync -avz user@server:/path/to/prestashop/ /local/prestashop/

-- Change domain to local
UPDATE ps_shop_url SET domain = 'localhost:8080', domain_ssl = 'localhost:8080' WHERE id_shop_url = 1;

-- Disable SSL
UPDATE ps_configuration SET value = '0' WHERE name = 'PS_SSL_ENABLED';
UPDATE ps_configuration SET value = '0' WHERE name = 'PS_SSL_ENABLED_EVERYWHERE';

Edit app/config/parameters.php (PS 1.7/8.x) or config/settings.inc.php (PS 1.6) with the local DB credentials, then wipe the cache: rm -rf var/cache/*.

Once you've imported, create a brand-new admin account for local use and don't sign in with production credentials. We've seen people forget which tab is which and edit a category description on the live shop. New local account, new password — easy to keep separate.

The problems we see clients hit most often

White screen after install

Always read the log first. The answer is almost always one line in there:

# Apache: tail -50 /var/log/apache2/error.log
# XAMPP: C:\\xampp\\apache\\logs\\error.log
# PrestaShop: tail -50 var/logs/dev.log

Missing extension: Call to undefined function in the log tells you which one. Memory: Allowed memory size exhausted — push memory_limit up. Wrong PHP: PS 8.x on PHP 7.4 throws type errors; php -v doesn't lie.

Admin panel 404s on every URL except the dashboard

mod_rewrite isn't on, or .htaccess isn't being read. sudo a2enmod rewrite, AllowOverride All in the vhost. For XAMPP, change AllowOverride None to AllowOverride All in httpd.conf.

Painfully slow on Windows

Antivirus: add your XAMPP and PrestaShop directories to Windows Defender exclusions. The difference is dramatic. Docker on WSL2: keep PrestaShop files inside WSL2's own filesystem at /home/you/prestashop/, never on /mnt/c/.... Mounted Windows volumes through WSL2 are slow enough to make PrestaShop unusable.

Images not loading

No GD: install php-gd. Permissions: chown -R www-data:www-data img/. Imported shop: regenerate thumbnails from Design > Image Settings — without this, the front office references files that never got created locally.

Module installation fails

"Cannot upload": bump upload_max_filesize and post_max_size to 64M. "Cannot unzip": install php-zip. "Permission denied": chmod 775 modules/. "Class not found": stale class index — delete var/cache/*/class_index.php and reload.

Database connection refused

MySQL isn't running — sudo systemctl status mysql. "Access denied" means credentials in your config don't match what MySQL has on file.

Workflow habits worth picking up

Turn dev mode on. In config/defines.inc.php: define('_PS_MODE_DEV_', true);. You get stack traces and SQL details instead of blank pages. Never leave this on a production shop — it leaks paths and queries.

Turn caching off locally. Back Office > Advanced Parameters > Performance — Smarty cache "No", CCC off. Cached templates and assets will hide changes you just made and waste an hour of your life.

Git, even for one module. git init in the module directory, commit on every working state. git diff tells you what changed, git checkout -- file.php undoes the experiment that didn't work. We commit dozens of times a day across our module fleet.

Quick reference: which PHP for which PrestaShop

PS 1.6.1.x: PHP 5.6-7.1, MySQL 5.0-5.7
PS 1.7.0-1.7.6: PHP 7.1-7.3, MySQL 5.5-5.7
PS 1.7.7-1.7.8: PHP 7.2-7.4, MySQL 5.6-8.0
PS 8.0-8.1: PHP 8.0-8.1, MySQL 5.7-8.0
PS 8.2: PHP 8.1-8.2, MySQL 5.7-8.0 / MariaDB 10.x
PS 9.x: PHP 8.1-8.3, MySQL 8.0 / MariaDB 10.11+

Cross-check the official system requirements for the exact patch release you're on — minor versions tighten the supported PHP range surprisingly often.

PrestaShop Local Development: XAMPP, WAMP, Docker & Linux Setup