Somewhere in September a problem was introduced into blog displays of com_content (section, category and frontpage).
The problem is that the article parameters are over riding the menu parameters.

@8987 there were a bunch of changes to com_content

in the three view.html.php files


$params->merge($aparams);

was changed to
$item->params->merge($aparams);


I found that by reverting this change to the three files that the display is correct.


See the following related threads (among many)

http://forum.joomla.org/index.php/topic,230803.0.html
http://forum.joomla.org/index.php/topic,225022.0.html

and the following tracker issue:

7798

Agreed. Thank you for this.

I changed these three files, as per your directions:

• components/com_content/category/view.html.php
• components/com_content/frontpage/view.html.php
• components/com_content/section/view.html.php

Tested it and it does, indeed, prevent the article parameters from overriding the menu item parameters, thus bringing it back to prior behavior in the v 1.0.x series. This is backwards compatiable. I would like to see the change made to core.

Thanks!
Amy

Oh, hackwar .... :p

I would suggest that you ask him about this as it looks like those changes were to fix this issue.

No, you ask him.

There are lines and lines of changes in that commit. 

Two middle-aged American women trump one young German lad. Look it up. It's in the rules. 

Let's get the Dutch involved 

RobS his view on parameter cascading:
http://forum.joomla.org/index.php/topic ... msg1062979

Louis his view:
http://forum.joomla.org/index.php/topic ... #msg797970

I think Louis is right, Global exceeds Menu parameters, Menu paramters exceeds the Item parameters. This has been so from the start in 1.5. I'll try and get this confirmed ASAP. See whats the desired/intended behaviour.

Do not trust the Pusher Robot. He is malfunctioning.  Menu parameters are the answer.

So, if I understand those two posts correctly:
Rob: Menu Params beats Article Params beats Global Params
Louis: Article Params beats Menu Params beats Global Params

Poor global params!  Always beaten....  Please correct me if I'm wrong.

I seem to recall someone reporting the other bug - article params where being discarded.  I personally think menu params should prevail ( think multiple menu links to the same article ) but eventually it has to be either one behavior or the other.

tcp

It's a bit unclear to me what Louis is saying since he is dealing with a specific problem but I think he is saying the same thing that Elin and I are saying. (I wish he had mentioned the menu item page and the article page in his description; that would have helped me understand the relevance to this discussion.)

There is one point that I think is easy to be confused by, at least I know I was. Parameters have always been a two-layer system, not a three-layer system:

• Globals are first, then menu item parameters override Globals at the menu item level.
• Globals are first, then article parameters override Globals on the individual article pages.
• Menu item parameters have never been referenced for an individual article page (and still are not today.)
• Before 9-22, individual article parameters have never been referenced previously for a menu item (but, they are today).

The last point is the crux of this discussion. That is the first time that Joomla! parameters have been implemented as a three layer system. Now, at the menu item level, global parameters are first, then menu item parameters, and finally, article parameters take precedence.

The implication of this change is that it is no longer possible to achieve a consistent blog layout because article parameters override menu item parameter selections. When article parameter choices are made, people must be mindful of menu item implications (tcp's point.)

I do see some benefit from having more sensitivity at the menu item level for articles. Honestly, I don't think either way is perfect or "correct." But, I don't see this change as an improvement because it is not offering more choice - it's just changing the default behavior. In doing so it moves us away from backwards compatibility and is causing confusion with end users.

I think Elin made a good suggestion. If we are going to try to improve menu item options by allowing article preferences to override menu item choices, add a parameter at the menu item level that toggles this behavior. That might be a good solution and result in a real improvement. Otherwise, if someone needs menu item layout customization, it will likely need to be implemented as another view. That's the beauty of this new architecture - it's relatively easy to do so.

Thanks very much for considering this seriously.
Amy

My understanding of how it is supposed to work:

Article trumps everything in an article vew

In blog view, menu trumps article (which gives the consistent layout Amy mentions)

Time to call in the architects, I'm lost in params...

Sending an e-mail to the dev list so they can check on this subject.

Whatever Louis says he meant to happen, he is the one who put the line in the way it was originally back in May.

The system is meant to operate as follows.

Each component gets a configuration that acts as a global fall back configuration for anything happening within that component's context.

Each menu item linking to a component gets an opportunity to override the global fall back configuration for that component.  This allows us to say that anything falling under a particular menu item (or configuration) of the component will behave in a certain way.

Each entity (or article in this example) also has some configuration settings that get to override all other settings.  If i decide that an article should never display a PDF icon then that should transcend any other configuration I have.

In general look at it as concentric circles.  We go from the most broad configuration and filter down to the most fine grained configuration.  In the global component configuration you know nothing about the specific articles or the way you intend to display each one, but you do know in general how you want things to operate... so you set defaults.  As you create different menu entries you create something like sub-sections of your site with specific configurations catering to that particular sub-section.  It is more specific and therefore will override the global configuration.  At the article level you know exactly how you want your article to be displayed and therefore you set things specific to that article.  If you don't have strong opinions then ti should stay as "Use Global" which would use the menu configuration or if that is set to "Use Global" it would use the global component configuration.

Hope that helps,
- Louis

Point of clarification, please, Mr. Landry, sir:

Are you saying that the article parameters *should* override the menu item parameters? That's the real question here.

Thanks!
Amy

Totally agree with this setup (even though it's not really clear in the backend, and I think we'll get lots of questions on this). The same system is used in directories. The further away a relation is, the less important the settings on it. This would mean in order of importance:

article
menu
global

If explicitly set, yes... article parameters take precedence over menu parameters.

- Louis

Tonie -

To see if I understand you correctly, you are proposing parameter values be determined, as follows for menu items, from lowest to highest priority:

- Global Parameters - Menu Item Parameters - Article Parameters.

For Article parameters, parameter values would be determined in this order:

- Global Parameters - Article Parameters.

Is that correct?


+++++

Tonie and Louis -

Also, I want to confirm that you agree that in the J! v 1.0.x series, Menu Item Parameter values are determined as thus:

- Global Parameters - Menu Item Parameters.

Article Parameter values do *not* come into play for menu items in the J! v 1.0.x series. These were also not part of J! v 1.5 until the September 22 change Elin identified above.

Just want to make certain we all understand things the same way - I'm not advocating a specific implementation at this point.
Amy

yup

Thanks Louis.

Amy

On the one hand, just so long as it is documented, cool.

On the other, the item part of a blog view is very different than the actual article view.
So I actually don't think it is so clear which way the logic should be. The blog view is a special set up.

The logic louis is using makes sense in the list view. That  seems clear and is working right now.

I just don't think that it totally makes sense from a webmaster point of view for the blog view to work in that way. It forces you to give up setting special parameters on your articles if you want the blog view to look decent.

I agree with you, Elin. Plus, it seems odd to me to have a lowest level of drill down detail (an article) override a summary view (a set of articles).

Anyway, I agree with your first point, as well: at least it's documented, now. There's not really a "right way", but we now understand it's different than it used to be and it's intended to be different. So, when people ask where to find the article parameters, we can tell them that article parameters have been hidden because they are more powerful than they used to be.  If they can't find them, they probably ought not to be using them. I do believe that is what tcp's well articulated warning was telling us.

It's all good,
Amy

Amy, you can just make a different view you know. 

I guess I have to rewrite the faq.  So glad I gave Rob credit. 

I know that. A friend of mine showed me how. It's sweet!
Amy

Okay, I had a long talk with Louis in which he attempted to explain this to me.

I am going to attempt in a few days to write up something for the FAQs that explains how this works, and then I will link that here.
Also, if someone who knows how to do a layout over ride would do one for the tips and tricks forum that produces the previous behavior (all of the items in a blog being displayed with the menu parameters)  that would be so helpful to have for linking to.

In the meantime, there are many reports here and in the tracker that reflect the confusion on this issue which I think is made worse by some UI issues that I want to think about. 

So, I say, all those related issues go into closed.  Is that agreed?

Can I conclude that this is now solved, and that there is no actual bug? So...I can close this as Resolved?

Thanks for picking it up Elin, to make it a FAQ. I can help clean up related reports on forum and tracker...

I think so.

look at 7798 7208  to start.

Sorry I just have a question and this seemed a good thread to ask it in...

If there is a config variable that is type 'text' and it is set at the component level, when you get to the menu item there isn't an option to use global. So if the field is left blank at the menu item level, it overrides the setting at the component level and the parameter ends up being null.

This isn't a problem with anything core that I know of but it's something I am dealing with in custom extensions and I'm trying to figure out a way around it.

Marking as Resolved and moving as such...

wow, why talk about this so much, it is so simple....