Composer upgrade 2.1.2 => 2.1.3 results in broken CMS, HTTP 500 error

[ohnonot]

Earlier I have used composer at least once to succesfully upgrade pico.

Now I'm getting this error when I visit my blog. Completely blank page, no code in "View source" either. I can't see anything in /var/log/nginx/error.log, /var/log/php7.0-fpm.log or /var/log/syslog or in the respective service's systemd status. I do see the access in /var/log/nginx/access.log: X.X.X.X - luser [01/Aug/2020:17:35:02 +0300] "GET / HTTP/1.1" 500 5 "-" "Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0" But that's all. I removed the server root dirctory and "composed" a completely new instance of pico, and it gives me the same error. I emptied composer's cache. I tried this twice, with composer 1.8.4 installed on my system (Debian stable) and composer downloaded straight from their site. I checked nginx' settings as per http://picocms.org/docs/#nginx, it needed a little adjustment but really I don't think they changed at all since the last version?

What changed between now and then? IDK; a few OS upgrades, editing my custom theme.

Just to prove that the server is serving, I can replace the webroot directory and place a single index.php in it which shows me phpinfo(); - it works. This is the staging version of my blog; all the while the production version, which is still at 2.1.2, works normally.

This is what composer (newest version) told me:

$> php composer.phar --verbose create-project picocms/pico-composer staging
Creating a "picocms/pico-composer" project at "./staging"
Installing picocms/pico-composer (v2.1)
  - Installing picocms/pico-composer (v2.1): Downloading (100%)         
 Extracting archiveCreated project in /var/www/html/staging
Loading composer repositories with package information
Updating dependencies (including require-dev)
Dependency resolution completed in 0.023 seconds
Analyzed 2272 packages to resolve dependencies
Analyzed 1969 rules to resolve dependencies
Package operations: 9 installs, 0 updates, 0 removals
Installs: picocms/composer-installer:v1.0.1, erusev/parsedown:1.8.0-beta-7, erusev/parsedown-extra:0.8.0-beta-1, symfony/polyfill-ctype:v1.18.0, symfony/yaml:v2.8.52, twig/twig:v1.43.0, picocms/pico:v2.1.3, picocms/pico-deprecated:v2.1.3, picocms/pico-theme:v2.1.3
  - Installing picocms/composer-installer (v1.0.1): Downloading (100%)         
 Extracting archive  - Installing erusev/parsedown (1.8.0-beta-7): Downloading (100%)         
 Extracting archive  - Installing erusev/parsedown-extra (0.8.0-beta-1): Downloading (100%)         
 Extracting archive  - Installing symfony/polyfill-ctype (v1.18.0): Downloading (100%)         
 Extracting archive  - Installing symfony/yaml (v2.8.52): Downloading (100%)         
 Extracting archive  - Installing twig/twig (v1.43.0): Downloading (100%)         
 Extracting archive  - Installing picocms/pico (v2.1.3): Downloading (100%)         
 Extracting archive  - Installing picocms/pico-deprecated (v2.1.3): Downloading (100%)         
 Extracting archive  - Installing picocms/pico-theme (v2.1.3): Downloading (100%)         
 Extracting archiveWriting lock file
Generating autoload files
> post-autoload-dump: Pico\Composer\Installer\PluginInstaller::postAutoloadDump
Creating Pico plugins file
3 packages you are using are looking for funding.
Use the `composer fund` command to find out more!

I don't see any problem there.

To clarify: The webroot is ./staging. This results in a non-working pico CMS, with a generic 500 a.k.a. "Internal Server Error". Using the installed version of composer also results in a non-working pico CMS. This is a new install - but the same happened when I updated my current staging site.

But then: I downloaded the release tarball, extracted it to the webroot, and It Worked! What is going on? :o

I would prefer the composer method for easier upgrading, keeping configurations intact etc.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two days if no further activity occurs. Thank you for your contributions! :+1:

[ohnonot]

Thank you for removing the "stale" label. Yes, this is still very moch Not Solved.

[PhrozenByte]

Sorry for the late response. A blank page indicates a PHP error. Check your webserver config, it looks like your PHP error log isn't configured properly. See e.g. https://stackoverflow.com/questions/8677493/php-fpm-doesnt-write-to-error-log. You can also set display_errors = 1 in your php.ini temporarily, it should show the error message then

Since Pico doesn't lock the versions of its dependencies, I'd assume that there's some incompatibility between one of the dependencies and your PHP version. Since Pico's release packages are working for you, I'd recommend simply using a release package. It makes no difference, a release package is exactly the same as a Composer-based install. You can try running composer update on a release package, but I'd assume that it stops working again, because the dependencies are upgraded to the same versions as if you created a Composer-based install from the beginning.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two days if no further activity occurs. Thank you for your contributions! :+1:

[ohnonot]

It was surprisingly difficult to enable logging for PHP. Or maybe I was looking in all the wrong places. Is it only me, or is PHP just too complex?

But I noticed that I had 2 PHP versions installed - PHP7.0 and PHP7.3. Since all my nginx sites are already configured to use PHP7.0 I just uninstalled 7.3. Ran composer update again - surprise, it actually downgraded twig (v1.43.0 => v1.42.5). Now everything is working. Phew.

Update

I have since changed PHP versions again, using 7.3 and uninstalled 7.0. This works just as well (meanwhile updated again to 2.1.4), so 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.

It's strange that installing from the release tarball does not have these problems; 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).