~... and where is the endif or else for <?php if ($params->get('access-view')):?> @ line 93?
... unsure... botched indentation... really difficult to read... :-/~
Forget about this... not a problem.

Actually there is more to do, I guess:

Take line 89:

<?php if (isset($urls) && ((!empty($urls->urls_position) && ($urls->urls_position == '0')) || ($params->get('urls_position') == '0' && empty($urls->urls_position)))
    || (empty($urls->urls_position) && (!$params->get('urls_position')))) : ?>

that's totally broken: the logic is wrong and, beside that, urls_position is not to be found into the $urls object (you only have links and text there...) and good day trying to override the globally set urls_position with article's settings!

What I did in my override is to move the $attribs=json_decode($this->item->attribs); statement at the very top of the template and then:

NOTE: wrong code here: see amended version in next post.

foreach ($attribs as $key => $value)
{
    if (!empty($value))
    {
        $params->set($key, $value);
    }
}

Done! From there on no need for twisted logic: just use $params->get()

line 89 becomes:

if (isset($urls) && $params->get('urls_position', 0) == 0)

easy!

line 146 (the one giving the ugly Undefined property) becomes:

if ($params->get('alternative_readmore', '') == '')

problem solved.

And you'll be sure that the options you set at the article level will override the global settings (isn't this what we want?)

NOTE: Although fixing some things, this actually have consequences. See two posts down.

Sorry, I just realized that the code I gave above:

foreach ($attribs as $key => $value)
{
    if (!empty($value))
    {
        $params->set($key, $value);
    }
}

is wrong

With that code you cannot override a global parameter set, say, to 1, with a local (at the article level) value of 0 as 0 is considered empty() and thus it doesn't have a chance of overriding the global parameter.

Correct (hopefully) code should be:

foreach ($attribs as $key => $value)
{
    if ($value != '')
    {
        $params->set($key, $value);
    }
}

Sorry for bumping this issue which doesn't seems to be of much interest, but while writing my own overrides to fix this, I discovered something new which can itself be a separate issue with deeper consequences and for which I don't have a solution (particularly at the overrides level).

To better comprehend what I'm trying to explain, please have a look at the following (incomplete) logical combinations table which describes what happens when changing an article option ("show_author") at the global (component) level, at the article level and at the menu item (single article) level. I'm also adding what I can get at my override level ("smz" column)

T = Show
F = Hide
X = Use Global

In the above table you can clearly see that what is declared at the article level is royally ignored by Joomla.

But there is something more. IMHO the logical behaviour should be that the hierarchy be:

Global < Article < Menu item

That is, what is declared at the global level is overridden by what is declared at the article level and this is overridden by what is declared at the menu item level.

The problem is that the "article level parameters override logic" is performed in the article template (this is how it goes today), but once we are inside article templates what is defined at the global level has already been overridden by what is declared at the menu item level, and the best we can achieve is to override this already combined parameter with what is declared at the article level (which is what I'm achieving in my column "smz"), and hence the hierarchy will be:

Global < Menu Item < Article

Questions are:

• Is this a bug? (IMHO it clearly is...)
• Should it be fixed? (IMHO it surely should)
• Is the "Global < Menu Item < Article" hierarchy acceptable? (I hate this)
• Are there B/C issues to address? (sure there are...)
• Could possible B/C breaking differences in behaviour be addressed by the introduction of a new global parameter (Old/New behaviour)? (Sob!)

Just in case anybody's reading, I understood that although the problem does exist (try the "Show author" thing above, if you are interested), this (I mean the article template) is not the place where the issue must be solved.

The solution to the problem belongs to the view, where already parameters (options) are merged, but where evidently something goes wrong...

#9801 should solve the parameters hierarchy issue.

The template is still to be fixed for the "Undefined property" issue.

So the "hierarchy" thing is now being discussed in #9801.

This leaves us with the remaining issues concerning /com_content/views/article/tmpl/default.php:

1) there is an "Notice: Undefined property: stdClass::$alternative_readmore" error generated at line 150 (it was 146 at J! 3.4.8): this is due to using $this->item->alternative_readmore, which is not set: that thing is today in $attribs, and not in $this->item.
IMHO we shouldn't need to use $attribs (and hence json_decode it from $this->item->attribs) in the template. That alternative_readmore belongs to the params, I think, and should be ready available to template developers, but this is another story, I guess...

2) Line 91 (the URLs thing) is broken, in many senses: the logic is wrong and, beside that, urls_position is not to be found into the $urls object (you only have links and text there, but not urls_position)

Now, I will be most grateful if somebody else could go on fixing the above for a couple of reasons:

• Next week I'll be very busy and probably don't have the time to care about that too much.

• I'm quite senior, 61, my sight is not as it used to be and in templates I'm loosing myself between the scores of <?php ... ?>. Due to that I write my templates differently (see: https://github.com/smz/tpl_pantarei if interested). For me putting my hands in standard Joomla templates is a royal pain in the back, and hence my request for somebody else to take over that...

Thanks!

Closed as we have a PR to resolve the alternative readmore text #11473