Steps to reproduce the issue

The concept of a autoload_psr4.php has been introduced in Joomla 4.

This file is stored at /administrator/cache/autoload_psr4.php

This file, if not-exists, is created on first interaction with Joomla, and regenerated at times, like on installing a Joomla extension/template/plugin.

If this file is not writable, or the folder not writable, by Joomla then a warning is generated, and no helpful text explaining that Joomla is now in an odd an inconsistent state as any newly added classes are not in the autoloader. Depending on the extension installed, this could have knock on effects. Joomla doesn't (probably correctly) automatically keep trying to update the autoload_psr4.php on subsequent page loads, as it just loads it and uses it, regardless of the fact it could be missing classes.

Why would autoload_psr4.php not be writable you may be asking? Well. Because. Internet. Users. Webhosts. Etc... See Additional Comments below for my case today, however this is not as uncommon as I make out. Many web servers run different users for FTP and for the web server. Many web hosts have permissions issues generally. Just look at the forum and you will see that. In a perfect world Joomla would always have access to write to its files. but this is an imperfect world.

How you can replicate this issue manually:

• Interact with your newly installed Joomla 4 site
• Now that you have a /administrator/cache/autoload_psr4.php file, make it unwritable by changing permissions and/or ownership manually
• Attempt to install Akeeba Backup (A rock solid Joomla 4 compatible extension at this time).
• Note the warning.
• Note that the /administrator/cache/autoload_psr4.php has not been updated

Expected result

I don't have all the answers.

At the very least we should not be showing PHP warnings to the user.

At the best, we should be checking for the ability to write to administrator/cache/autoload_psr4.php BEFORE attempting to undertake a task (such as installing an extension) that will require the regeneration of the autoloader and writing of the file.

At the extreme we could check the consistency of the content of autoload_psr4.php periodically.

Actual result

Warning: file_put_contents(/pathto/public_html/administrator/cache/autoload_psr4.php): failed to open stream: Permission denied in /pathto/public_html/libraries/src/Filesystem/File.php on line 384

System information (as much as possible)

cPanel based standard hosting on Centos7

Additional comments

This came to light in testing the CLI in a production environment when logged in as the linux root user and running php cli/joomla.php command - this generated a /administrator/cache/autoload_psr4.php file owned by the root user.

This then meant that the /administrator/cache/autoload_psr4.php was not writable by the standard user used at the time of running Joomla PHP (the cPanel user in this case).

It will not be uncommon for command line utilities to be run by "other users" not the same as the user running at the time Joomla PHP is running (I.e not the cPanel user in this instance) - it will also not be uncommon for some (silly) admins (like me) who use root to interact with (known and secure) CLI apps.

Bonus issue.

If, while your autoload_psr4.php is unwritable by your command line user, you use the command line:

php cli/joomla.php extension:install --url=https://www.akeeba.com/download/akeeba-backup/7-5-1/pkg_akeeba-7-5-1-core-zip.zip

You actually get no feedback that the autoload_psr4.php was not updated. You don't get the PHP warning, so you are blind to the problem that your site's autoload_psr4.php is not inconsistent with your sites classes.