Behaviour changes of 16 to 30 September 2026 #

Read this page before you take the changes of 16 to 30 September 2026 to an existing Exponential 6.0 installation. It lists what visitors, editors, installers and operators will notice, and what to do about it. Each row names the change, who is affected, the setting that controls it and the action; longer explanations are linked. This is the upgrade companion of the chronicle for the period. The previous period is in the chronicle of 1 to 15 September, the next in behaviour changes of October 2026.

Deploy order #

Do these first, in this order, on every site you take the changes to:

php bin/php/ezpgenerateautoloads.php -e
php bin/php/ezcache.php --clear-all --allow-root-user
systemctl reload <php-fpm service>      # the PHP-FPM service that serves your site
./console exp:velocity deploy --dry-run # if you run Velocity: shows every step

The three changes most sites must act on:

1. Security headers and the session cookie (first two rows below): check any host that frames the admin, and any script that reads the session cookie.
2. The admin content tree starts at the top node: set RootNodeID=2 if editors want the old tree.
3. Add the cache_cleanup cronjob part to your crontab (see "Caches and web servers").

Visible to visitors and editors #

Installers and operators #

Caches and web servers #

Fixes that change results #

• Subtree counts with a language find a start node that has no translation in that language and no longer leave that language set; counts that used to come back empty now match the fetch.
• Packages: content installs completely and under the right parents; old V7 tar packages import (no hang); old class packages install.
• MongoDB: every SELECT COUNT, date-ordered list, $inc on a quoted number and search reindex now work; see MongoDB kernel support.
• Search indexing takes the batched path on SQLite and PostgreSQL as well as MySQL (about twice as fast on SQLite, same index).
• Absolute URLs keep the port an installation is reached on; host matching ignores the port, so links no longer carry the siteaccess name when the site is served on a non-default port.

Details behind the cache, archive and engine changes #

The tables above say what to do. These are the facts behind them, for the people who tune a server. Measurements are from a reference installation on the dates given and were not repeated for this page.

HTTP cache (httpcache.ini) #

• Compressed once. A hit used to put the visitor's values into the stored page and compress the whole page for every request, the largest cost of a hit. The parts of the stored body between placeholders are compressed once (each ending in a full flush, so each stands alone) and kept in APCu beside the entry; a hit compresses only its placeholder values (a form token) and joins the pieces into one gzip member with the page's CRC-32. Without APCu it compresses the page as before. The bytes served are identical (test HC-11). Measured 27 September, 8 concurrent, cached front page on FrankenPHP: 4,048 pages a second anonymous (about 2,800 before) and 3,413 signed in (3,010).
• Security headers on cached pages. The cache answers without the kernel, so a cached page used to lack the headers a rendered page carries. The configured [HTTPHeaderSettings] SecurityHeaders[] are stored with the page, and the cache key carries the scheme so an HTTPS-only header never reaches an HTTP answer.
• Siteaccess matching. URI and host-plus-URI matched siteaccesses are served, and a siteaccess the cache does not serve is reported as X-Exp-Cache: MISS (siteaccess) and kept out of the miss counters. RemoveSiteAccessIfDefaultAccess and PathPrefix need nothing of their own (a page is kept under the full request URI). Behind a TLS-ending load balancer the engine must hand over the request headers (engine release 0.0.4.35 and later).
• Purge tags are sent only when [HttpCacheSettings] TagHeader names a header (see security defaults).
• Setup > Caches clears the query cache and the HTTP cache, and Setup > System information shows both.

SQL query cache (querycache.ini) #

• A hit is answered without parsing the statement. The cache read the tables from the statement text before it looked for a stored result, every time; that was a third of a rendered page's CPU. A stored entry already carries its tables, so the entry is looked up first and the text parsed only on a miss; an entry whose tables have since been excluded, or are temporary, is not answered from (test QC-13). A single Velocity render went from 211.6 to 141.2 ms of CPU with the same bytes.
• Keys use xxh128 of the statement and its parameters (0.84 against 1.55 microseconds a key; md5 where PHP lacks xxh128).
• The database's own catalogue is never cached (sqlite_master, sqlite_stat*, pg_*, information_schema, and for Oracle USER_*, ALL_* and the like): ANALYZE and schema changes are no writes the cache sees, and a cached sqlite_master read was answered stale within the same request (test QC-14).
• The SQL profile counts each request on its own under a persistent worker: every line of var/tmp/sql_profile.log used to repeat the warm-up's figures; a request that sends nothing to the database writes no line.
• APCu size: the cache and the response cache share APCu; Velocity's PHP gets apc.shm_size=256M (see Velocity). Several servers on one port ([ServerSettings] Instances) are described in Velocity engines.

Engine archive (exp:phar) #

• The build writes the archive under a temporary name beside it and renames it into place. Before, it deleted dist/engine.phar and wrote the new one in place, so every build left a window with no archive, and two builds at once (a restart rebuilding a stale archive while you built by hand) left none, after which the server would not start.
• The syntax check before the build uses the PHP that runs the build (it ran php -l from the PATH, so where there is no php on the PATH every file "failed" and nothing was built) and checks files 200 to a php -n -l call (1,049 files: nine minutes before, about two seconds for the checks and about 26 for the whole build). A batch that fails is checked file by file so a broken file is still named and nothing is written.
• A stale archive says how to fix itself (exp:phar check, exp:phar build); see Engine archive.

Engines and the server commands #

• The three engines (php, qbix, frankenphp) follow the same asset rules as .htaccess_root; [ServerSettings] FollowSymlinks=disabled refuses a file a link inside the document root leads to outside of it (Qbix answers 403, the built-in server 404). Caddy always follows links.
• FrankenPHP serves HTTPS by default ([FrankenPHPSettings] HTTPS=enabled), offers compression (zstd br gzip; the front page went out at 95.7 KB uncompressed where gzipped it is about 10 KB) and runs by default twice the CPU cores of PHP threads (an empty [FrankenPHPSettings] Workers), not the bundled server's Workers, which counts mostly idle processes (measured with 64 concurrent pages: 16.0 requests a second with 12 to 48 threads, 14.6 with 96 or 590).
• exp:webserver, exp:frankenphp and exp:solr: Server control commands.

Preload #

Start preloading on Setup > Preload runs the crawl as a background process, so it works behind Velocity and behind proxies that buffer streamed answers. Nothing to configure; see Preload Sites.

Related pages #

• Chronicle, 16 to 30 September 2026
• Security defaults
• Datatype and input hardening
• Database drivers and installers, September 2026
• Server control commands
• Maintenance mode, Order receipts, Store dashboard
• Changelog 6.0.15