The single article menu item is already specific to a layout. An alternative layout doesn't make any sense here.
If you want to create a menu item using your alternative layout, you need to add a corresponding xml file to it. Then you can choose it as an own menu item.
See https://docs.joomla.org/Layout_Overrides_in_Joomla

The way you've described requires then to use a custom layout that all single article views must be assigned to a menu item, whereas this change (if I've understood it right, admittedly this parameter/field isn't one I've worked with much) allows it to be defined directly in the article's settings and doesn't bind the possibility of an alternative layout to the menu system.

Thanks for this PR it is very useful and consistent with other com_content views

this change allows it to be defined directly in the article's settings and doesn't bind the possibility of an alternative layout to the menu system.

@mbabker No, it's not about the article settings. You already can specify an alternative article layout in the article settings itself. This is about the single article menu item itself. Technically it's even an alternative layout for the specific menuitem for the "default" layout.

@brianteeman No, it's not consistent with any other views anywhere in core. It makes no sense because you already selected a specific layout with the menu item itself.
Also we don't use alternative layouts in menu items so far. At least I'm not aware of a single one. We use them at the category and article settings itself (not the related menu items).
Eg for a category view, you can't select an alternative category layout.

Any PR that makes things more consistent is welcome to me. As far as I know settings are determined by the menu item allowing to set it there or decide to use either the item or component setting.

By the way, this is what the options tab of the component has to say:

These settings apply for article layouts unless they are changed for a specific menu item.
Choose a Layout

Suggesting this can be overridden at menu item level!

Suggesting this can be overridden at menu item level!

Yeah, you override it when you create a menu item for a single article. Because that menu item is tied to a specific layout ("default" in this case).
In Joomla core every menu item you can create is specific to a layout. Because the XML file defining the menuitem is the one at the layout level.
That's why you can select between two different menuitems for the category view (blog and list) because you choose the layout for the category view with the menu item there (overriding any settings done elsewhere).

Indeed the trick applied to the category blog/list is just wrong! You should be able to pick an alternate layout just like any other situation. Obviously you should only be presented with the blog layouts or list layouts. Probably requires a blog and list view instead of the current category.

No wonder this very difficult to understand and document. It just confirms that the implementation is wrong!

For Single Article menu item I agree with @Bakual . There the layout already selected, I not see much sense allow to do it again ...

But it can be a good idea to be able to select the layout for Single Article layout in the Blog Menu item, so you can specify "full view" layout for the blog article ... there also just need to add one more menu option

Indeed the trick applied to the category blog/list is just wrong!

Nah, it was a decision that goes back to I think 1.6 that menu items are based on layouts.
They can also be based on views (metadata.xml) or component (don't remember the filename here) but for core we always used the layout approach since then.
One can agree or disagree with that of course, but it's the intended way for quite some time now.
Main reason probably was that you can have different (custom) parameters for each layout/menuitem.

In my own component I use view menuitems and let the user decide on a layout in the component and menuitem settings, but you face other issues there due to the way Joomla menus are working.

But it can be a good idea to be able to select the layout for Single Article layout in the Blog Menu item, so you can specify "full view" layout for the blog article ... there also just need to add one more menu option

There are already two PRs open for that. Also created by @shamsbd71.
It will be a new feature and certainly needs also good testing with behavior how layout settings in article itself will be overriden (article should take precedence over menuitem over global setting)

It is not a matter of specifying it again. Each menu item type has a default layout (most of the time called default in core components). Obviously when not overridden it would take that one.

Strikes me as strange to have the possibility to create a template override but not for an alternate layout. Just because a mistake was made at the time J1.6 was introduced, not the only one either.
Do see a tendency to keep them instead of acknowledging them and accepting fixes!

Each menu item type has a default layout

That's the point. if i want to make a different presentation, i had to create a new xml and view both for category list, category blog, single item.
But when i'm creating a menu, its dedicated. It can save a lot of time and work if i have these options for regular menu?
if by making a very single change can save us a lot of work : creating xml and apply all things and maintain with others updates and joomla core options those will be applied time to time.

OT:

Indeed the trick applied to the category blog/list is just wrong!

I agree with that. Settings in this combined view are confusing and conditions in model annoying.

Probably requires a blog and list view instead of the current category.

Yep!

Having bloig and list using the same view is absolutely correct. The data that is shown is identical. Just the display is different. That's exactly the job of a layout. And since they have different parameters, we need two XML files as well.

I don't unterstand what the problem is with creating an XML file. As soon as it is there, the alternate layout becomes an alternate menuitem and you can do what you want.

... i had to create a new xml and view both for category list, category blog, single item.

copy paste copy paste copy paste ... easy ... what the problem?

Now imagine situation.

• You make the menu item from Default.xml layout and selected there MyFancy layout,
• then someone create menu from Another.xml layout and selected HisFancy layout ...
• after some time you decide that you need additional parameters for MyFancy and make MyFancy.xml ... but for apply it you need create new menu
• then someone else will make menu item from MyCool.xml and select your MyFancy layout...
• and so on ...

after all you will end up to debugging to find where thing comes from

Here is two Single Article Menu and New Article Options
1. Menu options for single article

2. Article option when we create

we have all options repeated everywhere.
1. Global options
2. Article Edit
3. Menu Item

** Category edit is missing. there suppose to be some options too :(

so to be consistent, the common options should be only in once in one place or it should be everywhere it belongs to.

to avoid argument : please think for regular process. this is how we deal with it.

and

when we need extra parameters for any new item, then our existing solution is like this

Create new.xml, new.php
and for your information:
joomla form field type componentlayout only show those layouts in dropdown when it dosent belongs to any xml.

so if you have a layout thats for new.php. you will not see that from default.xml menu items.

I'm far from saying the current system is perfect. But I think this PR makes it even worse.
Ideally, common parameters would be defined in components or view level and Layouts only defined layout specific params.

The reason why the componentlayout field doesn't show alternative menuitem is likely because they are supposed to have custom parameters. However that thought is flawed anyway. We may change that so all Layouts are shown.

@Bakual should this be tested?

Imho it should be closed. But since I already closed it once and someone else reopened it again, I'm not going to close it myself again.

Thanks @Bakual, so i gonna ask @brianteeman if this PR should be tested.

Unfortunately, @brianteeman will not be able to answer it for another two months or so.
pinging @joomla/cms-maintainers

Asking @brianteeman if this PR should be tested.

As this PR has had no update in well over a year, it will be closed in a few weeks as abandoned if it doesn't start getting attention.

If this PR get no Response, it will be closed at 22. June 2017.

closed as stated above.

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/8603