Related to #36567 ?

Hard to tell if its the same cause or not as they're not the most technical of users but the description is the same.

Perhaps the biggest problem is that users who are impacted by this dont know anything about the assets being moved and just assume the update is missing files

I ran into this problem while working on my template.
If I try to make changes to the file structure by analogy with cassiopeia, then everything that is connected via "joomla.asset.json" is not loaded.
If I make a copy of Cassiopeia, then everything works in it
If I make edits in the "templateDetails.xml" file before installation in the copied template, then the styles no longer work

I also noticed that if I just copy the template folder, then I get in the control panel
Joomla\CMS\Object\CMSObject Object ( [_errors:protected] => Array ( ) [name] => cassiopeia2 [type] => template [creationDate] => February 2017 [author] => Joomla! Project [copyright] => (C) 2017 Open Source Matters, Inc. [authorEmail] => admin@joomla.org [authorUrl] => [version] => 1.0 [description] => TPL_CASSIOPEIA_XML_DESCRIPTION [group] => [inheritable] => 1 [filename] => templateDetails )

If I change "templateDetails.xml" before installation, I get an empty array, which prevents me from making a child template
Joomla\CMS\Object\CMSObject Object ( [_errors:protected] => Array ( ) )
Tried updating the cache

I have not yet found how to solve these problems.
But I think they may be related to the problem of webassets

I too am running into this issue.
Not sure how to solve it, or what code route stuff takes to trigger this.
But the problem is that the template media path is being added to an already incorrect template media file path:

/media/templates/administrator/atum/css/administrator/templates/atum/css/template.css

Problem code is indeed the stuff:
/libraries/src/HTML/HTMLHelper.php [418]

if ($template->inheritable || !empty($template->parent))
{
	$client     = $app->isClient('administrator') === true ? 'administrator' : 'site';
	$templaPath = JPATH_ROOT . "/media/templates/$client";
}

The issue is that the $file contains administrator/templates/atum/css/template.css.
I haven't tracked down where that file path is coming from (where it is created).

This is the route in one of the cases I am seeing (final step at the top):

/libraries/src/HTML/HTMLHelper.php [357] 
> Joomla\CMS\HTML\HTMLHelper::includeRelativeFiles()

/libraries/src/HTML/HTMLHelper.php [297] 
> Joomla\CMS\HTML\HTMLHelper::stylesheet()

/libraries/src/HTML/HTMLHelper.php [125] 
> Joomla\CMS\HTML\HTMLHelper::call()

/libraries/src/WebAsset/WebAssetItem.php [318] 
> Joomla\CMS\HTML\HTMLHelper::_()

/libraries/src/WebAsset/WebAssetItem.php [182] 
> Joomla\CMS\WebAsset\WebAssetItem::resolvePath()

/libraries/src/Document/Renderer/Html/StylesRenderer.php [137] 
> Joomla\CMS\WebAsset\WebAssetItem::getUri()

/libraries/src/Document/Renderer/Html/StylesRenderer.php [80] 
> Joomla\CMS\Document\Renderer\Html\StylesRenderer::renderElement()

/libraries/src/Document/Renderer/Html/HeadRenderer.php [37] 
> Joomla\CMS\Document\Renderer\Html\StylesRenderer::render()

/libraries/src/Document/HtmlDocument.php [601] 
> Joomla\CMS\Document\Renderer\Html\HeadRenderer::render()

/libraries/src/Document/HtmlDocument.php [907] 
> Joomla\CMS\Document\HtmlDocument::getBuffer()

/libraries/src/Document/HtmlDocument.php [672] 
> Joomla\CMS\Document\HtmlDocument::_renderTemplate()

/plugins/system/regularlabs/src/Application.php [68] 
> Joomla\CMS\Document\HtmlDocument::render()

Trying to update a website on cloudaccess (joomla.com) I had the problem too. It was not possible to update twice because the backend was totally broke. I found this thread: https://issues.joomla.org/tracker/joomla-cms/35915#event-667343 and this: https://github.com/joomla/joomla-cms/blob/4.1-dev/administrator/components/com_admin/sql/updates/mysql/4.1.0-2021-11-28.sql#L4
On my DB the inheritable value was 0, changing it to 1 solved my problem.

In my cases changing the inheritable value has no effect.
To me it seems like the approach to determining what the file path is, is rather prone to failure.
No control over what paths are coming in, and no checks on it. A lot of assuming going on in the code.

In my cases changing the inheritable value has no effect.

Changing the inheritable in the XML will never have an effect, you need to apply those in the template_styles table manually.
The 4.1 (when the update did finish correctly) should have the inheritable column in the template_styles table correctly filled. This is the indicator for the core if a template is legacy or using the new mode. The code is not prone to bugs because the template details are loaded very early in the lifecycle and are used in the related methods (HTMLHelper, Web Assets) for picking up the right paths. Are you using relative paths or hardcoded ones? The hard coded are totally wrong as they prevent the overriding of static assets which is kinda fundamental for front end people...

On my DB the inheritable value was 0, changing it to 1 solved my problem.

Maybe we should write a simple end point so that the update could be done by visiting a URL for those not able to do these changes manually...

For those that can't apply manually the sql files needed for the update and they do have a broken site after updating please follow the instructions (3 easy steps) here: https://gist.github.com/dgrammatiko/6889cbf2a2cc68627fdbf968bd7d9b43

Also something that came up in another issue: check that the name field in your templateDetails.xml is the actual folder name of your template (case sensitive)

Changing the inheritable in the XML will never have an effect

I know, I meant changing it in the database.

The code is not prone to bugs

See my earlier reply.
The $file variable already contains an incorrect path (because the fils have moved). It contains administrator/templates/atum/css/template.css.
This happens for instance when doing a custom (new Application)->render().
Whether the problem is in the HTMLHelper, that it doesn't check the value of the $file, and blindly prepends it with the new template media path. Or the problem is higher up the stream, that should prevent a path like administrator/templates/atum/css/template.css even being passed to the HTMLHelper::stylesheet()... well, you can decide that.
Personally I think checks for dealing with the new template media path should be in multiple places to make it more stable.
Somewhere in Joomla the code is still creating a path like administrator/templates/atum/css/template.css based on the information provided in the joomla.asset.json. So things are already going 'wrong' there.

Also - and yes, I know, there is not much value in saying this, but - changing the location of media files (that could be called on via different ways, to me seems like a BC breaking change. You have no overview of how extensions or other templates might be calling/including those files. So things can potentially break. And as you have seen, they clearly do.
And a BC break is fine, but it would mean Joomla 4.1 should have been named Joomla 5.

But like I said, useless to mention this, as Joomla hasn't stuck to the semantic versioning many times, pushing breaking changes in minor (and even bugfix) versions.
We should have been at at least Joomla 16 by now!

Ok, rant done.
Do with this what you want. I'll try and find a way to work around the curveballs again.
Over and out.

And a BC break is fine, but it would mean Joomla 4.1 should have been named Joomla 5.

@regularlabs you're wrong the changes were done in v4.0.0: #30192 August 2020!!

Somewhere in Joomla the code is still creating a path like administrator/templates/atum/css/template.css based on the information provided in the joomla.asset.json

joomla.asset.json contains template.min.css which resolves to template CSS folder
/media/templates/administrator/atum/css/template.min.css
in past it was
/templates/administrator/atum/css/template.min.css

In some reason you still have old behavior, due to outdated DB or some other reasons.
It not possible to say remotely.

Problem code is indeed the stuff: /libraries/src/HTML/HTMLHelper.php [418]

if ($template->inheritable || !empty($template->parent))
{
  $client     = $app->isClient('administrator') === true ? 'administrator' : 'site';
  $templaPath = JPATH_ROOT . "/media/templates/$client";
}

So it looks like outdated DB, what @drmenzelit already commented. inheritable should be 1 for Autum and Cassiopeia.
Or some PHP file not updated, but it unlikely.

Sorry for repeating:

For those that can't apply manually the sql files needed for the update and they do have a broken site after updating please follow the instructions (3 easy steps) here: https://gist.github.com/dgrammatiko/6889cbf2a2cc68627fdbf968bd7d9b43

I bow in shame and crawl back into my hole...
Seems like I was registering the style paths manually via a bit of code. ??‍♂️

This fix is not fixing my problem!! Backend and frontend templates are still gone

Hmm.. ok i got it working by overwriting all core joomla files with the 4.1 files - very odd behaviour. But then the user.css from the old cassiopeia folder was also gone ? Is that file not moved when updating to 4.1 ?

Your user.css should be in media/templates/site/Cassiopeia/css

Yes i confirm all components how propose to load a css file for override (put in templates/mytemplate/css) need to udpate rules or move css file

Thanks for the fix, it fixes the template issue. However, I wonder if there is still an issue - on two sites I've had this issue, it doesn't seem the new jooa11y plugin is there. So could there be some other installation error? The upgrade log shows success. Also of note, these are all manual upload and upgrades. I can't get rid of the "database needs fixing" error, even though the database shows no problems and doesn't have an update structure available.

I can't get rid of the "database needs fixing" error, even though the database shows no problems and doesn't have an update structure available.

This was reported on Glip I think @roland-d has more info for this (but this one has nothing to do with the broken database fix, it's another issue afaik)

@tmumm What I had to do to get rid of the Database needs fixing issue was run 2 SQL queries:

UPDATE #__extensions
	SET manifest_cache='{"version": "4.0.6"}'
	WHERE extension_id=211
    
INSERT INTO #__schemas (extension_id,version_id)
	VALUES (211,'4.0.6-2021-12-23');

The first one fixes the version in the manifest cache, this needs to match the version of the installed Joomla version. In my case this said 4.0.5..
The second one I did was add the schema version to the schema table because it was completely missing. The version ID here is the filename of the latest SQL file in the administrator/components/com_admin/sql/mysql/updates folder. Which should also be the same if you are running 4.0.6.

The value 211, is the ID of the extension table for the Joomla files. This should generally be the same for everybody but could differ per site of course.

Great, thanks. That fixed the database issue, and as another clue to the larger issue, I was able to update this site without have the template issue come up.