A comprehensive analysis of the architectural shift from the custom MVC legacy of 1.6 to the Symfony-powered modern core of version 9. Understand exactly why your code breaks between versions.
The version history of PrestaShop is defined by one major event: The introduction of Symfony. While PrestaShop 1.6 ran on a custom, proprietary framework (often called "Legacy"), version 1.7 began a slow migration to Symfony. This decision effectively tied PrestaShop's lifecycle to Symfony's lifecycle, and by extension, to PHP's strict roadmap.
As PHP evolved from the loose standards of 5.x to the strict typing of 8.x, PrestaShop had to rewrite its core to comply. Below is the technical breakdown of every major version.
PrestaShop's journey mirrors the history of PHP itself. As PHP deprecated dangerous features like register_globals and mysql_connect, PrestaShop had to reinvent its core multiple times.
Below is the complete technical history, starting from the early days of 2010 to the future of 2026.
Version 1.0 was a student project (originally named phpOpenStore) that evolved into PrestaShop. It is virtually unrecognizable today.
PrestaShop 1.0 was born in the "Wild West" of PHP. It often relied on register_globals being enabled, meaning URL parameters automatically became PHP variables (e.g., ?admin=1 creates $admin = 1). This is the single biggest security hole in PHP history.
// URL: shop.php?logged_in=1
if ($logged_in) {
// Access granted because variable was auto-created!
showAdminPanel();
}// Variables must be fetched explicitly $logged_in = $_GET['logged_in']; // register_globals was removed in PHP 5.4
PrestaShop started as a graduation project by five students from the Epitech IT school in Paris. They translated it into two languages (French and English) and released it for free. Within 3 months, it had been translated into 13 languages by the community, proving the massive demand for an alternative to osCommerce.
Released in 2008, version 1.1 was the release that separated logic from design, allowing for the first custom "Themes".
This version explicitly required magic_quotes_gpc to be ON in some configurations (or simulated it). Modern PHP (5.4+) removed this "security feature" because it was actually a security flaw.
In early 1.1 builds, installing a module was often a manual FTP process involving editing PHP files. The "One-Click Install" for modules we take for granted today didn't exist in its modern form.
Released in 2008/2009, version 1.2 was the first to truly stabilize the Module system (Hooks), allowing developers to insert content without hacking core files.
While marketed for PHP 5, the codebase was heavily influenced by PHP 4 coding styles (no visibility keywords like public/private). Modern PHP 7+ parsers reject the constructors used in this era.
class Product {
// Method with same name as class
// Deprecated in PHP 7, removed in PHP 8
function Product() {
$this->id = ...
}
} class Product {
// Standard constructor
public function __construct() {
$this->id = ...
}
}PrestaShop 1.2 introduced the ability to sell "Virtual Products" (MP3s, PDFs). Before this version, PrestaShop was strictly for physical shipping only. This opened the door for software vendors to use the platform.
PrestaShop 1.3 was built in an era when the web was "loose". It heavily relied on PHP settings that are now considered critical security vulnerabilities.
PHP 5.4 removed magic_quotes_gpc and register_globals. PrestaShop 1.3 expected these to be handled by the server. Without them, user input isn't automatically escaped, leading to SQL injection risks, and variables aren't automatically defined in the global scope.
This version used Smarty 2. The template syntax was much more limited compared to the Smarty 3 engine introduced later. You couldn't even use simple math in templates like {$price + 10} without writing a custom PHP modifier.
Version 1.4 was the first to introduce a true Controller architecture and the famous /override/ system, allowing developers to extend core classes without editing original files.
This version used the mysql_ extension (removed in PHP 7) and regular expression functions starting with eregi (removed in PHP 5.3+).
// Removed in PHP 7.0
mysql_connect($host, $user, $pass);
eregi("[a-z]", $string);// PDO or MySQLi
$pdo = new PDO(...);
preg_match("/[a-z]/i", $string);PrestaShop 1.4 was the version that introduced the legendary /override/ folder. Before this, developers had to "hack" core files directly to change functionality, meaning every shop update would delete their custom work. The Override system was celebrated as a revolution in 2011, though ironically, modern standards (PrestaShop 9) are now trying to kill it off in favor of Decorators.
PrestaShop 1.5 introduced the "Multistore" feature, changing the database schema significantly. However, its core database driver (DbMySQL.php) still relied on the old mysql_ functions by default, making it crash instantly on PHP 7.0.
PrestaShop 1.5 introduced "Advanced Stock Management" (ASM). It was so buggy and complex that most developers advised disabling it. It was eventually completely removed in version 1.7 because it was deemed unfixable.
PrestaShop 1.6 is architecturally incompatible with modern PHP. While many shop owners cling to it, running it on PHP 7.2 or higher requires modifying core files, which breaks the upgrade path.
In PHP 7.2, object became a reserved type keyword. PrestaShop 1.6 defined a core class simply named Object (the parent of ObjectModel). This causes a fatal syntax error immediately upon booting the kernel.
/**
* Fatal Error in PHP 7.2+
* 'Object' is a reserved word
*/
class Object
{
public $id;
// ...
}/**
* Renamed to avoid collision
* 'Object' class was removed entirely
*/
class ObjectModelCore
{
public $id;
// ...
}PrestaShop 1.6 used the Rijndael class for cookie encryption, which relied on the mcrypt PHP extension. PHP 7.1 deprecated mcrypt, and PHP 7.2 removed it entirely.
mcrypt_encrypt not found.PrestaShop 1.6 was revolutionary because it was one of the first major e-commerce platforms to ship with Bootstrap 3 as the default theme engine. Before 1.6, mobile shops were often separate "m.dot" subdomains. Version 1.6 killed the mobile subdomain and standardized "Responsive Design" for European e-commerce.
PrestaShop 1.7 had a very long lifecycle. Early versions (1.7.0) supported PHP 5.4, while late versions (1.7.8) require PHP 7.1+. This makes "1.7 compatibility" a vague term.
Many modules written for PS 1.6 and early 1.7 used curly braces $array{0} to access array or string offsets. PHP 7.4 deprecated this, and PHP 8.0 removed it. This is the #1 reason 1.7 stores crash on PHP 8.
$string = "abcdef";
// This syntax is removed in PHP 8
$char = $string{0};
// Fatal Error in PHP 8+$string = "abcdef"; // Square brackets are required $char = $string[0]; // Works in all versions
PrestaShop 1.7 relied on older libraries (like Smarty 3.1 old versions) that used create_function(). This function was a security nightmare and was removed in PHP 8.0. If you try to run PS 1.7.6 on PHP 8, Smarty will crash the site immediately.
Because 1.7 was part Symfony (new) and part Legacy (old), developers jokingly called it "The Frankenstein." In early versions, clicking "Modules" (Symfony page) would sometimes log you out because the Symfony session and the Legacy cookie weren't syncing. It was essentially two different applications trying to share one browser window.
PrestaShop 8 stripped away the "1.7" prefix to signify a clean break. It removed huge chunks of legacy code. However, the move to PHP 8.0/8.1 introduced Strict Typing issues that plague careless module developers.
This is the most common error when upgrading to PS 8. PHP 8.0 no longer allows optional parameters to be defined before required parameters.
// $title is optional, $content is required.
// PHP 8 throws: "Deprecated: Required parameter
// $content follows optional parameter $title"
public function installModule($title = null, $content) {
// ...
}// 1. Move required params to the left
public function installModule($content, $title = null) {
// ...
}
// 2. Or give everything a default
public function installModule($title = null, $content = '') {
}In PHP 7, strlen(null) returned 0. In PHP 8.1, strlen(null) throws a Fatal Error. PrestaShop 8 core is fixed, but thousands of community modules perform operations on variables without checking if they are null first.
There was never a PrestaShop 1.8. The team decided to jump from 1.7.8 directly to 8.0. Why? To align with Semantic Versioning (Major.Minor.Patch) and to signify that the software is now a "Company Neutral" open-source project.
PrestaShop 9 is a massive technological jump. It adopts Symfony 6.4 (LTS) and embraces the modern features of PHP 8.2 and 8.3, such as Enums and Readonly properties.
PHP 8.2 deprecated "Dynamic Properties". In the past, you could assign a value to a property that wasn't defined in the class (e.g., $product->custom_flag = 1). PHP 8.2 warns against this, filling logs with gigabytes of data or crashing in strict mode. PS 9 modules must declare their properties.
class MyPaymentModule extends PaymentModule {
// No properties declared
}
$mod = new MyPaymentModule();
// Writing to undeclared property
$mod->api_key = '12345';
// WARNING: Creation of dynamic property deprecated// Option 1: Declare it (Best Practice)
class MyPaymentModule extends PaymentModule {
public string $api_key;
}
// Option 2: Use Attribute (Quick Fix)
#[\AllowDynamicProperties]
class MyPaymentModule extends PaymentModule { ... }PrestaShop has always been famous (and infamous) for its /override/ folder. In Version 9, the team is aggressively pushing Symfony Decorators instead. While overrides still exist technically, they are being phased out architecturally. The goal is to make PrestaShop upgradeable without "losing" your custom changes that conflict with core updates.
The upcoming PrestaShop 9.1 release represents one of the biggest architectural shifts in years, aiming to solve legacy "pain points" that have existed since version 1.6.
Solving the "1 Order = 1 Carrier" Limitation
Historically, PrestaShop operated on a strict rule: 1 Order = 1 Payment = 1 Carrier. If a customer bought a sofa (Freight) and a lamp (FedEx), PrestaShop would silently split this into two separate orders with the same reference ID. This confused both merchants and customers.
ps_shipment & ps_shipment_product.The old "Cart Rules" system was powerful but performance-heavy and complex. PrestaShop 9.1 introduces a new, structured approach categorized into 4 distinct types. This is not just a UI change; it redefines how price rules are calculated to avoid conflicts.
The "Classic" theme is finally retiring. Hummingbird 2.0 is built on Bootstrap 5 and focuses on compliance with the European Accessibility Act (EAA), achieving over 95% compliance score out of the box. It is lighter, faster, and designed to be a "parent theme" for agencies to extend easily.
Feature Flags Required: These new features (Shipments, Discounts) are hidden behind "Feature Flags" in the Back Office under Advanced Parameters > New & Experimental Features. They are currently in Beta.
| PrestaShop Version | Min PHP | Max PHP | Status |
|---|---|---|---|
| 9.1 Beta | 8.1 | 8.4 | BETA |
| 9.0.x | 8.1 | 8.4 | LATEST |
| 8.0 - 8.2 | 7.2.5 | 8.1 | STABLE |
| 1.7.8.x | 7.1 | 7.4 | SEC. FIXES |
| 1.7.0 - 1.7.7 | 5.4 | 7.1 - 7.3 | EOL |
| 1.6.x | 5.2 | 7.1 | EOL 2019 |
| 1.5.x | 5.3 | 5.6 | EOL 2014 |
| 1.4.x | 5.2 | 5.4 | EOL 2012 |
| 1.0 - 1.3 | 4.3 | 5.2 | ANCIENT |
| PS Version | Min RAM | MySQL / MariaDB | Web Server |
|---|---|---|---|
9.0 - 9.1 | 512 MB+ (1GB Rec.) | MySQL 8.0 MariaDB 10.6+ | Apache 2.4 / Nginx |
| 8.0 - 8.2 | 256 MB+ (512MB Rec.) | MySQL 5.7+ MariaDB 10.3+ | Apache 2.4 / Nginx |
| 1.7.x | 256 MB (Minimum) | MySQL 5.6+ MariaDB 10.1 | Apache 2.2 / 2.4 |
| 1.6.x | 128 MB (It was lighter!) | MySQL 5.1 - 5.6 MariaDB 5.x | Apache 1.3 / 2.x |
| 1.4 - 1.5 | 64 MB (Legacy Era) | MySQL 5.0 | Apache 1.3 |
| 1.0 - 1.3 | 32 MB (Yes, really.) | MySQL 4.x / 5.0 MyISAM Engine | Apache 1.3 |
Note on Nginx: PrestaShop officially supports Apache, but runs faster on Nginx. Nginx requires manual configuration rules.
memory_limit: We recommend 512M for all modern (1.7+) shops to prevent image generation crashes.
Artykuł napisany przez Milosza Myszczuka, eksperta PrestaShop i oficjalnego moderatora społeczności PrestaShop. CEO i założyciel agencji interaktywnej VEKIA. Dowiedz się więcej.
If you like this article, support our work!
Automatic National Bank of Ukraine (NBU) currency rates integrator. The module guarantees precise pr...
19.99 €
Streamline your order fulfillment process with the Order PDF Export module for PrestaShop. This esse...
39.99 €
Automatic Bank of Spain (Banco de España - BdE) currency rates integrator. The module guarant...
19.99 €
The Currency Exchange Module offers unparalleled flexibility in managing international sales. Regard...
19.99 €