Behaviour changes of the legacy extensions (September and October 2026) #

Read this page before you upgrade a site that uses the legacy extensions, designs or themes shipped with or beside Exponential 6.0.15. Between 22 September and 2 October 2026 all of them were brought up to the same standard. Most changes are invisible; this page lists the ones that are not, in the order you should check them, each with how to check and how to fix. Each extension's own page under Extensions lists its releases.

Quick checklist #

1. Update the extensions you use to their current release (see the release notes). Keep se7enxweb/expui installed.

2. Regenerate autoloads and clear the caches:

   php bin/php/ezpgenerateautoloads.php -e
   php bin/php/ezcache.php --clear-all --allow-root-user

3. Search your own extensions and designs for the patterns in sections 1, 4 and 6 below.

4. Check roles for renamed and new policies (section 7) and act on the security fixes (section 9).

5. Refresh anything that caches packed scripts and styles (ezjscore 1.5; --clear-tag=template,content).

1. Persistent PHP workers: module views no longer declare at file level without a guard #

What changed (22 September 2026). Exponential includes a module view on every request. A function or class declared at the top level of that file is declared a second time on the second include, which is fatal. With one process per request this never happens; under a persistent worker (Exponential Velocity, FrankenPHP) it kills the worker on the second request, and the client gets a 502.

In explayouts_ui, explayouts_ui_api, cjw_newsletter, eztags, ezupdate, ezflow, ezodf, ezpm, xrowmetadata, nxc_powercontent, syndication, sevenx_dse and xrowextract every such declaration is now wrapped in function_exists() or class_exists(), and moved to the head of its file. (PHP binds an unconditional top-level declaration before the first line runs; a guarded one exists only once execution reaches it, so a file that called a function above its own declaration would otherwise break.) Behaviour under Apache and PHP-FPM is unchanged.

How to check your own code.

grep -rln "^function \|^class " extension/*/modules extension/*/classes/runnable/views 2>/dev/null

Every file listed declares at file level and needs a guard.

How to fix.

• Wrap each declaration: if ( !function_exists( 'myHelper' ) ) { function myHelper() { ... } } and if ( !class_exists( 'MyClass', false ) ) { class MyClass { ... } }.
• Better: make the view a class, as described in Commands, cronjob parts and module views as classes.
• Avoid state in function statics and static variables that must reset between requests. Examples: ezstarrating 6.0.3, whose rating statistics cache lived in a function static; sevenx_dse 1.1.1, whose security-policy nonce did.

2. Forgot password pages no longer tell whether an address has an account #

What changed. The kernel's user/forgotpassword stopped answering "There is no registered user with that email address" for a valid address, because that lets anyone test addresses one by one. The designs and the extension that carried their own copy of the page did the same on 27 September 2026: ezwebin 6.0.7, ezdemo 6.0.4 and ezmbpaex (the userpaex/forgotpassword view) 6.0.2. Now:

• an unknown but valid address gets the same page as a known one ("if an account is registered with the address, a mail has been sent to it");
• input that is not an e-mail address gets "Please enter a valid email address.";
• an address posted as an array is treated as not given;
• every address the page prints is escaped with |wash.

The messages use the kernel's translation context design/standard/user/forgotpassword, so existing translations apply. ezmbpaex 6.0.3 also makes the reset key 128 random bits from the system's secure source (it was an md5 of the time and mt_rand()). Keys and links keep their shape; existing links work until they expire.

How to check. If your site design overrides user/forgotpassword.tpl or the userpaex template, compare it with the kernel's. Tests or documentation that expect the old message must change.

3. Error pages show their own error in the page title #

What changed. Every error page reaches the page layout with the same URI, so whichever error was cached first gave its title and path to all later ones: a "Page not found" could carry the title of the access denied error. The head, path and menu cache blocks of ezwebin 6.0.8, ezdemo 6.0.5 and sevenx_themes_simple 1.0.15 now add the error type and number to the URI key when the page is an error page. Every other page keeps exactly the same cache key.

How to check and fix. If your own pagelayout.tpl has {cache-block keys=array( $module_result.uri, ... )} around the head, path or menus, key error pages by error type and number too, as the extensions do:

{def $uri_cache_key = $module_result.uri}
{if is_set( $module_result.errorType )}
    {set $uri_cache_key = concat( $module_result.uri, '|error|', $module_result.errorType, '|', first_set( $module_result.errorNumber, '' ) )}
{/if}
{cache-block keys=array( $uri_cache_key, $user_hash, $extra_cache_key )}
    ...
{/cache-block}

4. YUI is gone; jQuery 4 and Exponential UI replace it #

The whole picture and the replacement table are in YUI removed from Exponential. For the extensions:

These extensions require se7enxweb/expui ^1.0.0.1 where they use its modules (eztags, ezwebin, ezwt, ezmultiupload, ezautosave).

jQuery 4 itself removed helpers: $.isArray, $.trim, $.proxy, $.browser, the .click(), .bind() and .unbind() shorthands, and boolean .attr(). eztags, ezie, ezstarrating, cjw_newsletter, ezwebin, ezdemo, xrowmetadata and the simple theme's Magnific Popup were ported (.on(), .off(), .prop(), Array.isArray).

How to check your own scripts:

grep -rnE 'YUI\(|YAHOO\.|ezjsc::yui|\$\.browser|\$\.isArray|\.bind\(|\.unbind\(|\.load\(function' extension/ design/

5. HTML5 markup in the designs #

ezwebin 6.0.3, its installer package ezwebin-ezpackage, ezwt 6.0.3 and sevenx_themes_simple 1.0.12 (July 2026) write HTML5:

• XHTML self-closing slashes (<br />, <input />, <img />, <meta />, <link />) are gone;
• obsolete type and language attributes on <script>, <style> and stylesheet <link> tags are gone;
• the toolbar stylesheet dropped vendor prefixes.

ezdemo, ezodf and ezflow followed with <br> (27 September). bcwebsitestatistics 1.0.6 does the same for the analytics tags. If your design overrides these templates, a style or script that selects on the old attributes, or expects XHTML output, may need a change.

6. Code that must run on every database #

A series of fixes (29 and 30 September 2026) made queries portable. Custom code should follow the same rules; the extensions' fixes show each one:

7. Names, tabs and policies that changed #

8. The layout editor API: tokens, drafts and locked zones #

• explayouts_ui_api 1.3.3 refuses every non-GET request that does not carry the session's form token (X-CSRF-Token header or ezxform_token field) with HTTP 403 and the JSON body {"error":{"code":403,"reason":"form_token_missing"}}.
• 1.3.4 refuses block writes unless the block belongs to a draft.
• 1.2.1 refuses writes to blocks of a published shared layout and into linked zones.

Scripts that drove the API must fetch the token from GET /explayouts_ui_api/app/api/config (csrf_token), work on drafts, and publish. See the API specification.

9. Security fixes that may need action #

10. Metadata, translations and integrity manifests #

• Every extension now has an ezinfo.php and an extension.xml that both state name, version, copyright, license and website, so Setup > About and the upgrade checks show them. A few showed the directory name as their name; they now show their real names (for example "Enhanced eZBinary File Type", "Xrow Meta Data", "Exponential Layouts UI API").
• Tab names, tooltips, navigation parts and left menu entries of extensions are translated in the contexts design/admin/pagelayout, kernel/navigationpart and design/admin/parts/<menu>/menu; add your language there.
• cjw_newsletter's share/filelist.md5 (the manifest behind Setup > System Upgrade > File consistency check) now matches the files. Before 4.1.5 the check reported files nobody had touched.
• The copyright notices in the extensions name "1998 - 2026 7x & Exponential Foundation" first, above the original eZ Systems notices, which stay as the GPL requires.

11. REST API v1 and v2 come from one extension; ezprestapiprovider is deprecated #

What changed (15 October 2026). ezprestapi 1.2.6 serves REST API v1 and v2 alone: one provider class, ezp7xRestApiProvider, for the prefixes ezp and ezpl, one route table, one OAuth2 setup. ezprestapiprovider 6.0.4 is its final release and a compatibility shim: ezpRestApiProvider and ezpRestContentController extend the classes of ezprestapi, its rest.ini maps ezp and ezpl to ezp7xRestApiProvider, and the five classes it duplicated are gone. Before, when ezprestapiprovider was listed earlier in ActiveExtensions or active alone (as the setup wizard used to activate it), every /api/ezp/v2/... route answered 404 and the v1 reads ran without the permission checks. Now every combination routes every URL to ezp7xRestContentController. OutputFormat=xhtml fills renderedOutput again; every other v1 and v2 answer is unchanged.

How to check. grep -rn "ezprestapiprovider\|ezpRestApiProvider\|ezpRestContentController" settings/override extension/*/settings extension/*/classes finds the activation, a rest.ini override that names the old provider, and code that extends the old controller.

How to fix. Keep or add ActiveExtensions[]=ezprestapi and remove ActiveExtensions[]=ezprestapiprovider; change ProviderClass[ezp]=ezpRestApiProvider to ezp7xRestApiProvider; then php bin/php/ezcache.php --clear-tag=ini --allow-root-user, php bin/php/ezpgenerateautoloads.php -e, reload PHP-FPM and restart Velocity. Nothing changes for OAuth clients, tokens, personal API keys or v1 URLs. The steps and the before and since table are in REST API v1 and v2: one extension.

Related pages #

• REST API v1 and v2: one extension

• YUI removed from Exponential

• Commands, cronjob parts and module views as classes

• PHP 8 support, Velocity engines, Security hardening

• Release notes of all extensions

• History of the extensions

• An extension can replace a kernel module

• Extensions in more than one folder

• History: January 2024, 16 to 31, September 2024, October 2024