Changing the installer script #

This page is for developers who change what a site package does when it is installed: which extensions it switches on, which settings and siteaccesses it writes, which roles it creates and which repairs run after the content is in place. It explains how the kernel calls the package's PHP files and how the 7x installer class is built, so you can change a fork without breaking the chain.

7x and the Exponential Foundation strongly encourage you to share the finished package by pull request to se7enxweb/exponential.packages.exponential.earth: see Contribute your site package.

Contents #

1. How the files are loaded
2. The hook functions
3. The installer class
4. Post-install steps
5. Extensions and their tables
6. Making a change

How the files are loaded #

package.xml lists the installer files in <settings>:

<settings>
  <settings-file filename='ini-site.php'/>
  <settings-file filename='sevenx-multi-site-installer.php'/>
  <settings-file filename='install-scripts.php'/>
  ...
</settings>

During CreateSites, kernel/setup/steps/ezstep_create_sites.php reads the site package's settings-files and runs include_once( <package path>/settings/<file> ) for each file that exists. Nothing else in a file runs by itself: the kernel then calls the hook functions below when they are defined (function_exists()). The same happens whichever front end started the install: the setup wizard, the kickstarter or exp:install (Install scripts in a site package).

The hook functions #

In the order ezstep_create_sites.php reaches them:

Each 7x hook file is a few lines that create the installer and return one of its methods:

function eZSiteINISettings( $parameters )
{
    $installer = new sevenxMultiSiteInstaller( $parameters );

    return $installer->siteINISettings();
}

The installer class #

settings/sevenx-multi-site-installer.php defines class sevenxMultiSiteInstaller extends eZSiteInstaller (kernel/classes/ezsiteinstaller.php). Its parts:

The class file also loads post-install-fix.php with require_once (repairs shared by the installer); a fork keeps that line pointing at its own copy.

Post-install steps #

initSteps() describes the post-install as a list; eZSiteInstaller::postInstall() runs it with executeSteps():

$postInstallSteps = array(
    array( '_function' => 'dbBegin', '_params' => array() ),
    array( '_function' => 'setVersion', '_params' => array() ),
    array( '_function' => 'postInstallFixContentObjectNameLanguages', '_params' => array() ),
    // ...
);
$this->Steps['post_install'] = $postInstallSteps;

Each _function is a method of the installer (yours or one eZSiteInstaller provides) called with _params. When a step reports an error and the error handler answers ERR_ABORT, the rest of the list is skipped and the step is kept in eZSiteInstaller::abortedStep() (number, function, count), so the setup knows the post-install did not finish. The 7x list runs its repairs early for that reason: a comment in initSteps() notes that "executeSteps aborts the chain on the first step that reports an error, and several later steps are fragile".

Extensions and their tables #

Some data a site needs is not content and is not in any package. The 7x installer creates the tables of the extensions it activates and seeds some of them from the extensions' own files: declaredExtensionSchemas() names sevenx_themes_media (schema and data: the layouts, tags and ratings of the demo content), explayouts (schema and data), and the schemas of ezstarrating, ezgmaplocation, eztags, enhancedselection2, cjw_newsletter and syndication; extensionSchemas() adds every other listed extension that ships share/db_schema.dba or sql/<engine>/schema.sql. The details are on Layouts data and share .dba files.

For your fork this means: a layout or tag you want in a new installation goes into the share/db_data.dba of the extension that owns it, not into the site package.

Making a change #

1. Change the method or add a step in your renamed installer class.
2. Check the syntax: php -l packages/<name>/settings/<your-installer>.php.
3. Rebuild the archive (Rebuilding with build.sh).
4. Install it in a sandbox and read var/log/setup.log (Testing in a sandbox).
5. Write the change in the package's <changelog> and the repository's changelog.

The 7x repository shows the commit style for such changes, for example "Updated: The sevenx_multisite package's installer activates ezownerchange" (15 October 2026).

Related pages #

• Making your own site package
• Contribute your site package
• The multisite installer script
• Post-install fixes
• The CJW installer scripts
• Package install scripts
• Site packages: start here
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.