Maximum execution time exceeded in ModuleControllerRegisterPass: the PrestaShop 9 back office does not open

What happened#

On the first back office visit after an install, an upgrade or a cache clear, PrestaShop builds its Symfony service container and saves it in var/cache. One step of that build, ModuleControllerRegisterPass, goes through every installed module and opens each .php file in it, vendor folders included, to find the module's admin controllers.

That is a lot of files. On our PrestaShop 9.2 test store the modules folder holds about 27,000 PHP files, and a single payment module such as ps_checkout brings more than 2,000.

On a normal server the whole build takes seconds: the same test store opened its back office with an empty cache in about 10 seconds. When something makes each file read slow, the request reaches max_execution_time, PHP stops in the middle of the build with this message, and the next request starts the build over. The back office never opens.

Raising max_execution_time only helps when the build is just a little slow. The number in the message shows the limit PHP actually applied, so if it already says 180 or 600 seconds and the error stays, look for what slows down file reads.

The usual causes#

• The store sits in a folder synced by OneDrive. On Windows, Documents and Desktop often are. Files that are "available online only" are downloaded each time they are opened. Move the store to the web folder of your local stack, for example C:\MAMP\htdocs or C:\wamp64\www.
• The antivirus scans every file PHP opens. While testing, add the store folder to the exclusions: Windows Security > Virus & threat protection > Manage settings > Exclusions.
• Xdebug is loaded. It makes every PHP request much slower. If phpinfo shows an Xdebug section, turn it off for this PHP version.

The fix: build the cache from the command line#

PHP on the command line has no time limit, and bin/console lifts it itself in any case. From the store root:

php bin/console cache:warmup --no-optional-warmers

With MAMP on Windows, call PHP by its full path (adjust the version folder):

C:\MAMP\bin\php\php8.5.12\php.exe bin\console cache:warmup --no-optional-warmers

This builds the cache for debug mode. With debug mode off, add --env=prod. When the command finishes, reload the back office: the container is ready, so the page no longer has to build it.

Keep --no-optional-warmers. Without it, on our 9.2 test store the command also precompiled every Twig template and stopped with Allowed memory size of 536870912 bytes exhausted. The optional warmers are not needed to open the back office. With the option, the container was ready in about 10 seconds.

On a Linux server, run the command as the web server user (for example sudo -u www-data php bin/console …). Run as root, it leaves cache files the web server cannot write, and the back office answers with error 500. That happened in our test, and chown -R www-data:www-data var/cache fixed it.

Where else it hides#

The same build runs again after every cache clear: installing or updating a module, Clear cache in Advanced Parameters > Performance, every upgrade. In debug mode the container is also rebuilt whenever a file it depends on changes. If OneDrive or the antivirus is the cause, fix that rather than building the cache by hand each time.

To see which modules bring the most files:

for d in modules/*/; do echo "$(find "$d" -name '*.php' | wc -l) $d"; done | sort -rn | head