Help for Developers

What changed in the source code most recently: the main branch of se7enxweb/exponential, read from its public feed by this server.

Hide merge commits

1. Merge pull request #362 from vmeyke/tests/migration-runner-db (opens in a new window) se7enxweb · 11/11/2026 12:01 pm

   Message

   Merge pull request #362 from vmeyke/tests/migration-runner-db
   
   Updated: The migration runner tests forget the class ids of their own database

   d03bf01533
2. Updated: The 6.0.15 changelog names that class ids follow the database (opens in a new window) · 11/11/2026 11:42 am

   Message

   Updated: The 6.0.15 changelog names that class ids follow the database
   
   - Updated: doc/changelogs/6.0/6.0.15.md and share/filelist.md5.

   9ec3d5706a
3. Updated: The migration runner tests check that class ids follow the g… (opens in a new window) · 11/11/2026 11:42 am

   Message

   Updated: The migration runner tests check that class ids follow the global database
   
   - Added: RS-6 in expMigrationRunnerSqliteTest: switched to a second SQLite database, a class and a class attribute only
     the first one has are unknown, and known again after switching back, without expireCache(). It fails without the
     kernel change of the class id caches.
   - Updated: RS-5 checks the class attribute ids too, in the process, so it needs no installation database.
   - Updated: eZContentAccessForAnotherUserTest gives its empty class identifier hash the name of its database handler
     (and puts both back), so the class id cache does not read the ids again from a handler that runs nothing.
   - Updated: share/filelist.md5.

   6b50c5001b
4. Updated: Class and class attribute ids by identifier follow the globa… (opens in a new window) · 11/11/2026 11:40 am

   Message

   Updated: Class and class attribute ids by identifier follow the global database
   
   eZContentClass and eZContentClassAttribute keep the ids by identifier they read in a static for the whole process. A
   process that switched its global database (eZDB::setInstance(), as a script or the migration runner tests do) kept
   those of the first database: a later class filter used its ids, or missed a class it never had. In a full test run
   the hide cronjob hid nothing and the forum, product and comment services found nothing.
   
   - Updated: classIdentifiersHash() and classAttributeIdentifiersHash() remember the name of the database they were
     read from and read the ids again when the global database is another one. The file caches were already kept per
     database; nothing changes while the database stays the same.
   - Updated: share/filelist.md5.

   194d9ea6bb
5. Updated: The migration runner tests forget the class ids of their own… (opens in a new window) vmeyke · 11/11/2026 11:21 am

   Message

   Updated: The migration runner tests forget the class ids of their own database
   
   runnerEnd() switched back to the installation's database but kept the class ids by identifier the process had read
   from the test's database (eZContentClass keeps them in a static hash for the whole process). A later class filter of
   the same process then used the ids of that database, or missed a class it never had: in a full run the hide cronjob
   hid nothing, and the forum, product and comment services found nothing.
   
   - Updated: runnerEnd() expires the class identifier cache (eZContentClass::expireCache()).
   - Added: RS-5 in expMigrationRunnerSqliteTest: the class ids read while the test's database is the global one are in
     memory, and forgotten after runnerEnd(). The check reads the in-memory hash, as a run without a database (the
     PHPUnit job) has no database to ask afterwards. Without the change it fails.
   - Updated: eZContentAccessForAnotherUserTest gives the checks an empty class identifier hash and an empty content
     language list for the test and puts them back afterwards. Its database handler runs nothing, so read from it they
     gave "foreach() argument must be of type array|object" warnings; it only passed in a full run because an earlier
     test (a migration test) had left its own class ids in memory, which this change now forgets.
   - Updated: share/filelist.md5.

   7c2cf6f09e
6. Merge pull request #361 from vmeyke/tests/velocity-warmup-ini-cache (opens in a new window) se7enxweb · 11/11/2026 11:06 am

   Message

   Merge pull request #361 from vmeyke/tests/velocity-warmup-ini-cache
   
   Updated: The velocity warm-up test leaves the installation's INI cache alone

   0c1f889ba8
7. Updated: The Velocity warm-up test checks that the warm-up writes not… (opens in a new window) · 11/11/2026 10:19 am

   Message

   Updated: The Velocity warm-up test checks that the warm-up writes nothing into its root and removes all of it
   
   The test switches the INI cache off while the warm-up runs. It now also checks that the warm-up wrote nothing next to
   autoload.php and var/maintenance.json in its temporary root: an INI cache saved during the run logs itself to
   var/log/storage.log there, so the check fails as soon as the warm-up uses the INI cache again. Before, that file kept
   the temporary root on disk, as the clean-up removed only the files the test had made; it now removes everything below
   the root, also after a failed run.
   
   - Updated: tests/tests/kernel/classes/expVelocityEnginesTest.php and share/filelist.md5.

   d7cc3883db
8. Updated: eZINI gives settings read from another working directory a c… (opens in a new window) · 11/11/2026 10:18 am

   Message

   Updated: eZINI gives settings read from another working directory a cache file of their own
   
   eZINI reads the base files and keeps its cache below the installation root, but reads the override directories
   (settings/override, the siteaccess and extension directories) relative to the working directory. A process working
   elsewhere read other files under the cache file name every process of the installation uses: the Velocity warm-up
   test, run in a temporary root without settings, stored a site.ini without settings/override, and the site, the
   administration and every script read that until the INI cache was cleared.
   
   - Updated: eZINI::cacheFileName() adds the place the override directories resolve to when that is not the
     installation's own (eZINI::workingSettingsDirectory()). A directory that resolves to the installation's own, through
     a symbolic link for example, counts as the same; the usual cache file names do not change.
   - Added: eZINIWorkingDirectoryTest, which fails without the change (the cache written elsewhere was read in the root).
   - Updated: The configuration guide names the case in its troubleshooting table, in English and German.
   - Updated: The 6.0.15 changelog and share/filelist.md5.

   ecba3bb12f
9. Updated: The velocity warm-up test leaves the installation's INI cach… (opens in a new window) vmeyke · 11/11/2026 09:29 am

   Message

   Updated: The velocity warm-up test leaves the installation's INI cache alone
   
   expVelocityEnginesTest runs bin/php/velocity-warmup.php in a temporary root without settings. eZINI found none of the
   override directories there, but stored what it read in the installation's var/cache/ini (eZINI keeps its cache below
   the installation root, whatever the working directory) under the name every process uses. Every later process (the
   site, the admin, the ezoe view helper) then read a site.ini built from settings/site.ini alone, without
   settings/override, the siteaccess settings and the extensions: the ezoe module was not found and the front page ended
   with an error, until the INI cache was cleared.
   
   - Updated: The test switches the INI cache off while the warm-up runs and back on afterwards.
   - Updated: share/filelist.md5.

   7fa1e2457e
10. Updated: The hide cronjob puts ShowHiddenNodes back when it ends and … (opens in a new window) · 11/10/2026 05:50 pm

    Message

    Updated: The hide cronjob puts ShowHiddenNodes back when it ends and skips a root node that does not exist
    
    Follow-up of pull request #360 (the hide cronjob ends also when the process fetched nodes with
    ShowHiddenNodes=true before it).
    
    - Updated: The hide cronjob sets ShowHiddenNodes=false only while it hides: when it ends, also after an error, the
      setting and the cached value of eZContentObjectTreeNode::showInvisibleNodes() are as before, so the cronjob parts
      after it in the same process (a site's own or an extension's) see hidden nodes as the site has them. With the
      cache reset of #360 alone they would all have run with ShowHiddenNodes=false.
    - Updated: A node of content.ini [HideSettings] RootNodeList that does not exist is skipped with a warning; it
      stopped the whole cron run with a fatal error before.
    - Updated: HideCronjobSearchIndexTest runs on a clean installation too, as the throwaway database of a test run:
      when no class has a date or integer attribute, it creates one inside its rolled-back transaction. Before, it was
      always skipped there.
    - Updated: HideCronjobSearchIndexTest pushes its error handler marker only when eZDebug's handler is not on top
      already. eZDebug takes the handler on top off as its own, so with its handler on top (the kernel started before
      the test) the marker was taken off in its place and the test left one handler too many (risky).
    - Added: HC-04 (the setting is as before after the cronjob) and HC-05 (a root node that does not exist is skipped).
    - Updated: phpstan-baseline.neon: hide.php has 1 known "undefined variable $cli" instead of 7, as the hiding moved into a
      method that takes $cli as a parameter.

    546bf41b09