After install PR using Patchtester got:

@franz-wohlkoenig - The patch tester doesn't apply any SQL updates. Go to PhpMyAdmin (or whatever database manager you're using), and execute the following:

ALTER TABLE `#__extensions` ADD autoload tinyint(3) DEFAULT 0 AFTER state;

@franz-wohlkoenig currently autoloader and namespace pr's on Joomla 4 are changing stuff on the core and do alter the db schema. So you need to run the update queries which do come with the pr's.
Honestly we are in development mode, so it is IMO not required to test them like on staging. Mostly feedback by the community and a test by the Joomla 4 release leader are enough to get it merged.

So its better not test and wait on Dev. for go to Test.

Yes, think so.

Honestly we are in development mode, so it is IMO not required to test them like on staging. Mostly feedback by the community and a test by the Joomla 4 release leader are enough to get it merged.

Honestly, I think that's a bad idea in general. If it can be tested, it should be properly tested. Otherwise we will introduce way to many bugs.

I've just tested and it's causing some issues:

Before:

After:

@C-Lodder did you set autoload.php in the com_content row in #__extensions for the autoload column?

Honestly, I think that's a bad idea in general.

I was referring to the autoload and namespace pr's not all pr's in general. For sure stuff needs to be tested.

I have tested this item ✅ successfully on a5b124a

@laoneo - Oops by bad. Did that and now working fine.

Some thoughts:

• I wonder how much sense it makes to load the autoload.php files of every extension (who has registered one), regardless if it is needed or not. That could be quite a few files to include and in most cases it probably isn't needed at all. Maybe it could instead be done as a fallback in case a requested namespace isn't found? Maybe the better approach however is that extensons just register the namespaces they need in their initial file.
• Current proposal will require the autoloader to be within the respective extension directory. Eg it's not possible to have a single autoload.php shipped in a library package which is then used by the component, modules and plugins as well for their classes. However I don't know if that would be a possible use case.

I wonder how much sense it makes to load the autoload.php files of every extension

This set up here is especially useful for extensions which do use composer and none standard namespaces. So honestly I don't know how to create here some magic for lazy loading. But I don't think so that this is an issue problem at all as registering a classloader is not too time consuming.

Eg it's not possible to have a single autoload.php shipped in a library package

It can easily be extended for libraries if needed.

So honestly I don't know how to create here some magic for lazy loading. But I don't think so that this is an issue problem at all as registering a classloader is not too time consuming.

It may be not very time consuming, but in most cases the query and the registering is just useless as the classes will not be used at all. That's why I ask if we really need some magic for those cases where extensions have non-joomla-standard namespaces. It's simple enough to register / include an own classloader in those extensions.

It's simple enough to register / include an own classloader in those extensions.

That's what this pr is about. Like that the extension developer is able to load it's own extension classes the way she/he needs.

I meant they can add as well a single line into their initial extension file(s) to load their classloader (when needed). Without Joomla having to query the database and loading several unneeded classloaders.

I'm just not convinced we need that "magic" here.

This isn't just about magic behaviors or loading extra data into the autoloader. Part of the aim with class autoloading is you don't have to be explicitly aware of the filesystem structure, make sure the class is loaded, load it if need be, then use it; you just use the resources. Extensions are littered with manual loading declarations of class dependencies, not just within the active component but modules and plugins too. The number of places calling jimport() or JLoader::register() needs to go down massively.

Sure, I got that part. My concern isn't about autoloading in general (which is obviously fine). It's about doing an extra database query and loading all autoloaders on each pageload, regardless if the classes of that extension are even used or not. Depending on the site that may be a lot of classloaders to always include.
I don't see the issue when a component or module (or whatever) has to add a single line of code to load their own classloader. But if you think it's worth to add a query and always load all autoloaders to remove that line then I'm fine.
I can't say if it's worth or not.

It's about doing an extra database query

Its a simple query with an index. So not much loss here. The gain for all the import and require calls is bigger IMO (of course just a guess).

I don't see the issue when a component or module (or whatever) has to add a single line of code

You have to add that line on multiple classes, because they can be called without the full context where they are used. So you end up in a normal request with multiple import calls.

The gain for all the import and require calls is bigger IMO (of course just a guess).

I'd question exactly that. Because the import and requires for specific classes can be removed from extensions anyway when they use an autoloader. That's independant from this PR.
We're only talking about a call to register/load the autoloader for a given extension. In your proposal all of them would be loaded in addition to an additional query. In most cases you only would need a few of them.

You have to add that line on multiple classes, because they can be called without the full context where they are used. So you end up in a normal request with multiple import calls.

Yep, it would be in one single class/file per extension, namely the initial "bootstrapping" one (for components the dispatcher one). Modules and plugins only would need it if they actually use a class from their respective component or have an own namespaced class structure. Imho that's not a big deal to do.

Or I still miss something obvious.

Because the import and requires for specific classes can be removed from extensions anyway when they use an autoloader

I'm talking here about classes which are used outside of the ordinary extension context. Like fields, helpers, layouts all code code which is used outside of an ordinary loaded extension. Or extensions like plugins who do want to load libraries from a component, etc.

Imho that's not a big deal to do.

When we start doing proper PSR-4 namespacing, then we should simplify it that way, that during execution process, an extension developer shouldn't care about autoloading. At least what I think should be the case in a proper system.

I'm talking here about classes which are used outside of the ordinary extension context. Like fields, helpers, layouts all code code which is used outside of an ordinary loaded extension.

Ah ok, this makes sense, yes.

I still don't think it's a good idea to load all autoloaders prematurely but at the moment don't see another way then.

At least I tried ?