Extension porting status

Every extension that ships in the PHP source tree, and where it stands on this port. There is a machine-readable version of the optional extensions, per PHP version, in components/php/versions/<version>/manifest.toml (for the current default, 8.4.24). That manifest is the contract the flash-tool CLI (phpflash) reads: the flags, settings, dependencies, fetch scripts and per-mode rules. It is the single source of truth — phpflash init offers the optional extensions from it, and enabling one in the project config compiles it in. By hand, each is a -DPHP_EXT_*=ON flag on idf.py build.

The three states

Each extension is in exactly one of three states.

The Roadmap classification says where an unshipped extension is headed:

• Done — anything shipped (built-in or flag).
• Planned — a realistic next port: self-contained, no external library, no missing OS feature, ranked by value. Next up are the self-contained utilities bcmath (arbitrary-precision math) and phar (bundling an app into one archive), then the more situational exif (image metadata, useful with the P4's camera).
• Not planned — could be ported, but nobody has committed to it. Ask if you need one.
• Not possible — relies on something a bare-metal target fundamentally lacks: fork, processes, shared memory, a dynamic loader, an interactive TTY, or Windows COM.

The always-on core

The language itself (the Zend engine) plus these extensions are compiled unconditionally. They carry no flag and cannot be turned off:

Core · standard · pcre · hash · json · spl · reflection · random

standard is the bulk of the standard library — strings, arrays, math, var_dump, printf, URL, base64, crypt. pcre is the PCRE2 regex engine, hash the md5/sha/sha3 family, spl the iterators and data structures, reflection the Reflection API, and random the Random\Engine API with random_int(). Every project type (init-loop, web-server, event-driven) lists all of these as required.

The project's own extensions

Three non-standard extensions of ours ship alongside the core. They are built in, but their required scope differs.

Full list

Every extension in the upstream source tree. skeleton, dl_test and zend_test are omitted — they are the source tree's example and test extensions, not real features.

Why so much is "not available"

The unported set falls into a few clear buckets. Knowing which one an extension lands in tells you whether it is worth asking for.

• Needs an external library PHP does not bundle — bz2, curl, dom/libxml/simplexml/soap/xml/xmlreader/xmlwriter/xsl, gd, gettext, gmp, iconv, imap, intl (ICU), ldap, mysqli/mysqlnd/pdo_mysql, oci8/pdo_oci, odbc/pdo_odbc, pgsql/pdo_pgsql, pspell/enchant, snmp, sodium, tidy, zip, zlib, and the other pdo_* drivers. Porting the library is the real work; the extension follows.
• Depends on an OS feature this target lacks — pcntl (no fork), posix (no users/processes), shmop (no shared memory), sysvmsg/sysvsem/sysvshm (no System V IPC), ffi (no dynamic loader), readline (no interactive TTY), com_dotnet (Windows only). These are Not possible on a bare-metal RTOS target, not merely unported.
• Self-contained and portable, just not done yet — bcmath, phar, exif (all Planned), and calendar/fileinfo (portable but deprioritized). sockets is a candidate: lwIP already gives BSD sockets, but ext/sockets itself is not wired up.

Build flags at a glance

Every optional extension and its sub-options. phpflash init offers these interactively and fetches any extra sources on demand; setting them by hand means adding the flags to idf.py build.

Some flags pull sources that are not committed to the repo. The manifest names a fetch script that must run before the build: scripts/fetch-sqlite.sh for the SQLite amalgamation, scripts/fetch-oniguruma.sh for mbstring's onig setting, and scripts/fetch-openssl.sh for the full OpenSSL build. phpflash runs these automatically when the extension is enabled.

Enabling an extension in the project config

In a php-esp32.config.toml, each optional extension is a [extensions.<key>] table with enabled = true and any of its sub-settings. phpflash translates these to the -D flags above at build time. A few worked examples follow.

[extensions.mbstring]
enabled = true
no_cjk = true

[extensions.sqlite]
enabled = true

[extensions.date]
enabled = true

By hand, the equivalent is a flag on the build:

idf.py build -DPHP_EXT_MBSTRING=ON -DPHP_EXT_MBSTRING_NO_CJK=ON

Notes on the flag extensions

Detail on the extensions that ship behind a flag, beyond the one-line reason in the table.

date — stub plus full

date is unusual: a UTC stub is always present, covering the core date/time functions against UTC. -DPHP_EXT_DATE=ON replaces it with the real ext/date — the DateTime class and the full API — at a cost of ~650 KB, about 350 KB of which is the bundled timezone database. The minimal_tz setting ships a UTC-only tz db instead: ~300 KB total, no named zones.

mbstring — the heavy one

mbstring is the largest optional extension, ~965 KB, most of it the CJK conversion tables in the bundled libmbfl.

UTF-8, UTF-16 and Latin are unaffected by no_cjk. The onig setting is off by default because most code does not need multibyte regex, and it is the difference between ~965 KB and ~1.38 MB with full mbstring.

openssl — subset or full

The default -DPHP_EXT_OPENSSL=ON is a small mbedTLS-backed subset (~42 KB): symmetric AES only — openssl_encrypt, openssl_decrypt, openssl_cipher_iv_length, openssl_random_pseudo_bytes — enough for something like Laravel's Encrypter. The full setting builds the real ext/openssl against a ported OpenSSL 3.0 libcrypto instead (~2.1 MB): RSA, EC, X.509, EVP, digests, and on-chip keygen. The tls setting (full build only) adds the ssl:///tls:// stream transport for an HTTPS client, and no_load_config skips reading openssl.cnf at startup. Full detail in openssl.md.

opcache — bytecode cache, no JIT

-DPHP_EXT_OPCACHE=ON (~500 KB) caches compiled bytecode so each request skips re-tokenizing and recompiling the sources — the per-request cost for a framework is compilation, so this is a large win. The default is a file cache on the microSD (bytecode on the card, full PSRAM free for the request). The in_memory setting keeps the cache in PSRAM (SHM) instead, fastest once warm, but the whole bytecode plus per-request heap must fit in PSRAM — good for a small app, not a large framework. See opcache.md.

pdo / sqlite

-DPHP_EXT_SQLITE=ON builds ext/pdo and ext/pdo_sqlite together, ~560 KB (about 530 KB of that is the SQLite library itself, fetched via scripts/fetch-sqlite.sh). The standalone SQLite3 class is not built — use the PDO driver.

session, tokenizer, ctype, filter

The small, self-contained ones. session (~50 KB) gives session_start(), $_SESSION, session_id() and save handlers — the files handler (point session.save_path at a writable dir such as the microSD) and user handlers via session_set_save_handler(). tokenizer (~13 KB) exposes token_get_all(), token_name(), the PhpToken class and the T_* constants over the engine's own lexer, wanted by frameworks and static-analysis tools. ctype (~2.5 KB, one source file, no data tables) and filter (~27 KB, filter_var() validation and sanitization) are pure additions with no sub-options.

Networking is not an extension

Networking does not appear in the extension list. It comes with a board that has a network (the P4-ETH or the S3-ETH) and is configured in php-esp32.config.toml under [network] (static DNS) and [extensions.openssl] (the tls and certs_path settings for the HTTPS client). The web-server project type adds an HTTP server (esp_http_server) in front, invoking PHP fresh per request. See openssl.md and the https-client example.

Writing your own

If the extension you need is not here and not portable as a straight PHP source-tree extension, a project can ship its own C extension — compiled into the firmware alongside the core, with its own functions and constants exposed to PHP. See custom-extensions.md.