What happened?

Issue:

On Joomla 5.4.7+ and 6.1.2+, an article’s Options → Alternative Layout (stored as article_layout in the article attribs) is not applied when the article is viewed through a Single Article menu item. The frontend uses the global com_content article layout instead.

This is a regression from PR #47752, which stopped merging all article attribs and only copies keys whose menu/state value is the string use_article.

Related issues: #48058, #48062.

Steps to Replicate:

1. Add a custom article layout override under the active template, for example: templates/[template]/html/com_content/article/mylayout.php. Use markup that is easy to recognise on the frontend.
2. Create and publish an article. Open Options → Alternative Layout and select that layout.
3. Create a Single Article menu item pointing to that article. Do not add a layout= parameter to the menu link.
4. Under Content → Articles → Options, set the global Alternative Layout to a different value so the difference is obvious.
5. Open the menu item on the frontend.

Version

6.1

Expected result

The article’s Alternative Layout is used.

Actual result

The global article layout is used. The layout selected on the article is ignored.

System Information

Joomla: 6.1.x (also reproducible on 5.4.7+)
PHP: 8.3
Template: any template with a custom article layout override
Menu item type: Articles → Single Article

Additional Comments

Root cause

In components/com_content/src/Model/ArticleModel.php (getItem()), parameter handling changed from merging the article attribs registry into the params object to only copying keys when the menu/state value is 'use_article'.

That sentinel is used by listing-style menu options such as Use Article Settings for display toggles (show title, show author, etc.). It is not how Alternative Layout is configured.

For a typical Single Article menu item:

• The menu request usually contains only option, view, and id (no layout).
• The Single Article menu definition does not provide an article_layout field with a use_article value.
• Therefore article_layout is never copied from the article attribs into $item->params.
• HtmlView then calls setLayout() from $item->params->get('article_layout') and receives the global layout.

PR #47752 correctly improves Menu → Article → Global resolution for fields that use use_article, but it drops article_layout, which is still set on the article and is still documented as the way to assign a custom Alternative Layout.

Suggested fix

Keep the use_article three-tier logic for display fields, and also apply article_layout from the article attribs when it has an explicit value, for example after the existing loop:

if ($registry->get('article_layout') != '') {
    $data->params->set('article_layout', $registry->get('article_layout'));
}

Temporary workarounds

• Add &layout=LAYOUTNAME to the Single Article menu link so the active menu query includes layout (the view checks that first).
• Temporarily restore a full merge of article attribs into params (fixes layouts; undoes the display-hierarchy fix from #47752).
• Wait for the official patch in a later 5.4.x / 6.1.x release.

Impact
Any site that assigns per-article Alternative Layouts and opens those articles via Single Article menu items is affected after upgrading to 5.4.7 or 6.1.2. Global layout and menu-link layout= still work; article-level Alternative Layout does not.