Confirmed (tested before and after update to 6.1.2)

Confirmed (tested before and after update to 6.1.2)

• Selecting an alternative layout on an individual article doesn't work
• Selecting an alternative layout globally doesn't work
• Selecting an alternative layout in the menu item works

Confirmed here too, I was posting this:

Since updating several sites to Joomla 5.4.7, custom layout overrides selected on individual articles (e.g. a homepage article using a named layout like homepage.php or accueil.php instead of default.php) stop loading. No PHP error, no warning — Joomla just silently renders as if no override existed.

Reproduction steps:

Create a named layout override for an article, e.g. templates/YOURTEMPLATE/html/com_content/article/homepage.php (a copy of default.php).
Select it as the "Layout" for a specific article (or via the menu item's "Choose a Layout" option).
Load the page — the custom layout is not used; the article renders with the fallback/default markup instead, with no error logged.
Workaround found:
If I rename the override file itself to default.php (overwriting the template's actual default layout), the content does load correctly using that markup — confirming the override file itself is valid and error-free. The issue is specifically that Joomla is no longer resolving/selecting named (non-default) layout overrides for articles.

Why this looks like a regression:
This happens identically across multiple, unrelated sites, all broken at the same version (5.4.7), with overrides that worked fine before. Since the file is confirmed syntactically valid (works once renamed to default.php), this points to a change in the layout lookup/resolution logic in 5.4.7 rather than anything in the override code itself.

Environment:

Joomla 5.4.7
PHP: 8.3
Template: custom child template based on Cassiopeia
Affects: article layout overrides selected via menu item and/or article options
Happy to provide a minimal reproduction template or more details if useful.

Confirming this on 5.4.7 across multiple sites (article-level layout selected via "Options → Layout", no dedicated menu item).

Root cause: PR #47752 replaced the blanket merge of the article's own params into $data->params (in ArticleModel::getItem()) with a narrow one that only forwards keys carrying the use_article sentinel value (show_author, show_create_date, etc.). article_layout never carries that sentinel, so it's silently dropped and never reaches HtmlView::display(), which reads it here to pick a named layout:

} elseif ($layout = $item->params->get('article_layout')) {
    $this->setLayout($layout);
}

For anyone needing a fix before the official patch lands, here's a temporary core-file workaround. In components/com_content/src/Model/ArticleModel.php, search for this line (added by #47752):

$data->metadata = new Registry($data->metadata);
and insert the following block immediately before it:

// TEMPORARY FIX for regression from #47752: article_layout is no longer
// forwarded to $data->params. Remove once fixed upstream.
if ($registry->get('article_layout')) {
    $data->params->set('article_layout', $registry->get('article_layout'));

}
Less invasive than a full revert of #47752 — keeps the author-display fix intact and only restores article_layout forwarding.

Please test #48060 and report back the test result there. Thanks in advance.

The source of the problem resides precisely here :
\components\com_content\src\Model\ArticleModel.php
lines 231 - 250, which have been newly introduced.

formerly there was just one line :
line 230: $data->params->merge($registry);

Obviously with the new code, the fallback/hierachical logic concerning settings-priorities ( which setting overrides which ( should be : Menu-item > Article-Settings -> general/component settings ) ) has been ignored or implemented in a faulty way here.

Hope that helps

The source of the problem resides precisely here : \components\com_content\src\Model\ArticleModel.php lines 231 - 250, which have been newly introduced.

formerly there was just one line : line 230: $data->params->merge($registry);

Obviously with the new code, the fallback/hierachical logic concerning settings-priorities ( which setting overrides which ( should be : Menu-item > Article-Settings -> general/component settings ) ) has been ignored or implemented in a faulty way here.

Hope that helps

@Lab5-Switzerland Could you also comment in the pull request (PR) #48060 ? Thanks in advance.