@infograf768 Just tested Protostar and Beez3. After patch it was like this:

• With Protostar all works as expected, i.e. I see the intro text only and the "Register to read more" button when not being logged in, and after login I see the full article text without the button. When I log out then I again see only the introtext plus the button.
• With Beez3 I also see the button after having logged in, it appears between the intro text and the rest of the article. And when I log out, the full article text with button is still shown after log out.

Am not sure if this strange behavior with Beez3 is an issue, or if there is a mistake on my side, so I do not want to mark the test result as unsuccessful.

Can you check if you can reproduce my Beez3 test?

If the site works in SEF mode, does it then not redirect to none SEF urls? Should it really be like that?

@laoneo
Nope, if in SEF mode, it will redirect in SEF mode. Please test for yourself.

@richard67 You are correct. Please test again.

When patch applied : Beez3 shows the complete article even when not logged in.

When patch applied : Protostar OK

When patch applied : Tested on 3rd party template (without com_content overrides) OK

@infograf768 I can confirm @mikeveeckmans findings for the single article view with Beez3:

When being on the single article page, the full article (without button) is always shown, regardless if logged in or not.

In the category blog view, the display is correct in Beez3, i.e. intro text plus button if not logged in and complete article without button if logged in, with correct display change after login/logout.

With Protostar still all is correct.

@richard67 @mikeveeckmans i think #9964 is exactly to solve that issue across templates.

folks, beez3 needs more work than just the return issue when read more as quite a few changes were introduced in core without taking. care of beez.
i suggest to separate it from this patch. I can change the title if desired.

@infograf768 I agree. Shall I wait for some further commit before testing again? Or just set my test result to success because it works with Protostar (and others not having any overrides) as it is now?

@infograf768 same as @richard67 here ;-) i tested successful on protostar and 3rd party

Please, @richard67 and @mikeveeckmans
Indeed, please set it to Success on https://issues.joomla.org/tracker/joomla-cms/9959

I have tested this item successfully on f254d58

When patch applied : Protostar OK

When patch applied : Tested on 3rd party template (without com_content overrides) OK

I have tested this item successfully on f254d58

@richard67 and @mikeveeckmans

I will rtc this, but I may have found out something interesting for Beez3:
I just copied core default.php (after applying this PR) and overwrote in beez3 html/com_content/article/default.php with the core one and it seems it now works fine for a single article. Can you test?

RTC. Remains Beez3 to debug.

@infograf768 I guess you mean you copied components/com_content/views/article/tmpl/default.php (patched) to templates/beez3/html/com_content/article/, right?

Yes, the one produced by this patch.

@infograf768 Funny: It works with the copied file for beez3. When comparing the files (core file and beez3 override) before the patch, they look so different that the last thing what I would expect is that it works with the copied core file. But it does.

then i think we can safely delete the beez override.
@wilsonge what do you think?

@infograf768
JM, if you look at the single article view (/components/com_content/views/article/view.html.php) at lines 70-71 you will find the following:

// TODO: Change based on shownoauth
$item->readmore_link = JRoute::_(ContentHelperRoute::getArticleRoute($item->slug, $item->catid, $item->language));

Isn't this a sign that something was left behind there (and probably in other views) about the handling of readmore_link?

And shouldn't my considerations in #9964 (there are things that do not belongs to templates, but views) do apply to this case too?

@infograf768

I made some test and I found what I think is a slightly more elegant implementation of the solution you found:

You can put your corrected routing code in line 71 of /components/com_content/views/article/view.html.php:

$item->readmore_link = base64_encode(ContentHelperRoute::getArticleRoute($item->slug, $item->catid, $item->language));

then at the template level just use:

<?php $link->setVar('return', $this->item->readmore_link); ?>

I've tested with the "Single article" and it works

"category views" are another story, in the sense that the 'readmore_link' property is not set for article items handled by "category views"

I overcome this by inserting the same above line at line 94 of /components/com_content/views/category/view.html.php

This put the properties of articles generated by "single article" and "category" views in sync as far as regards this aspect.

Then we can use <?php $link->setVar('return', $this->item->readmore_link); ?> also for category views.

I've still to check what should be done for the other templates in which you inserted your code (very little, I guess, beside referencing $item->readmore_link...)

I think that the solution I described above is more similar to what was done before merging the PR that fixed the security issues related to the "return" parameter in the readmore link. Edit: no, I checked and readmore_link wasn't used even before that. Wondering when it was used and when felt in disgrace...

I also think that if we don't go this way the $item->readmore_link is orphan property, unused anywhere it is expected to be used.

As a last consideration, I'm wondering if this could not be the occasion for standardazinig on the usage of the joomla.content.readmore JLayout, which is used in "Category Blog" but not elswhere (and hence the visual difference for readmore links in various templates)

@smz
My thought is that we are already enough not B/C with the JUri::isInternal() to now introduce such a change in the view.html.php

Also i looks like $item->readmore_link is a remnant of 2.5 where the value was used in default.php.
In any case, this PR just solves the bug. Its purpose is not to rewrite the functionnality. This, if judged necessary should be for another PR.