The overrides system of Joomla is flawed

[dgrammatiko]

This comes in 2 parts:

• CLI is not aware of the layouts (Fix FileLayout to work in non Web context, like Cli, Api #38585 tries to fix it)
• Both static assets and layouts overrides are checked per instance in every lifecycle (this has a huge perf/energy cost)

For the first I left a comment in @Fedik's PR
For the second: Templates are the only entity that HOLDS any overrides thus templates SHOULD provide a resolution (eg a json file with all the layout and asset overrides or even better a .php returning 2 objects one for the static files and one for the layouts, this will increase the efficiency if OPCache is enabled) instead of having to do a gazzilion of I/O file exists checks!

Since this is touching the architecture of the platform @laoneo @nibra @HLeithner might be for you

[Fedik]

CLI is not aware of the layouts

Yeah, much of rendering (component view and layouts) thing is built for Web view, and overrides also. Quick fix for API was add "fake template":

joomla-cms/libraries/src/Application/ApiApplication.php

Lines 194 to 208 in 3074a99

	public function getTemplate($params = false)
	{
	// The API application should not need to use a template
	if ($params) {
	$template = new \stdClass();
	$template->template = 'system';
	$template->params = new Registry();
	$template->inheritable = 0;
	$template->parent = '';
	return $template;
	}
	return 'system';
	}

I probably would expect that for non Web context an override would look for a default site template.
It would be more easy for end User.
Btw, Niels made RFC for "Decoupling Output" joomla/rfc#36, I guess it is linked.

Both static assets and layouts overrides are checked per instance in every lifecycle (this has a huge perf/energy cost)
... instead of having to do a gazzilion of I/O file exists checks!

You will be surprised how much "file exists" PHP doing under Class loaders.
But in general PHP do cache a loot of filesystem request.
It was "huge" when we used HDD, now it is fine 😄

UPD: In J4 css,js assets checked only once before actual rendering, in oposite to older joomla, when HTMLHelper was used for add these files.

[dgrammatiko]

It was "huge" when we used HDD, now it is fine

Maybe you're right but for such cases only benchmarking the 2 versions can only give the actual state.

Also something related looking at the future and when all of the browsers will support import maps having a JSON with all the overrides for JS files would be invaluable as the creation of an import map would be a simple object filter and json.stringify task. The project should always check where things are heading...

Also nice to the RFC, I know that @nibra already had a working prototype on this particular problem (and it's a nice one)