How the setup wizard uses packages #

This page is for administrators who run the web setup wizard and for developers who need to know what it does with packages behind the screens. It answers: where the list of site packages comes from, what is downloaded and when, where it goes, and how the chosen package becomes a site. The screens themselves, with every message, are described in The setup wizard; this page follows the packages.

Contents #

1. The steps that touch packages
2. Site types: building the list
3. Site types: choosing a package
4. Site types: uploading a package
5. Package language options
6. Create sites
7. Where the files go
8. When something fails
9. Related pages

The steps that touch packages #

The wizard's steps are listed in kernel/setup/steps/ezstep_data.php (StepTable). Three of them work with packages:

Site types: building the list #

When the step is built, it works out the index address from settings/package.ini:

[RepositorySettings]
RemotePackagesIndexURL=https://exponential.packages.exponential.earth/exponential/6.0/6.0.15
RemotePackagesIndexURLBase=https://exponential.packages.exponential.earth/exponential

RemotePackagesIndexURL is used when it is not empty; otherwise the base plus /<major.minor>/<full version>/. The step appends index.xml. Then, on every display:

1. Remote list. Download index.xml into the cache directory's packages/ folder (with the retries of DownloadAttempts and DownloadRetryDelays[], see Package server settings), parse it, delete the copy, and keep the entries whose type is site. If the download fails, use index.xml from the system repository (var/storage/packages/<Vendor>/index.xml, Vendor=7x) when there is one. From 6.0.15 on the index of every further package server follows, adding the packages the earlier ones do not list (Further package servers).
2. Local list. Every package of type site already in the local repository, in any vendor directory.
3. Status of requirements. For each local site package, each <require> is marked imported when a package of that name exists with a version that meets its min-version.
4. Merge. One entry per name. A local package wins, unless the remote entry's version compares higher (eZPackageVersion::compareFull()). An entry without a download URL counts as imported.
5. Preselect the first imported site package, so Next installs it without a download.

The page also shows the index address ("Remote repository URL") so you can see which server is used.

Site types: choosing a package #

The radio button posts eZSetup_site_type: the plain name for an imported package, name|url for a remote one. On Next (eZStepSiteTypes::processPostData()):

Then, in both cases, downloadDependantPackages() checks every <require> of the site package: kept when imported and new enough, otherwise removed and downloaded again from the URL the index gives. The rules are in Dependencies and install order. Only after all requirements are in does the wizard go on.

Site types: uploading a package #

The Upload package field (PackageBinaryFile, button UploadPackageButton) imports an .ezpkg from your computer with eZPackage::import() and shows the same page again, now with the package in the local list. This is how you install a site package that is not on the package server, or install without network access. A package that is already imported is not imported again (a warning is logged); anything that is not a package gives "Uploaded file is not an Exponential package". The archive is checked as described in The .ezpkg file.

Package language options #

The step reads the languages of the content classes and objects in the packages the site package requires (eZPackage::languageInfoFromPackageList()) and compares them with the languages you chose. Only when packages carry other languages does it ask what to do with them (create, map to a site language, or skip). The answer is kept as the language_map that the Create sites step passes to each package's install.

Create sites #

The step that writes the site. For packages it:

1. Fetches the chosen site package from the repository (EZSW-041 "Could not fetch site package" when it cannot).
2. Includes the site package's install scripts and calls eZSitePreInstall() (Install scripts in a site package).
3. Logs in the administrator (user 14), so the content is created by that user.
4. For every <require type="ezpackage"> of the site package, in order: fetches it (EZSW-050 when missing) and, when its install_type is install, installs it non-interactively with the site's siteaccess, design, top node 2 and language map (EZSW-051 when it fails).
5. Builds the settings and roles with the INI, role and preference hooks, and calls eZSitePostInstall().

The site package itself is never installed: it is install_type="import" and has no items.

Where the files go #

When something fails #

Related pages #

• Site package basics
• Site packages: start here
• The setup wizard, 5.3.8 Site package
• How the kickstarter and the console use packages
• Downloading a package by hand
• Contribute your site package: a package accepted on the shared server appears in every wizard's list.
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.