Short term hack here to make things work #20827

Please leave this open though because the fix you describe by extending the xml is clearly much better and should be implemented instead of my hack before we get to beta.

As there is now one way to access a component, through the boot function. An alternative would be to give the classloading responsibility back to the extension itself. Means the namespace registration can be done while booting the extension.

The namespace mapper and autoloader shouldn't be using said boot function. Otherwise you're getting into a massively magical black box you don't want to be getting into.

What I mean, that the extension itself can register its namespaces during boot by itself and not something else.

I still think it is can bring us into troubles when users can disable the classmapping plugin.

At the moment we have the namespace information at three places. The manifest file, the database and the classmap file. I would cut out the database step as it is unflexible, what this issue revealed. So the classmap file will be generated out of the manifest files directly. This allows us to extend it with a destination folder or even multiple classpath's when needed. If @wilsonge you agree with tht then I will do next week a pr.

It depends what kind of timing issues this gives on the PR. I assume that parsing XML files is going to be slow. Because we'd have to parse ALL extension xml files on install, update and removal of any extension (what's going on in the namespace plugin).

Don't think so that timing will be an issue. If it is then we can optimise the classmap as an indexed array. So the extension can directly being added/updated/removed.

If it is then we can optimise the classmap

I'd like to avoid that. I've deliberately kept the classmap with the same format as the composer generated autoload files.

But let's see what the timing is like. The only reason I stored in the db was to 'solve' the theoretical timing issue to parse all the XML files.

I can make some tests how long it will take. If fine, would you be ok to skip the db? Then I can also implement the path attribute.

Yeah of course. If it doesn't take forever to rebuild the file then I'm totally happy with removing it from the db (literally the time to parse xml files was the only reason to store it in the db)

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/20823

closed as having Pull Request #21766