What It Needs to Run

PHP, MySQL or MariaDB, OpenSearch, Composer 2, and the optional extras - plus why the search engine is not optional.

Syntax"php": "~8.3.0||~8.4.0||~8.5.0"

Magento 2.4.9 has a short list of hard requirements and a shorter list of optional ones. The hard list is PHP with its extensions, a MySQL-family database, Composer 2, and a search engine.

PHP

The platform's own composer.json declares "php": "~8.3.0||~8.4.0||~8.5.0". This course uses PHP 8.4. The tilde is shorthand: ~8.4.0 means exactly the same as >=8.4.0 <8.5.0, so any 8.4 patch release satisfies that clause and 8.5 is matched by the next one. Extensions are declared in the same block. The ones most often absent from a stock build are intl, soap, xsl, sodium and bcmath.

The search engine is not optional

MySQL search was removed in 2.4.0. Catalogue search, layered navigation and product listings are all served by the search engine, which for 2.4.9 means OpenSearch. The installer, and every later setup:upgrade, validate the connection before touching the schema. The configured engine is stored at the configuration path catalog/search/engine.

Database and the optional extras

MySQL 8.4 or a supported MariaDB release. Then, optional but normal in production: Valkey, the Redis-compatible fork Adobe lists for 2.4.9, for cache and session storage; RabbitMQ or ActiveMQ Artemis for message queues, which asynchronous and bulk REST need; Varnish as the full page cache. Linux x86-64 is the only supported host - Windows and macOS are not, which is why local work usually happens in Docker.

Example

Example · bash
# pre-flight check on the host, before installing Magento 2.4.9

php -r 'echo PHP_VERSION, PHP_EOL;'
# 8.4.13

# the extensions most often missing from a stock PHP build
php -m | grep -E '^(bcmath|intl|soap|sodium|xsl|zip)$'
# bcmath
# intl
# soap
# sodium
# xsl
# zip

composer --version
# expect a Composer 2 release; Composer 1 cannot install 2.4.9

mysql -h 127.0.0.1 -u magento -p -e 'SELECT VERSION();'
# +-----------+
# | VERSION() |
# +-----------+
# | 8.4.6     |
# +-----------+

# the search engine is not optional
curl -s 'http://localhost:9200/_cluster/health?pretty' | grep status
#   "status" : "green",

When to use it

  • Specifying a server before a project starts, so the stack is not a surprise in week three.
  • Diagnosing a storefront search page that returns nothing after a server move.
  • Deciding whether message queues need RabbitMQ for the features a client has asked for.

More examples

The requirement block the installer enforces

An excerpt from composer.json in the project root, after installation. Composer checks this before downloading anything, so a missing extension or PHP 8.2 fails at create-project time with a clear message rather than halfway through setup:install. Run composer check-platform-reqs to see the same check on an existing install.

Example · json
{
    "require": {
        "php": "~8.3.0||~8.4.0||~8.5.0",
        "ext-bcmath": "*",
        "ext-intl": "*",
        "ext-soap": "*",
        "ext-sodium": "*",
        "ext-xsl": "*",
        "ext-zip": "*",
        "lib-libxml": "*"
    }
}

Pointing the install at the stack

Reach for this when the services are not on localhost, which is the normal case in Docker or on a managed host. The --amqp-* group is only needed if you run message queues; omit it and consumers fall back to the database queue. Changing the search engine later is a configuration change plus bin/magento cache:flush.

Example · bash
# the flags that name the services, as part of setup:install
bin/magento setup:install \
    --search-engine=opensearch \
    --opensearch-host=opensearch --opensearch-port=9200 \
    --amqp-host=rabbitmq --amqp-port=5672 \
    --amqp-user=magento --amqp-password=magento \
    --session-save=files
    # ... plus the --base-url, --db-* and --admin-* flags

# afterwards the engine lives in configuration, not in env.php
bin/magento config:show catalog/search/engine
# the configured engine, for example opensearch

Checking a running install rather than the host

The command line and PHP-FPM read separate ini files, so a generous memory_limit on the CLI tells you nothing about the storefront. This is the first thing to check when setup:di:compile or static content deployment dies with an out-of-memory error while the browser is fine.

Example · bash
# what the application thinks it is running on
bin/magento info:currency:list | head -3
php -i | grep -E '^(memory_limit|max_execution_time)'
# memory_limit => 2G => 2G
# max_execution_time => 0 => 0

# CLI and web often use different php.ini files - check both
php --ini | grep Loaded
# Loaded Configuration File: /etc/php/8.4/cli/php.ini

Related

m2 installm2 dev dockerm2 cache redism2 indexer introm2 cli

Discussion

  • Be the first to comment on this lesson.