Skip to content

feat: add a Magento 2 definition#23

Open
geodro wants to merge 5 commits into
mainfrom
feat/magento
Open

feat: add a Magento 2 definition#23
geodro wants to merge 5 commits into
mainfrom
feat/magento

Conversation

@geodro

@geodro geodro commented Jul 10, 2026

Copy link
Copy Markdown
Member

Magento is the largest PHP framework the store does not cover. Detection is unambiguous, a bin/magento file or the community or enterprise metapackage in composer.json, and the major version has been 2 for a decade, so a single frameworks/magento/2.yaml spans 2.4.6 through 2.4.9.

Two things make it unlike every other definition here. Its deployment config lives in app/etc/env.php, a PHP file returning a nested array, so the env section uses the php-array format and addresses keys by dotted path, and it opts out of the app URL key because Magento keeps its base URL in the database. And setup/ sits outside the document root while /static/ and /media/ are generated on demand by pub/static.php and pub/get.php, so the definition ships the nginx it needs: without it an uninstalled store redirects to /setup/ forever, and static.php never receives the resource parameter it reads, so every asset is a 404.

Magento 2.4 removed the web installer, so a fresh store is installed from the command line. That lives in commands rather than setup, gated behind a confirmation, because it creates schema and an admin user and lerd setup --all runs every setup step regardless of its default. Everything else needs an installed store, so the setup steps and the rest of the commands are gated on app/etc/config.php, which setup:install writes and lerd's env wiring never does. The schema, dependency injection and indexer commands run with the memory limit lifted, since they blow past PHP's default.

This needs the nginx.snippet key and the php-array env format from lerd-env/lerd#845, and does nothing useful until that ships.

Closes #20

Magento is the largest PHP framework the store did not cover. Detection is unambiguous, a bin/magento file or the community or enterprise metapackage in composer.json, and the major version has been 2 for a decade, so a single frameworks/magento/2.yaml spans 2.4.6 through 2.4.9.

Two things make it unlike every other definition here. Its deployment config lives in app/etc/env.php, a PHP file returning a nested array, so the env section uses the php-array format and addresses keys by dotted path, and it opts out of the app URL key because Magento keeps its base URL in the database. And setup/ sits outside the document root while /static/ and /media/ are generated on demand by pub/static.php and pub/get.php, so the definition ships the nginx it needs: without it an uninstalled store redirects to /setup/ forever, and static.php never receives the resource parameter it reads, so every asset is a 404.

Magento 2.4 removed the web installer, so a fresh store is installed from the command line. That lives in commands rather than setup, gated behind a confirmation, because it creates schema and an admin user and lerd setup --all runs every setup step regardless of its default. Everything else needs an installed store, so the setup steps and the rest of the commands are gated on app/etc/config.php, which setup:install writes and lerd's env wiring never does. The schema, dependency injection and indexer commands run with the memory limit lifted, since they blow past PHP's default.
@geodro geodro requested a review from a team as a code owner July 10, 2026 12:55
geodro added 4 commits July 10, 2026 16:17
Magento 2.4 removed the MySQL catalog search engine, so a store cannot boot without a search engine at all. Naming it in requires means lerd installs and starts opensearch when the project is linked, rather than letting setup:install die partway through the schema install with a stack trace that never mentions it.
Magento's CLI needs far more than PHP's 128M default, and it is not only the schema and index commands. Switching deploy mode regenerates the config cache and dies in symfony/cache with an allocation failure, which surfaces during lerd setup as a fatal error with no hint of what asked for the memory.

Guessing which commands need the headroom was wrong twice, so every one-shot command lifts the limit now. The two long-running workers keep the default, because an unbounded process that runs forever is how a leak takes the machine down rather than one command.
Magento's CLI blows past PHP's 128M default, and guessing which commands needed the headroom was wrong twice: the schema and index commands were obvious, switching deploy mode was not. The web side never needed anything, since Magento ships a pub/.user.ini that PHP-FPM reads and the CLI SAPI ignores.

Declaring php.cli_ini once lets lerd pass it to every PHP process it starts for the project, so the nine commands go back to reading as the commands Magento documents. The two long-running workers still run at the default, because an unbounded process that runs forever is a different risk from a command that ends.
Magento cannot bootstrap at PHP's 128M default, so the cron and consumer workers crash-looped. Now that lerd hands cli_ini to workers too, an unbounded -1 would follow a process that runs until you stop it, and di:compile peaks around 450 MiB anyway, so nothing needed it. 2G is what Adobe documents for the CLI and leaves plenty of headroom.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add a Magento 2 definition

1 participant