Making your own site package
This section is for developers, designers, agencies and hosts who want new Exponential installations to start from
their own site: their own content classes, demo content, settings, roles and design, chosen in the setup wizard or
named in kickstart.ini like the 7x packages are. It answers: where to start, what you change, how the archives are
built, where they are published, and how an installation finds them.
7x and the Exponential Foundation strongly encourage you to submit your site package by pull request to se7enxweb/exponential.packages.exponential.earth: an accepted package becomes available through the default distribution system, the setup wizard, the kickstarter and ezupdate, on every installation. How to do that is on Contribute your site package.
Contents
- The path in short
- The pages of this section
- What you need before you start
- Two ways to share the result
The path in short
A site package is an ordinary Exponential package of type site whose package.xml names the packages it requires
and the PHP files the installer runs at fixed points of the CreateSites step
(What a site installer package is). Making your own one is mostly
copying a working one and changing it:
fork a source repository sevenx-ezpackage or cjw_multisite-ezpackage, packages/<name>/ per package
-> rename and edit package.xml, the installer script, the content classes and the demo content
-> rebuild the archives packages/build.sh: one <name>.ezpkg per package folder
-> publish a static HTTPS folder with index.xml, the .ezpkg files and thumbnails/
-> point an installation package.ini [RepositorySettings] RemotePackagesIndexURL, kickstart.ini Site_package
-> test in a sandbox exp:install --dry-run, then a throwaway installThe 7x site packages were made exactly this way. cjw_multisite, published with release 6.0.15, is a fork of
sevenx_multisite: it keeps sevenx_classes as a requirement, brings its own demo content package
(cjw_multisite_democontent) and its own installer class (cjwMultiSiteInstaller in
settings/cjw-multi-site-installer.php), and lives in its own repository,
se7enxweb/cjw_multisite-ezpackage, "laid out as the 7x package
repository" (its first commit, 7 October 2026).
The pages of this section
| Page | What it answers |
|---|---|
| Forking a site package | Which package to start from, what to rename, which names must be unique |
| Changing the installer script | The hook functions, the installer class, its steps, the extension tables it seeds |
| Changing classes and content | The class and object files, editing them, exporting them from a test site, remote IDs |
| Rebuilding with build.sh | How the 7x archives are built, what is left out, how to check the result |
| Creating packages with the wizard | Class, content, extension and site style packages from the administration |
| Creating packages with ezpm | The same from a shell, scriptable |
| Versioning your own packages | <version>, min-version, the index version, release folders |
| Running your own package server | The folder layout, index.xml, GitHub Pages or any HTTPS server |
| Pointing a site at your package server | package.ini override, kickstart.ini, exp:install, ezupdate |
| Testing in a sandbox | Dry runs, a throwaway install, what to check, cleaning up |
What you need before you start
- To do: An Exponential 6.0 installation you can throw away (a separate checkout with SQLite is enough), never the production site: the installer writes the database and the settings.
- To do: git and a GitHub account (or any git host) for the source repository of your packages.
- To do: A shell with
tarandgzip;xmllinthelps to check XML files. - To do: For publishing: a place that serves static files over HTTPS (GitHub Pages works, as the 7x server shows).
- To do: A license decision for the code, the documentation and the demo images (Licensing choices).
Note
The installer reads site packages; it does not care how they were made. Everything in this section works the same
whether you build the archives with build.sh, with ezpm or by hand, as long as each archive passes the checks
of Validating a package before publishing.
Two ways to share the result
| Way | Who gets it | What you run |
|---|---|---|
| Pull request to the 7x package server | every installation, in its setup wizard, kickstarter and ezupdate, with no settings changed | your packages are reviewed and published with the next release folder (Contribute your site package) |
| Your own package server | installations whose package.ini points at your server, or that add it in ezupdate | a static HTTPS folder you keep up to date (Running your own package server) |
Both can be combined: test on your own server, then send the pull request.
Tip
Start from the requirements checklist (The requirements checklist) so the package is ready for review from its first version, and keep a changelog from the first commit.
Related pages
- Site packages: start here
- Contribute your site package
- Site packages glossary
- How the setup wizard uses packages
- sevenx_multisite and cjw_multisite
- Packages in the administration
- 4.3 Site packages
- Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.
Become an Exponential Partner
Partners share their information, provide funding, contribute back and develop the products with us, and that is how Exponential grows. A partner website and dashboard are planned for mid-2027: please become a partner today to speed up our growth rate and land new features faster.