Clarify PHP module bundling for PHP 8.3 and 8.4

[skjnldsv]

Summary

Clarifies PHP module bundling behavior in PHP 8.3 and 8.4 to help users troubleshoot installation issues.

Problem

When deploying Nextcloud on PHP 8.4, users encounter "module not found" errors when trying to install modules that are already bundled with the PHP package. The documentation doesn't clarify that certain modules are bundled by default in newer PHP versions, leading to confusion and wasted troubleshooting time.

Solution

Added version-specific notes to the PHP configuration documentation explaining:

1. Which PHP versions bundle commonly used modules (curl, zlib, etc.)
2. How to verify if a module is already enabled using the provided check command
3. Distribution-specific guidance (Debian/Ubuntu packages may have different module availability)

Changes

• Updated admin_manual/installation/php_configuration.rst
• Added note in "Required PHP Modules" section explaining bundled modules in PHP 8.3+
• Updated sodium module documentation to clarify it's typically bundled in PHP 8.4

Relates to

#14036

[github-actions]

📖 Documentation Preview

🔍 Open preview →

📄 1 changed documentation page

• admin_manual/installation/php_configuration.rst

Last updated: Thu, 07 May 2026 09:28:19 GMT

[sproggit]

Very helpful. I think the biggest challenge here is that different distributions/platforms may elect to bundle PHP in different ways... The Raspberry Pi machines I use for this use Debian-based software, so PHP is broken down in to discrete packages... that division of content may be different on other Linux flavours, never mind other OS platforms.

I think this might be something that would benefit from crowd-sourcing - so users can share what they've learned in their own attempts.

[skjnldsv]

Yes, I agree. It's also quite hard to document such changes as it's easy to become out-of-date.
I think the incentive to check your own distro php modules is a good approach.

[sproggit]

Yes, I agree. It's also quite hard to document such changes as it's easy to become out-of-date. I think the incentive to check your own distro php modules is a good approach.

500%

The experience that prompted me to raise this suggestion related to ImageMagick... I had a prompt in my Nextcloud Admin panels to tell me that I was missing some ImageMagick-related code... I went looking, using the Raspberry Pi's native "Add/Remove Software" GUI-based application - which has some useful text search features built in... but I was unable to identify any package not already installed that would solve that dependency issue.

It was only by random luck that I happened to come across a Reddit thread where someone had very kindly posted a solution that worked on their Pi - I tried it and it solved the issue.

This tells me that the root of the challenge is not NextCloud per se, but a "disconnect" between the way that NextCloud asks for libraries and the way that the platforms on which NC is being run choose to package and distribute that code. That is a problem of infinite complexity and I am under no illusion that asking NC to "solve" that is not only completely unreasonable, but beyond the abilities of any software project to address.

For this specific issue, I think one possible solution is simply to have a series of static pages in a tree-like structure:-

• Top Level would be Platform (Raspberry Pi, Gentoo, Microsoft Windows, Mac OS/X
• 2nd Level would be Platform Version
• 3rd Level would be e.g. all supported versions of PHP on that platform (8.3, 8.4)
• 4th Level - essentially the detail on the pages formed at the 3rd level - could be the actual packages [names and versions] needed/used.

I have a LibreOffice document that I wrote and maintain that covers how to install NC on a Raspberry Pi - and each time I port or upgrade the code I upgrade the doc to a new version. There, I literally list down the package dependencies, as well as notes along the lines of, "When you see this error message in the Admin Screens, {...}, here's how to fix it..."

The problem is that my notes are certainly specific to Raspberry Pi based installations and likely specific to my setup, but I still think there is knowledge there worth sharing with others. And I'd happily contribute to that pooled knowledge as a way of paying back to all those who have helped me in the past...