thirty bees, a maintained fork of PrestaShop 1.6 for merchants who want stability

A fork that chose stability over features

thirty bees is described as a matured e-commerce solution which once started as a fork of PrestaShop 1.6.1.11 and is still compatible with almost all PS 1.6 modules. The stated focus is on stability, correctness and reliability of the rich feature set, so that merchants can focus on growing their business.

That sentence is the whole thesis, and it explains why a fork of a version of PrestaShop from years ago still exists. PrestaShop 1.6 was a stable release with a large module ecosystem, and shops that ran it had a hard problem: the module ecosystem was tied to that version, and moving to a newer major version meant re-testing every module and often rewriting things. A fork that keeps the 1.6 behaviour while updating the underlying runtime keeps those modules working.

The compatibility claim is specific enough to check rather than take on faith, and it is the thing to verify before adopting. Compatibility with a module ecosystem also means compatibility with its quirks, including modules written for older PHP and older conventions.

The project also commits to being free and open source, and says it is committed to making all software it develops free and open source. It runs a backers page so the community can support the project, which is how a fork of an ageing platform funds itself without turning commercial.

The description on the repository is a blunt pitch: e-commerce that works for you.

The roadmap of deliberate removals

The roadmap section is the most revealing part of the README, because it lists what the project intends to remove rather than what it intends to add.

The first item is removing really old code, with retro-compatibility code for PS 1.4 and older named as an example. The second is removing pointless configuration switches in the back office, with the reasoning that quite a number of them are outdated or useless, just distracting merchants and slowing down operations.

Three specific switches are named. Support for multiple encryption algorithms, on the grounds that one reliable encryption is entirely sufficient. Support for mixed HTTP and HTTPS sites, described as a good idea in 2005 that triggers browser warnings today. And an ellipsis for the rest.

That middle example deserves a note for anyone evaluating the platform in 2026. A store running mixed HTTP and HTTPS will get browser warnings, and a platform that offers the option is doing merchants a disservice. The fork's position is that removing it is a service to them, even though it breaks configurations that some shops still rely on.

The remaining roadmap items are about consolidation rather than removal: package management for JavaScript and CSS vendor packages, bringing all modules provided by thirty bees up to the standards level of default modules, and moving the back office to Bootstrap 4.

There is also a Crowdin badge for the localisation of the interface, which tells you the project treats translation as a first-class ongoing task rather than an afterthought.

Requirements and what the installer checks

The requirements section states that support for the general requirements, except the recommendations, gets tested during installation, so a proceeding installation means all requirements are met. That is a good design choice for a shop owner who cannot evaluate the requirements in advance.

The required stack is PHP 7.4 through 8.3, Apache or nginx, Linux or macOS, and MySQL 5.5.3 or later or MariaDB 10 or later. The PHP extensions that must be present are bcmath, gd, json, mbstring, openssl, mysql with PDO only, xml covering SimpleXML and DOMDocument, and zip.

The recommended extensions are more revealing, because each one names a deficiency it compensates for. imap is recommended so that an IMAP server can be used rather than PHP's built-in mail function. curl is recommended for better handling of background HTTPS requests. opcache is recommended but not mandatory, with the explanation that some hosters turn it off in favour of other caching mechanisms. And apcu, redis or memcached are recommended as caching options.

The mysql extension note matters more than it looks. PDO only excludes the old mysql extension entirely, so a host running PHP with the legacy extension and no PDO driver for your database will fail the check rather than install and fail later.

Supported PHP versions from 7.4 to 8.3 is a wide range for a platform of this age, and it is the clearest sign that the fork is doing real maintenance work on the runtime rather than only freezing an old release.

Installing as a shop owner and as a developer

There are two installation paths and they suit different people.

For a shop owner the README describes downloading the latest release package, thirtybees-vXXX.zip at roughly 43 MiB, unpacking it into the web hosting directory, pointing the browser at the webhosting so the installer appears, and following the instructions. If you have no shell access you unpack it locally and upload all the files, with FileZilla given as an example, and using a subdirectory works fine.

For a developer the path is a recursive clone, because the repository uses submodules:

$ git clone https://github.com/thirtybees/thirtybees.git --recurse-submodules

Then you run Composer with the file matching your PHP version:

$ COMPOSER=composer/<php>/composer.json composer install

The version-specific composer files are visible in the repository layout, with a composer/ directory holding one file per PHP version, so the dependency set is pinned per runtime rather than floating.

After that you install through the browser at the install-dev path, or from the command line:

$  php install-dev/index_cli.php --newsletter=1 --language=en --country=us --domain=thirty.bees:8888 --db_name=thirtybees --db_create=1 --name=thirtybees [email protected] --firstname=thirty --lastname=bees --password=thirtybees

The README then lists the arguments the CLI installer accepts, which is unusually complete documentation for an installer. There is a step argument with the values all, database, fixtures, theme and modules, defaulting to all. Language, timezone, base URI, domain, database server, user, password and name all have defaults, as do the prefix, which is tb_, and the engine, which is InnoDB.

The flags with the most operational weight are db_clear, which drops existing tables and defaults to 1, and db_create, which creates the database if it does not exist and defaults to 0. A first run therefore wipes and recreates the schema, which is correct for a fresh install and destructive if you point it at an existing shop.

Repository layout, licence and where this fits

The top level of the repository is that of a full e-commerce application with a long history. There are the classic PrestaShop directories: classes/, controllers/, modules/, themes/, tools/, pdf/, mails/, webservice/, Adapter/ and Core/, plus override/ for class overrides, admin-dev/, install-dev/, config/, cache/, upload/, log/, localization/ and translations/. The Adapter and Core directories are where the fork's own abstractions sit.

There are also several things that indicate an actively maintained project rather than a frozen fork: a .gitmodules file, a SECURITY.md, a CODE_OF_CONDUCT.md, a CONTRIBUTORS file, a LICENSES directory, a docs/ directory, a .github directory, a build.sh script, a composer/ directory with per-version dependency files, and a codeception.yml with a tests/ directory.

On the licence, the repository's licence field says it is not one GitHub can classify. The README's supporter section is about funding rather than terms, and the developer installation mentions a --license argument that shows the thirty bees licence. For a platform that ships a licence file rather than a standard SPDX identifier, the practical step is to read the LICENSES directory and the terms shown by the installer before you commit a store to it.

The comparison to make is with the platform it forked from. If you are running PrestaShop 1.6 and it works, thirty bees is a way to stay on that feature set with a supported PHP version. If you are choosing a platform for a new store in 2026, the honest assessment is that this is a fork choosing conservatism, and a current platform offers more, so the choice is about module compatibility and team familiarity rather than capability.

The release history shows the pace. Version 1.5.1 shipped in November 2023, 1.6.0 in November 2024 and 1.7.0 in July 2026, with the last push on 2026-10-13.

Editorial conclusion

Adopt thirty bees if you run a PrestaShop 1.6 store and want the same module ecosystem with a maintained core that still supports PHP 8.3, or you need the option of a self-hosted shop without a subscription. Skip it if you are starting a new store and can commit to a current platform, since the fork deliberately carries legacy behaviour such as mixed HTTP and HTTPS support. Verify first by running the installer against a copy of your database and confirming that your existing PrestaShop modules install and function, and check the roadmap's list of removals for anything you rely on.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. thirtybees/thirtybees on GitHub