Note to testers: delete libraries/autoload_psr4.php after applying patch.

Thats not a solution, we can't move any file/directory around, we have the same problem with other files and 3rd party files too.

Thats not a solution, we can't move any file/directory around

Actually, you can. It's your product, you can define standards for extensions. This is a standard that should have been enforced in the first place once namespace efforts started but people rejected it for miscellaneous reasons that made little sense (to me).

I still don’t really like the src directory. But there’s very few extensions using new mvc and tbh those who are can deal with things as appropriate. There’s no real alternative to this PR unless you can propose one?

No change to script?

No change required. The old directories need to be moved. Just now the code lives in a sub directory the new code won’t be removed ?

the new code won’t be removed

You mean the old code I guess?

No, I think he means the new one. Problem on Windows hosts was that new code was removed because had same path as old code when case-insensitive path, if I don't remember wrong.

We should fix our install update script to support this kind of problems, It's possible to detect the current file case on disk on windows. I already started to write a PR but struggle to write all the testcases for this.

I still don’t really like the src directory.

What is the issue with it, the extra nested directory? IIRC part of the folder restructuring was to separate the different asset types so you didn't have mixed purpose files living in the same "root" directory, and that mostly exists now except for the fact that you have the PHP code sharing the same root path as forms and language files and SQL related stuff. Conceivably, you could have this as your root component structure:

• assets: CSS/JS/LESS/SCSS, because I think it's pretty clear by now extension vendors aren't using the media folder (and they may actually choose to ship non-production build assets ("raw" ES6 JS or SCSS) and this would be a meaningful place to put those resources
• forms: XML definitions
• language: Translation files
• sql: SQL files for install/update/uninstall
• src: PHP class structure
• tmpl: Template files (though I would've went with the spelled out templates instead of Joomla's weird abbreviation)

Every resource type is in its own crystal clear directory and you don't have mixed resources in mixed paths. Even Symfony is moving bundles toward getting rid of that Resources directory that had all the translation and service definition and asset files in it in favor of this type of structure (basically bundles will soon match the Flex application structure).

The only thing putting all the PHP code inside a src directory does is make you teach people why there is an extra directory level inside administrator/components/com_foobar. It doesn't hurt anything, and it helps work around the issue in upgrading 3.x to 4.0 for Windows users (which, based on last 180 day stats, is more of a niche use case 13% of sites reporting stats the last 90 days are on a Windows platform; to me this means simpler solutions should be explored and preferred where practical over trying to write overengineered filesystem code specific for the Windows environment, especially in an application where historically automated test coverage of filesystem interactions is minimal at best).

Even if this is a solution (that doesn't look bad) it doesn't solves our 3rd party library problem

Even if this is a solution (that doesn't look bad) it doesn't solves our 3rd party library problem

You're right. But, to my awareness, right now that is a practical issue for one file in one package. Personally, I would write up a solution specific to that single instance over spending time trying to write an abstract solution that will work for all future cases. Granted, odds are writing that one time fix is probably going to be 85% of the work for the "covers all the future scenarios" problem too, but that's again just me going for the quicker solution for what is statistically more of a niche scenario than a general issue.

What about moving core libraries outside of libraries directory as suggested in #23868? Can we do that for 4.0?

I have tested this item ✅ successfully on d23093a

I have tested this item ✅ successfully on d23093a

I have tested this item ✅ successfully on d23093a

RTC.

What about moving core libraries outside of libraries directory as suggested in #23868? Can we do that for 4.0?

It's not going to move. We blacklisted the override and I pretty much consider that issue closed.

Thanks!