LoveStack features in Exponential 6 #

LoveStack is Mugo Web's distribution of the legacy kernel originally published by eZ Systems (mugoweb/ezpublish-legacy on GitHub and Packagist). Over the years Mugo Web added a number of valuable features and fixes to it. Exponential 6.0.15 brings 36 of them into the Exponential distribution, each one rebuilt in Exponential's own APIs, documented and covered by tests, so that every Exponential site can use them together with Exponential's own features. With thanks to Mugo Web, whose work this is built on.

This page is the overview: what each feature does, who it is for, how to switch it on, its settings and defaults, what changes on an upgrade and on a new installation, the test that covers it and the LoveStack commit it comes from. The detailed pages are listed in More documents.

In one sentence: nothing changes on an existing site unless you switch it on, except plain bug fixes, a few new warnings and log settings, and the security checks for logging out (L03) and for uploaded images (L05, L06).

If you run Exponential and never ran LoveStack, there is nothing to do: the features are in 6.0.15, and the ones that could change how a site behaves are off until you turn them on. If you run LoveStack, see Moving a site from LoveStack.

Source reference (where the features come from, and when) #

The LoveStack features brought into Exponential were taken from Mugo Web's repository mugoweb/ezpublish-legacy as it stood on the day of the port, 12 October 2026. Every feature, test and comparison in this document refers to that exact commit, so the work can be reproduced and checked against the same source at any time.

To reproduce: git clone https://github.com/mugoweb/ezpublish-legacy && git -C ezpublish-legacy checkout e61e9fdf0ca464197b79935ef784ed459721aa87. The commit ids named for each feature (L01–L36) below are commits in that repository and open as https://github.com/mugoweb/ezpublish-legacy/commit/<id>.

The features in plain terms #

What the 36 features are, grouped by what they do to an existing site after the upgrade.

On for every site: fixes and safety checks #

On for every site: small visible changes #

New options, off until you switch them on #

On for new installations, off for upgrades #

New APIs for developers (additions only, nothing existing changes) #

In short #

The visible new features are required alt text, trimmed text fields, a Copy button, location audit records, custom tag controls in the editor, extra error-page headers and settings-file includes. The security changes are ezjscnode behind a policy, registration that can be closed, a real logout, unique logins and image uploads checked by their content. Everything else is small bug fixes and developer helpers.

Feature by feature #

Each entry says who it is for (editor, administrator, developer), what it does, its settings with their shipped defaults, what a new installation and an upgraded site get, how to switch it on, the test that covers it and the LoveStack commit it comes from. Settings you change go into an override (settings/override/<file>.append.php) or a siteaccess, never into the shipped file; clear the INI cache afterwards (php bin/php/ezcache.php --clear-tag=ini). Test files are under tests/tests/ and run on their own: php vendor/bin/phpunit tests/tests/<path>.

Security and sessions #

L01 — Node data calls can require a policy #

For administrators. The ezjscore calls ezjscnode::load, ::subtree and ::updatepriority return a node's name, ids, remote id, owner, section, dates, class and translations as JSON or XML to every user who may read the node, anonymous visitors included. With RequirePolicy=enabled a user also needs the policy ezjscore / call with the function list ezjscnode.

L02 — Registration can require a policy #

For administrators. Registering a new account (user/register) can be taken out of the list of views everyone may open, so it needs the policy User / Register. The login pages of admin and admin4, the standard design and its login toolbar, the media and the starter designs show the register link or the Sign Up button only to a user who may open user/register, so a site without open registration shows no dead link.

L03 — Logging out ends the session and its cookie #

For everyone. Logging out removes the session and its contents instead of giving it a new id with its contents kept. Every session handler sends the session cookie expired with the same path, domain, Secure, HttpOnly and SameSite it was set with, so the browser drops exactly that cookie, and the old session id no longer signs anyone in. A session started later in the same request gets a new id, under PHP-FPM and Velocity alike.

L04 — One account per login #

For administrators. A login belongs to one account. A console command lists the logins more than one account has (also those that differ only in case) and adds a unique index on ezuser.login once there are none. A first version of a user account whose form did not validate is not stored, and a draft, a package import, the content API's account string and a first LDAP sign-in no longer give an account a login another account has; two requests creating the same account at once end with one account.

L05 — Uploaded images are checked by their content #

For everyone. PHP's fileinfo reads the type of an uploaded image from its content, and the type must be on an allow-list. A refused file is not stored. This applies to the image datatype in the edit form, content/upload, the rich text editor's upload dialog, the AJAX uploader, WebDAV and imports; eZContentUpload refuses such a file before it creates an object.

L06 — Package thumbnails are checked the same way #

For administrators. The package wizard checks the thumbnail of a new package and the images of a style package with the same content check and allow-list as L05.

LoveStack's session SameSite setting is read too #

For administrators of sites coming from LoveStack. site.ini [Session] SameSite=, the name LoveStack uses for the SameSite attribute of the session cookie, is read when Exponential's CookieSameSite is not set (CookieSameSite wins when both are), and noted once per request at the deprecated level of the debug output. Nothing changes for visitors; rename the setting to CookieSameSite to silence the note.

Diagnostics and logging #

L07 — PHP deprecations get their own log #

For administrators and developers. PHP deprecations have a debug level of their own. They are written to var/log/deprecated.log, each distinct message once per request, and only counted: the debug bar shows their number (depr), they stay in the page's warning count, and none is kept in memory or listed with the other messages. On PHP 8 this keeps the debug output readable and its memory use low.

L08 — Log file size in site.ini #

For administrators. The size at which log files are rotated, and how many old files are kept, are settings, read by eZLog and eZDebug.

L09 — A warning for an operator parameter without a default #

For template developers. A template operator parameter that the template leaves out and the operator gives no default value for is null, with the warning Operator '<op>' has no default value for parameter '<name>', once per operator and parameter in a request (a compiled template is warned once, when it is compiled).

L10 — Edit links in the list of used templates #

For template developers. The "Edit" links in the debug output's list of used templates can point to an address of your choice, for example the template editor of the administration.

L11 — Database errors carry the driver's error number #

For developers. eZDBException::getCode() is the driver's error number of the failed statement on every driver, as errorNumber(): MySQL's number, PostgreSQL's SQLSTATE (a string), SQLite's result code, Oracle's ORA number; MongoDB keeps the server's code in errorNumber(). The "database unavailable" page (HTTP 503) also recognises the error numbers that say the connection went away or could not be made.

L12 — A warning when a change clears every view cache #

For administrators. When a change would clear the view caches of site.ini [ContentSettings] CacheThreshold nodes or more and all view caches are expired instead, a warning in the log names the number of nodes and the threshold (it was a debug message).

Content, datatypes and the administration #

L13 — Audit records for location changes #

For administrators. Location changes are events of Exponential's audit trail (channel content): content.node.add once per added location, content.node.remove with whether the removed location was the main one, and content.node.main when an editor chooses another main location or the next location takes the place of a removed main one. The audit console shows them as Location add, Location remove and Main location change. LoveStack's names location-assign, location-remove and main-node-update are mapped to these events, so eZAudit::writeAudit() calls and audit files of those names keep working.

L14 — Site data in templates and in the administration #

For developers and administrators. A template can read one row of ezsite_data by name, for names you list; Setup > Site data (setup/sitedata, policy setup/system_info) lists the rows with a filter and paging, in admin, admin3 and admin4.

L15 — A Copy button on the admin full view #

For editors. The full view of the administration (admin, admin3, admin4) has a Copy button next to Move, active with create access at the item's parent as in the context menu. It opens the same copy steps as the context menu.

L16 — Required alternative text for image fields #

For editors and administrators (accessibility). An image attribute can require an alternative text. The edit form, the online editor's upload dialog (also used by Tiptap) and the AJAX uploader of relation fields then refuse an image without one; the AJAX uploader has an alternative text field for classes with an image attribute. Packages carry the option.

L17 — Trim the stored value for text line fields #

For editors and administrators. A text line attribute can remove spaces at the start and the end of its value, in the edit form, information collection, imports and uploads.

L18 — Names made by a PHP class #

For developers. A class's object name pattern or URL alias pattern that starts with {MyResolver} is resolved by your PHP class MyResolver, when it is listed and implements expNamePatternResolverInterface. Any other name is logged and the pattern is resolved from its tokens as usual.

L19 — Class filter default for fetches #

For template developers. The class filter type the fetch functions list, tree, list_count, tree_count and calendar use when a fetch gives class_filter_array without class_filter_type.

L20 — The Locations window keeps a hidden location hidden #

For editors. In the edit form's Locations window an existing location starts at "Unchanged", not "Visible", so publishing no longer reveals a hidden location; a new location starts as it was given (EZP-26501).

L21 — Selection and matrix fields without stray line breaks #

For designers and visitors. The view templates of the selection and matrix datatypes write no stray <br />; several selected options are separated by one <br /> each.

Rich text editor #

L22 — Hidden custom tags #

For administrators and editors. Custom tags you list are not offered for new tags in the editors (TinyMCE 3, TinyMCE 8, Tiptap). Where a hidden tag is already in a text it is still shown, rendered, editable and saved back unchanged.

L23 — Custom tag controls in the rich text editor #

For editors. A focused custom tag gets a bar to move it up or down, edit it and remove it (its content stays), also with Alt+Shift+Up, Alt+Shift+Down, Alt+Shift+E and Alt+Shift+Delete; Backspace in an empty block custom tag removes it; every block custom tag shows its name as a label; a tag's dialog shows images/editor/custom_tags_thumbs/<name>.png from a design as an example. TinyMCE 3 gets the plugin exp_customtag_controls (built on TinyMCE 3's plugin API and ezjscore's jQuery, no YUI), TinyMCE 8 the buttons in its custom tag toolbar, Tiptap the same in exp_oe_tiptap 0.1.2.

L24 — The sub/sup dialog closes on OK #

For editors. The sub and sup custom tag dialog of TinyMCE 3 closes when you press OK. Exponential's tag_custom.tpl already had this fix, so nothing changed; it was checked in the browser on TinyMCE 3 and Tiptap (TinyMCE 8 has its own sub and sup buttons).

Developer APIs and settings #

L25 — eZURI::build() builds a site URL in one call #

For developers. eZURI::build( string $url, bool $full = false, bool $htmlEscape = true ) gives the same link as the ezurl template operator (index file and siteaccess in front; with $full scheme and host). Use $htmlEscape = false for a URL in a header or a JSON answer.

L26 — One message with another mail transport #

For developers. eZMailTransport::send( eZMail $mail, ?string $transportType = null ) sends one message with another transport of site.ini [MailSettings] TransportAlias[] (for example file) without changing the setting; the mail gate applies as before.

L27 — rawurlencode and rawurldecode template operators #

For template developers. RFC 3986 encoding (%20 for a space) in templates: {$value|rawurlencode}. urlencode and urldecode are unchanged. All four operators give an empty text for a value that is not set.

L28 — [Include …] inside settings files #

For administrators and developers. A line [Include site.d/*.ini] in a settings file reads other files at that place: the pattern is relative to the including file, wildcards are allowed, the files are read in name order, includes nest, a loop is read once with a warning and a pattern without a match is a notice. The included files are part of the INI cache, so php bin/php/ezcache.php --clear-tag=ini and exp:velocity deploy pick up their changes. The settings page, the classic settings editor and exp:ini keep the line as written and do not expand it.

L29 — Response headers for error pages #

For administrators. Each HTTP error page can send extra response headers, after its status lines; they are stored with the page in the view cache and sent again from it. An invalid header name or a value with a line break is left out with a warning.

L30 — The order of search results in the editors' dialogs #

For administrators. The ezjscore search (used by the editor's embed and link dialogs and the relation search) sorts eZ Find results by the search settings instead of always newest first.

L31 — Templates can tell layout views apart #

For designers and developers. Every node view sets the override key layout (empty outside layout/set, the layout of layout/set kept), so a template override can match on it again. New: eZTemplateDesignResource::setKeyValue( string $key, $value, bool $override = true ).

URLs and search #

L32 — Request addresses decoded once #

For administrators. The address of a request is decoded once instead of twice, so /(tag)/bar%2Bbar gives the view parameter bar+bar instead of bar bar. PHP-FPM and Velocity hand the kernel the same raw address and the response cache keys are made from it, so they do not change.

L33 — The double quote in IRI URL aliases #

For administrators. LoveStack's URL alias cleanup strips !, dots and separators at the end of an alias, and treats " as a reserved character. Exponential has stripped those trailing characters since 2016; what it adds is the double quote: in the IRI transformation (urlalias_iri) it becomes a separator and is stripped at the ends like the others.

L34 — Very large numbers no longer stop the search index #

For administrators. A number in a text beyond the range of the built-in search index's integer column is stored as the limit of the column instead of stopping the indexing of the object. Each driver states its range (MAX_INT, MIN_INT: signed 32-bit for MySQL, PostgreSQL and other drivers, signed 64-bit for SQLite and MongoDB), and $db->clampInteger( $value ) keeps a value within it, also one written as a float.

L35 — Relations of related objects stay out of the search index #

For administrators. The search index leaves out the relation fields of related objects, and the relation datatypes need no recursion guard. Exponential has done the same since 2018 (EZP-27101), so there is nothing to switch and no setting; a site coming from LoveStack gets the same search results.

L36 — The hide cronjob and the search index #

For administrators and developers. The hide cronjob (hide.php) tells the search engine about each node it hides (in Exponential since 2018), and the content/cache event gives its listeners ( $nodeIDs, $objectIDs ) from every sender in the kernel, now also from the node's URL aliases page; a listener that takes only the node ids keeps working.

PHP 8 review and other fixes #

LoveStack carries about forty fixes for PHP 7.2 to 8.3. Each named site was reproduced on PHP 8.5 and 8.1 as a regression test; most were already handled in Exponential (which runs on PHP 8.1 to 8.5) and stay as tests that document it. Those that still failed are fixed, for every installation, with nothing to do on an upgrade:

• the get_class and is_class template operators accept a value that is not an object without template compilation too (LoveStack e828c54709);
• wash(email) of an empty value, the classic HTML debug report, the debug bar and ezurl / eZURI of a number or of null give no "Passing null" deprecation or warning (LoveStack 4065ed16b3);
• eZHTTPTool copes with $_POST set to null (LoveStack 75cbb1daa2);
• the 5.4 update script cleanupfieldvaluerelations.php skips empty relation data, and eZPostgreSQLDB::escapeString( null ) gives '' (LoveStack 1bd250d4c6);
• a customer's orders are found from the shop's order lists, archive, customer list and dashboard when the e-mail address has a "+" (LoveStack 5a17c08bfc). A design of your own that links to shop/customerorderview can add |rawurlencode to the address in the same way.

The spell checker part of LoveStack cb8a3a1c58 was already in Exponential and is now kept by a test. Site by site, with the test of each: PHP 8 review.

Moving a site from LoveStack #

A LoveStack database is close to Exponential's. Two console commands do the work that is specific to it:

./console exp:lovestack check            # read only: what the installation brings along, and what to do with it
./console exp:lovestack migrate          # dry run: prints what it would write
./console exp:lovestack migrate --apply  # records the database as Exponential's

• check lists the database version row lovestack, LoveStack's db-schema-version row, a unique index on ezuser.login, a data_text NOT NULL DEFAULT '' column, an active legacy_2018 extension, LoveStack-only settings in settings/override, the siteaccesses and the extensions (with the Exponential name where there is one), and the mugoweb/ezpublish-legacy package in composer.json. Exit code 0: nothing to do; 1: something needs attention. --json for a machine-readable report.
• migrate sets ezsite_data ezpublish-version from lovestack to this release's version (6.0.15stable) and records LoveStack's schema version as lovestack-schema-version (LoveStack's own row stays). It then prints the settings and extensions to change by hand. It never changes content or settings, a second run changes nothing, and a database that does not come from LoveStack is refused with a message saying so.
• Tests: kernel/classes/expLoveStackCheckTest.php and kernel/classes/expLoveStackMigrateTest.php, on a LoveStack-shaped database built from Exponential's schema and LoveStack's schema steps 1 to 4. The same content operations (publishing, new versions, adding, moving and removing locations, copying, a new class attribute on a class with objects, the trash) give the same content as on an Exponential database, so LoveStack's data_text NOT NULL column and unique login index can stay as they are.

The full path, from backups to your own code: Moving a site from LoveStack, and the upgrade guide's Coming from LoveStack.

Already in Exponential #

These LoveStack features were already in Exponential, the same or in Exponential's own way:

Not brought over, and why #

Some of LoveStack's changes fit LoveStack's own way of working and were not needed in Exponential, or Exponential already solves the same problem differently. None of this is a judgement on the work; each item simply has a different answer here.

How it was tested #

Every feature above is covered in Exponential's PHPUnit suite. Each test file runs on its own, and apart from a few tests marked as needing a database (which roll back what they write), they run without one. The tests a change needs can be run alone: see run only the tests of a change. kernel/classes/expShippedFeatureDefaultsTest.php checks that an upgraded site keeps the defaults this page names.

LoveStack's own tests/ tree was compared with Exponential's too: every test case Mugo Web added or changed since the common ancestor that covers behaviour Exponential has is in the suite, rebuilt for PHPUnit and credited. The full list is in Tests, feature by feature and LoveStack's tests in Exponential's suite.

Licence and credits #

• LoveStack is licensed under the GNU GPL version 2 (its LICENSE, with the eZ Systems copyright; composer.json: GPL-2.0). Exponential is licensed under the GNU GPL version 2 or later (GPL-2.0-or-later). Mugo Web's changes are under the same GPL version 2, so they may be combined with Exponential; the parts derived from them are distributed under the terms of GPL version 2.
• Every feature on this page is treated as derived from Mugo Web's work, even where it was rebuilt rather than copied. Each file with derived code keeps every existing copyright notice and adds the line Portions derived from LoveStack (mugoweb/ezpublish-legacy, commit <sha>), Copyright (C) Mugo Web, GPL v2; the LoveStack commit is named in the commit message and in the 6.0.15 changelog.
• The custom tag controls (L23) follow the design of LoveStack's custom_tags_controls editor plugin, "Copyright 2014, Mugo Web"; that notice moves with the derived parts.
• The dual-licence wording of the original eZ Systems README can only ever be granted by eZ Systems for eZ Systems' code; it gives no rights to Mugo Web's or Exponential's code.
• "LoveStack" is Mugo Web's name for its distribution. Exponential uses it only to describe where a feature comes from; no class, setting or product in Exponential carries it, apart from the exp:lovestack command for sites moving from it. Nothing here implies that Mugo Web endorses Exponential.

Thank you to Mugo Web for years of careful work on the legacy kernel, for documenting their schema steps so precisely that a LoveStack database can be recognised and moved, and for publishing it all as open source. This page exists because of that work.

More documents #