Support

This is a core Joomla bug, now fully confirmed.

Joomla defines class aliases for the deprecated Joomla\CMS\Filesystem\* classes, mapping them to the modern Joomla\Filesystem\* classes.

Our software uses the modern classes as Joomla explicitly instructs is in its official documentation, see Joomla’s “New Deprecations” migration guide:

In most cases you only have to change the namespace from Joomla\CMS\Filesystem\* to Joomla\Filesystem\*.

That is to say, we are following Joomla’s own instructions here, not doing anything unsupported.

The real root cause of the problem is that Joomla erroneously ships the concrete Joomla\CMS\Filesystem\* classes in files under the libraries/src/Filesystem directory.

Since Loader::applyAliasFor() in libraries/loader.php (lines 570–579) calls class_alias() without first checking whether the alias already exists, this creates the core Joomla bug.

Admin Tools in itself does not have a bug. We are doing what Joomla asks us to do. The problem is that Joomla does not do what it is supposed to do. When an alias is introduced, the concrete class file MUST be removed to avoid exactly this kind of issue. This is the exact bug reported in issue #46652.

While the proposed fix for this issue (pull request joomla-cms#46300) was architecturally wrong, the underlying core Joomla bug is very real and it's what is biting you now.

Since this is a core Joomla bug, we do not have any way to address it. Moreover, since the Joomla project has blocked us from contributing, we have no way to even report it. Please submit an issue to Joomla's GitHub and point them to this public ticket. It should be very obvious to them what is going on and how to fix it. In case it's not obvious to someone, the correct fix is deleting the obsolete libraries/src/Filesystem directory and all its contents, as it should've been done in Joomla 6.0.0.

Also, for what it's worth, it appears that the files in libraries/src/Filesystem are ostensibly being removed in the post-update Joomla script administrator/components/com_admin/script.php in the lines 518–526 and 1301–1306 (as per the current 6.2-dev branch).

I trace these files back to a much earlier commit. This means that your site SHOULD NOT have these files – and the same applies to my dev test site which has been upgraded from Joomla 5.3 to 5.4 to 6.0 to 6.1. Seeing leftover files makes me worried.

Edit: I erroneously said "dev site" in the original reply I wrote. My dev site which has followed the same update path does not have leftover files. Only the test site which I use just to test whether packages can be installed and updated without an issue was affected. That's the bit that's worrying me. Same server, same software, same actions, different result points to some kind of non-deterministic issue which makes me wonder how many sites may have been affected!

Therefore, the real issue here may be a bit different.

If the Joomla post-update script doesn't run (either at all, or to completion), or somehow these files end up being present on the site, there is currently no warning, and no mechanism to fix that. There should've been a Filesystem Fix feature similar to Database Fix for exactly these use cases. If I recall correctly there's only a CLI command, but I am pressed for time being a Sunday evening and can't check thoroughly right now. I am adding this for completeness.

The bug is real, but the trigger is not something the core maintainers may have seen as they don't do end user support at the extent we do as third party developers. They are welcome to use our observations and knowledge as they see fit.

When it comes to your site, Yves, you can safely delete the directory libraries/src/Filesystem and your problem will go away.

A final, preemptive note: You are probably thinking I am full of shit because you reinstalled the Joomla core files. Here's the thing. Reinstalling the Joomla core files WILL NOT delete these leftovers. It will only replace existing files and write new files; it does NOT delete obsolete files. The problem happens because you have obsolete files that shouldn't be there.

To me, this is a documentation issue. The documentation does not mention that obsolete files won't be removed. Your expectation is that "reinstall core files" means going back to a pristine state, though that's not the case. This disconnect between expectation and reality needs to be documented to avoid issues like that.

Moreover, having a mechanism to reap the obsolete files (a "Filesystem Fix" kind of feature, in the same vein as the already existing "Database Fix") would address that disconnect and use case.

I have no say on Joomla development. This is how I would have addressed a similar issue in my own software. Core maintainers can do what they want with this suggestion, be it implement it or ignore it. I only make the observation, I am not demanding an implementation.