I have tested this item ✅ successfully on 6756d87

OK tested successful

Whilst I do understand the logic of this (and it's annoyed me before). There is a reason for this behaviour. If you pick a category blog menu option for example then you override it with a different article type then you end up with super confusing behaviour

@wilsonge i understand, but how can following scenario be solved then:
User is submitting content to a specific category. All Articles of this Category should be shown with an Alternate Layout (because of specific custom fields stuff). The User who is submitting has no possibility to chose a layout.

Hi @wilsonge I have the same "problem" with the alternative layouts than @coolcat-creations so I think this PR makes a lot of sense.
Could you explain further, the "super confusing behavior"?

I have tested this item ✅ successfully on 6756d87

Works perfectly. I don't see any reason not implementing this PR. If a user get a strange behaviour (not sure which one) he/she can deactivate the parameter...

I have tested this item ✅ successfully on 6756d87

RTC

If a user get a strange behaviour (not sure which one) he/she can deactivate the parameter...

This is exactly why the PR needs to be adequately tested. The behaviors need to be documented and the way menu item parameters are merged understood to know what the actual desired behavior will be. If you set this parameter on a category menu item and have a different value on the article, which is the value used?

Yes, this is a desirable feature, but it needs to be tested beyond "new parameter shows up, sweet!". Suggest RTC removed, a full test scenario is written up for possible paths, and that tested first.

Not sure about that. It's the same behaviour as all the other parameters with this combination

If it is we're good. But given George's comment on the matter and me knowing that menu item parameter merging with other items is tricky, it would be good if we had explicit test scenarios confirming this. Right now the way this PR reads, it basically says "make sure the menu item parameter is applied and works". It does not do anything with testing whether if the parameter is set at the article level, whether the article's parameter "wins" over the menu item as an example. It's that more involved path that needs better documented testing IMO.

Yep, I guess it wasn't clear from me, I fully agree with you, I just wanted to know, what is missing in your point of view.

1. Apply patch
2. Create category blog menu item for a category with two articles, set the new parameter to an alternate layout
3. In one of the two articles, change this parameter to a value different than the menu item
4. Browse frontend and note the layout used with each article

• Is this result consistent with expectations?

@coolcat-creations can you please test what @mbabker suggested?

@franz-wohlkoenig yes - added to my todos tomorrow.

@coolcat-creations If you could write automated tests for that, it would be great. If you can not do that with code, no problem: Just write down the test cases in plain English, so we can turn it into code. You can use this pattern:

Given: (any preparation step, fx. "I am logged in into the backend")
When: (a list of actions, fx. "I go to the Article Manager" and "I create a new article with title 'Test1'")
Then: (a list of expected results, fx. "I see the first article having h1.class 'default'" and "I see the second article having h1.class 'alternate'")

Hello!
Finally:

1. Create an alternate layout for articles and name it menutypelayout.php - add into the headline "This is the Alternate Layout set in Menutype"
2. Create an alternate layout for articles and name it articlelayout.php - add into the headline "This is the Alternate Layout set in the Article"
3. Setup a Testcategory with at least Testarticle 1 and Testarticle 2
4. assign the articlelayout.php Layout inside the Article Options of Testarticle 1
5. Apply the patch
6. Create a Menuitem with Testcategory Blog View, Select menutypelayout as alternate Layout in the Options tab

Expected Result: "All" Articles beside Testarticle 1 are shown in the assigned menutypelayout Layout. Testarticle 1 has an assigned specific Layout (articlelayout.php) - this Setting is "deeper" and so it´s expected that it´s shown in the other layout.

Repeat Step 1 - 5 for Category List, and for List view with ANOTHER Testcategory and items

Unexpected Results are caused by:

1. creating for example one menuitem category blog without alternate layout and another menuitem category blog to the SAME category with alternate Layout
2. Creating one menuitem category blog with alternate layout and another menuitem to an article from the SAME category directly without alternate layout

These two cases are caused by a bad site-architecture and planning and IMHO not relevant.

Priority:

See if A-Layout is set in an Article
IF NOT
See if A-Layout ist set in Blogview in Menuitem this Article is part of
IF NOT
See if there is an Alternate Layout in Global Options for Articles

See if A-Layout ist set in Blogview
IF YES
Display Articles with A-Layout
See if A-Layout is set in an Article
IF YES
Display Articles with specific A-Layout

I hope this makes the issue more clear. Not sure if the unexpected result part can be removed by improving the router. It would be definetly good to improve the overview and User Experience of Alternate Layout and Override setup at all. (J4 ?)

@mbabker is your Comment answered by @coolcat-creations?

So can this marked as RTC @zero-24 @dgt41

@mbabker is your Comment answered by @coolcat-creations?

As long as it's tested out and the parameter merging isn't causing unintended side effects (which it sounds like is the case, minus the deep rooted architectural issues which exist without this PR anyway), this is fine by me.

waiting on @zero-24 and @dgt41 before setting RTC as @bembelimen stated.

Make 1. to 6. how coolcat-creations commentend at 10.May

But if you now change in the menu-item to an other TemplateStyle(for example from Protostar to Beez)
Menuitem with Testcategory Blog View -> Details -> Template Style

Then works the menutypelayout furthermore with the Beez-Template
But you dont see this in the menu-item at:
Menuitem with Testcategory Blog View -> Options -> Choose a Layout

If you now save it again then is come the expected result(view without the override from the other Template). Save it twice after change to an other Template Style then you have correct "view".

Similar same as in #16755 and #8578

If RTC this new feature without solve the bug, then needs additional "documentation" or "warning" or not ?
I dont know that.

I would suggest to open a new issue about that. As far i understand you, you don't see alternate/custom menu-types (alternate layouts with own .xml) although you can select their alternate layout in the Article. That has not really something to do with those PRs.

I think you misunderstand me.

I make all (alternate layout for articles in the Template Protostar) and all others from 1. to 6. what you wrote in this PR at 10.May
and then all works as expected but:

if i then change Details -> Template Style (for example from Protostar to Beez) in the menu-item that was created at your point
6. Create a Menuitem with Testcategory Blog View, ...

then works the menutypelayout furthermore with the Beez-Template in this menu-item.
But you dont see that in this menu-item at:
Options -> Choose a Layout

If you now save it again then is come the expected result(article-view without the
alternative-article-layout-override from the other Template). Save it twice after change to an other
Template then you have correct "view".

@Sieger66 can we have a chat about your issues and if they are related to this PR?

@coolcat-creations no because my english is not good.

I know your PR is not direct the reason of the bug. The bug its relate to
filed type componentlayout, how shamsbd71 explain.
That layout parameter should save with a value like "template_name:layout_name" when saved to the database, and when used in the PHP API, that template name segment gets parsed by the view class to figure out that it needs to change the active template, how mbabker explain.

I dont find an other place in joomla who this bug have an affect.

But if your PR would merge without a solution for the bug, i dont know is it need for additional "documentation" or "warning" or not ?

For example in the:

COM_MENUS_ITEM_FIELD_TEMPLATE_DESC="Select a specific template style for this menu item or use the default template."

to:

COM_MENUS_ITEM_FIELD_TEMPLATE_DESC="Select a specific template style for this menu item or use the default template. If you use an alternative layout save twice for correct function."

and / or at the help-sites:
https://help.joomla.org/proxy/index.php?option=com_help&keyref=Help37:Menus_Menu_Item_Article_Category_Blog
https://help.joomla.org/proxy/index.php?option=com_help&keyref=Help37:Menus_Menu_Item_Article_Category_List

I dont know that.

@coolcat-creations no because my english is not good.

@Sieger66 @coolcat-creations is from germany too ;) So that should not be the issue ?

@Sieger66 @zero-24 Yes - that´s why i proposed it, because i think i would understand you better then ;) My contact is in my github profile ;)

@Sieger66 @zero-24 @franz-wohlkoenig
Seems that the issue from Sieger66 is an expected behaviour and has nothing to do with this PR.
(After assigning a new template style to your menüitem, you have to apply the change to be able to select an override from that template)

Can we set it RTC?

@mbabker as Release Lead can you please have a Look at Question above by @coolcat-creations?

I have tested this successfully and use it in a project

@mbabker ping :)