Updating PicoCMS with Composer

Table of Contents

How it works
Problem with more than one PHP version installed
Staging/Production

How it works ∆

composer is installed locally on the server (Debian oldstable) via apt.
All I had to do is

navigate to the folder including the PicoCMS installation

execute composer update

$ composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Removing symfony/polyfill-ctype (v1.12.0)
  - Installing symfony/polyfill-ctype (v1.15.0)
    Downloading: 100%         

  - Removing twig/twig (v1.36.0)
  - Installing twig/twig (v1.42.5)
    Downloading: 100%         

  - Removing picocms/pico (v2.1.0)
  - Installing picocms/pico (v2.1.1)
    Downloading: 100%         

  - Removing picocms/pico-theme (v2.1.0)
  - Installing picocms/pico-theme (v2.1.1)
    Downloading: 100%         

  - Removing picocms/pico-deprecated (v2.1.0)
  - Installing picocms/pico-deprecated (v2.1.1)
    Downloading: 100%         

Writing lock file
Generating autoload files
> Pico\Composer\Installer\PluginInstaller::postAutoloadDump
Updating Pico plugins file

That's all (same procedure for subsequent updates).

Problem with more than one PHP version installed ∆

For some reason, I had both PHP 7.0 and 7.3 installed on my Debian stable server (dist-upgraded to buster). A composer upgrade did not throw an error, but the CMS stopped working after that (blank page, no obvious error messages anywhere). It would seem that composer defaults to the highest PHP version installed and to the highest versions of dependencies compatible with that, instead of the lowest.

Uninstalling either of the PHP versions was enough to fix the problem.

Strangely, installing from the release tarball does not have these problems. It would seem that composer is not capable of recognizing the best solution when different PHP versions are installed. Or, if I had to guess, composer defaults to the highest PHP version, but I still had a lower PHP version in my server config, resulting in incompatibilities. Could the composer config file (I guess that's composer.json) be fine-tuned to use the same defaults as the release? My guess is that the lowest common denominator would be safer than the highest (backward compatibility more likely than forward compatibility).

Staging/Production ∆

It's advisable to have two separate sites, one for testing (staging), one that is actually seen by visitors (production). Now that the staging site is updated and working, one can copy the whole folder structure over to production. One could also delete a whole slew of files not required.