1.7.x-fpm image seems to use wrong base `php:8.4-fpm`

[matwey]

Hello,

I see that the fpm image is currently based on php:8.4-fpm:

roundcubemail-docker/fpm/Dockerfile

Line 1 in 0bf9876

FROM php:8.4-fpm AS root

While Roundcube 1.7.0 seems to use php 8.5 features such as array_last:
https://github.com/roundcube/roundcubemail/blob/26b96793cb301de448a8bd67956ae3cfc6c0ccc1/program/include/rcmail_output_html.php#L343

Currently, I see the following with 1.7.0-fpm roundcube docker image:

NOTICE: PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function array_last() in /var/www/html/program/include/rcmail_output_html.php:343
172.18.0.1 -  20/May/2026:11:31:27 +0000 "GET /index.php" 500
Stack trace:
#0 /var/www/html/program/include/rcmail_output_html.php(298): rcmail_output_html->load_skin()
#1 /var/www/html/program/include/rcmail_output_html.php(112): rcmail_output_html->set_skin()
#2 /var/www/html/program/include/rcmail_output_html.php(81): rcmail_output_html->init()
#3 /var/www/html/program/include/rcmail.php(589): rcmail_output_html->__construct()
#4 /var/www/html/program/include/rcmail.php(147): rcmail->load_gui()
#5 /var/www/html/program/include/rcmail.php(89): rcmail->startup()
#6 /var/www/html/public_html/index.php(43): rcmail::get_instance()
#7 {main}
  thrown in /var/www/html/program/include/rcmail_output_html.php on line 343

[pabzm]

Roundcube has symfony/polyfill-php85 as dependency. Your error messages suggest that this dependency is not installed.

Do you use a volume for the application source code?

Can you check if symfony/polyfill-php85 is contained in composer.lock?

[matwey]

Indeed, polyfill-php85 presents in composer.json and composer.json-dist but not in a composer.lock. However the latter is not empty. How could it happen?

[pabzm]

I guess you have the code in a volume mounted to /var/www/html?

The container entrypoint script runs only composer install, not composer update, so after an update with changes to composer.json currently requires a manual step: docker exec -it $containerId composer --prefer-dist --no-dev --no-interaction --optimize-autoloader update.

Alternatively remove the file composer.lock and restart the container, that should work as well.

We discussed previously to change the call to composer to run update, but somehow didn't come to a clonclusion.

[pabzm]

I remember why we didn't change the call to composer: because if it would run composer update, then each container start would potentially pull in new dependencies. This is arguably a breaking change in behaviour, which we didn't want to introduce lightheartedly.

Frankly, I'm still unsure how to handle this, and am interested in opinions.

[pabzm]

#425 will remove the bind-mounts from the examples to stop suggesting this would be necessary or generally a good idea.

[liayn]

I would actually refrain from running any composer command during runtime.
Most of our PHP software usually "builds" the source during image build time, hence running the composer update there and only copies the artefacts over to the target image. (keywords: multi-step build, vendor folder)
So package updates can only happen when rolling out a new image.

[pabzm]

In principle I agree, but since the images even suggested to mount the source code into them, calling composer was necessary, and I want to avoid breaking changes (at least until there's a proper versioning scheme for the images, which would allow people to not run into breaking changes without a chance to know it), so I won't remove it (now).

Also the images allow to specify plugins and skins that should be installed on startup, which both require running composer, too. But I guess that's a slightly different case, since the admins explicitly declared to want additional code running.

[liayn]

Also the images allow to specify plugins and skins that should be installed on startup, which both require running composer, too. But I guess that's a slightly different case, since the admins explicitly declared to want additional code running.

This should also happen in a derived Dockerfile during one's custom build.

But as long as roundcube itself does not properly separate concerns (code, assets, configuration) this is close to impossible to do it "right" in the docker image.
(/me thinking of my open issues regarding configuration handling)

[pabzm]

@matwey Is your concrete problem solved?