Composer and Git on servers #

This page is for system administrators and support staff at a hosting company who install and update Exponential sites, and for product managers deciding whether customers get shell access with Composer and Git. It answers: how the code arrives, what Composer does that a plain copy does not, which install way fits which kind of plan, and which commands are dangerous on a live site. The source is chapter 3 of the installation book, Getting the code.

Contents #

1. Why Composer is part of the platform
2. What a host provides
3. Three ways to get the code
4. Versions and tags
5. Extensions are packages
6. Updating safely
7. Updates from the administration
8. Checklist
9. Related pages

Why Composer is part of the platform #

Exponential installs with Composer 2. Composer downloads the kernel's libraries (the expcomponents, se7enxweb/expcomponents-*, the fork of the Zeta Components), every extension composer.json requires and, when asked, Velocity. Without it, vendor/ is missing and the site cannot start. After composer install, the script legacy-scripts runs php bin/php/ezpgenerateautoloads.php, which generates the class maps (chapter 2.7).

What a host provides #

On servers with several PHP versions, run Composer with the site's PHP, for example /opt/plesk/php/8.5/bin/php /usr/local/bin/composer install (adjust both paths to your server).

Three ways to get the code #

From chapter 3.2:

For way A, tell Composer once per user account to install se7enxweb/* packages as clones:

composer config --global 'preferred-install.se7enxweb/*' source
git clone https://github.com/se7enxweb/exponential.git
cd exponential
composer install

For way B on a production server, add --no-dev, which leaves out the test tools:

composer create-project se7enxweb/exponential:v6.0.14 exponential --no-dev

Versions and tags #

• Exponential is published as the Composer package se7enxweb/exponential from github.com/se7enxweb/exponential. Release tags are v6.0.0 and later in the 6.0 line; main carries the current development.

• A release tag never changes. A fix always arrives as the next version, so a pinned version gives the same files every time: the right choice for production.

• Sort versions by version, never by name: by name v6.0.10 sorts before v6.0.8.

  git tag -l 'v*' --sort=version:refname | tail -5

Extensions are packages #

Every extension except the four shipped in the kernel repository (ezjscore, ezoe, ezformtoken, expservices) is a Composer package that the installer plugin places in extension/<name>. So composer.json decides which extensions an installation has and their versions (chapter 3.5).

Adding one is three steps:

composer require se7enxweb/ezfind
php bin/php/ezpgenerateautoloads.php -e
php bin/php/ezcache.php --clear-tag=ini

and activating it in [ExtensionSettings] ActiveExtensions[] (in the administration under Setup > Extensions, or in settings/override/site.ini.append.php); restart Velocity if it serves the site.

The suggest block of composer.json lists optional extensions a host may want to offer as add-ons, among them ezfind (Solr search), sevenx_valkey_cache (cache on Valkey or Redis), ezscriptmonitor and hcaptcha.

Updating safely #

• Clones that Composer made itself are safe: Composer refuses to update a clone with uncommitted changes or unpushed commits (When Composer refuses).
• A clone made by hand in place of a package Composer installed as an archive is not safe: Composer still treats the folder as an archive and replaces it, history and commits included. Use composer reinstall <package> after setting preferred-install instead.
• Moving the code is half of an upgrade; the database update files are the other half (chapter 11).
• Back up before every update (What to back up).

A safe update of a clone-based site:

git fetch origin --tags
git merge v6.0.<n>                 # or origin/main
composer install

Updates from the administration #

The ezupdate extension, required by composer.json, is a package manager in the administration (Setup > Updates and packages) and on the command line. Updating and installing are off until switched on in settings/override/ezupdate.ini.append.php ([UpdateSettings] AllowUpdate, AllowInstall), because Composer rewrites vendor/ and every package it manages (ezupdate).

For a host this is a policy decision per plan: leave it off where the host manages updates, or switch it on for customers who manage their own. See Automated updates with ezupdate.

Checklist #

• To do: Composer 2, current, available to the site's user.
• To do: Composer runs with the site's PHP version.
• To do: Outbound HTTPS to Packagist and GitHub allowed.
• To do: Production installs use --no-dev.
• To do: Customer sites pinned to release tags unless they follow main on purpose.
• To do: No casual composer update on live sites; a backup before every update.
• To do: A policy per plan for ezupdate's AllowUpdate and AllowInstall.

Related pages #

• Chapter 3: Getting the code
• Develop with Git
• Upgrading customer sites and Deploying changes
• Extensions guide
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.