The PrestaShop console: bin/console commands that save you hours

Since PrestaShop 1.7.8, the store ships with a Symfony console in bin/console. If you have SSH access to the server, it lets you do in seconds what takes several screens in the back office, and automate it.

Run it as the web server user

If you run the console as root, the cache files it generates will be owned by root and the web server will not be able to overwrite them: the back office will start throwing 500 errors. On a typical server:

sudo -u www-data php bin/console cache:clear --env=prod --no-warmup

Modules

php bin/console prestashop:module install mimodulo
php bin/console prestashop:module upgrade mimodulo   # ejecuta sus scripts upgrade/
php bin/console prestashop:module enable mimodulo
php bin/console prestashop:module disable mimodulo
php bin/console prestashop:module reset mimodulo     # desinstala y reinstala
php bin/console prestashop:module uninstall mimodulo

Cache

php bin/console cache:clear --env=prod --no-warmup
php bin/console cache:clear --env=dev --no-warmup

The Smarty cache (front office templates) is separate: it is cleared from Advanced Parameters > Performance or by deleting the contents of var/cache/prod/smarty.

Themes and emails

php bin/console prestashop:theme:enable mitema
php bin/console prestashop:mail:generate classic es

In some PrestaShop 9 versions the theme enable command fails from the console because there is no language in the context. If that happens to you, enable it from Design > Theme & Logo.

Debugging

php bin/console debug:router | grep mimodulo     # rutas registradas
php bin/console debug:container mimodulo         # servicios del módulo
php bin/console list prestashop                  # todos los comandos de PrestaShop

Core updates

The official update module (Update assistant, formerly 1-Click Upgrade) has its own console in modules/autoupgrade/bin/console, with commands such as update:check-requirements, update:check-modules and update:start. It can update from a local package, without downloads, and it is the most repeatable way to test an update on a copy before doing it in production.

A good habit

Keep the commands you run on each deployment (upload the module, upgrade it, clear caches) in a script. Running them the same way every time is the best way to make sure nothing is forgotten.