[#9746] - Issues in "Single article" view when the "Show Unauthorized links" option is set
- Closed
- 9 Apr 2016
- Medium
- Build: master
- # 9746
Steps to reproduce the issue
Create 2 articles, set for registered users:
- 1st article without "readomore" text
- 2nd article with "readmore" text
Create three menu items:
- A "Blog" menu item for the category containing the above articles
- Two "Single Article" menu items, one for each article.
Not strictly necessary, but better to understand what's going on:
- each article should have some content processed by a "content plugin" (e.g. {gallery}...{/gallery})
Try accessing the three menu items with and without the "Show Unauthorized links" options set.
Expected result
Access to articles full text should never be possible.
Actual result
Access to articles full text is possible
System information (as much as possible)
Joomla 3.5.0, Protostar
Additional comments
The following tables explain what can be seen ("raw" means the content has not been processed by the "onContentPrepare" plugin):
Without the "Show Unauthorized links" options:
| Single article view | Blog view | |
|---|---|---|
| Article without readmore | Unauthorized | Article not displayed |
| Article with readmore | Unauthorized | Article not displayed |
So far, so good, but:
With the "Show Unauthorized links" options:
| Single article view | Blog view | |
|---|---|---|
| Article without readmore | Full article displayed "raw" | Article not displayed |
| Article with readmore | First part displayed "raw" | First part displayed |
What's the fuss about that? Where is the problem?
Well... what I thought was the main issue (access to the article's full text if the readmore break is not set) apparently isn't considered a problem but "Expected behaviour", and I'm going to add it to my personal list of "Unexpected Expected Behaviours".
The confirmed (unless this is expected too) issue is that in "Single article" view, when an article is partially displayed (intro text)) as a consequence of it being declared for "Registered" users, the user being "Guest" and the "Show unuathorized links" option being in effect, then the "intro text" is displayed "raw", with that meaning that certain content plugins (e.g.: those based on the "onContentPrepare" event) are not applied to the intro text.
| Labels |
Added:
?
|
||
If by "raw" you mean that the text is not wrapped in a DIV:
<div itemprop="articleBody">
<p>TEXT GOES HERE:</p>
</div>
Then, yes, I have the same on my Article pages. No image and no wrapping DIV.
Intro image not showing J 3.5
On my pages the Articles are set to registered while the Menu items are set to public. I get the intro text but I also want the intro image (which does not display).
....hmmm... no: by "raw" I mean that the content has not been processed by content plugins.
Anyway, in /com_content/views/article/tmpl/default.php, the execution path for "authorized" vs. "non-authorized" items is different and the latter has, IMHO, some other serious issue (see yet another issue I opened, #9491) and the markup is different, which explains the differences you're seeing in generated HTML.
I can't remember if displaying the intro image is part or not of the "secondary execution path for non authorized items"... give me some minutes and I'll check...
I see the term "content plugins" from time to time but I'm not sure what they do.
@rgmears
No: in "single article" view the image is displayed only if the user is authorized and it will not be the "intro image" but the "fulll image". This is "by design".
In blog view, on the contrary, you should have the intro image displayed for all users (can you confirm this?).
Articles in "Category Blog" are not handled (helas!) by the same template as single articles (/com_content/views/article/tmpl/default.php), but by; /com_content/views/category/tmpl/blog_item.php, with different code.
I see the term "content plugins" from time to time but I'm not sure what they do.
A content plugin, as an example, takes something in your article like {gallery}/images/mygallery{/gallery} and transforms it into an image gallery inside your article (provided you have that plugin and it is activated)
The Intro Images display in Blog view: content.
If Intro Text displays for an unauthorized viewer it would make sense, to me, that the Intro Image should as well. But, I'm getting off topic here.
A content plugin, as an example, takes something in your article like {gallery}/images/mygallery{/gallery} and transforms it into an image gallery inside your article (provided you have that plugin and it is activated)
Okay, I use those all the time. Articles Anywhere, loadposition, etc.
If Intro Text displays for an unauthorized viewer it would make sense, to me, that the Intro Image should as well. But, I'm getting off topic here.
what can I say... personally I have my own overrides that are doing just that!
Okay, I use those all the time. Articles Anywhere, loadposition, etc.
Try putting one of those in the "intro text" and tell me what you see...
Try putting one of those in the "intro text" and tell me what you see...
Exactly what I expect to see. See for yourself:
content editors
Here's the "shortcode":
`
{tab Tab Title 1}
Tab ONE text.
{tab Tab Title 2}
Tab TWO text.
{/tabs}
`
I see, but is that "blog" view or "single article" view? The problem I'm talking here is only for "single article" view...
That link goes to single article view. The menu item at the top -- CONTENT -- is the blog view.
The article is registered, the menu item is public.
... that's uttermost strange... this is not what I'm seeing here (see my description above)
Have you protected the menu item (not only article) for "Content editors"?
(btw... editor: none is my preferred one!!)
I used to use CodeMirror but used JCE Editor for that website, as it is aimed at average users, who, for the most part, prefer WYSIWYGs. Maybe JCE is doing something to make the content plugin work properly. I know it wraps everything in < P > tags (which don't show in my "shortcode" above) which are removed in the page code. The TABS become a UL wrapped in a DIV.
Have you protected the menu item (not only article) for "Content editors"?
If by "protected" you mean "registered", then no, the Menu Item is public.
Nope, I tend to exclude that the editor used can have any influence on that.
If by "protected" you mean "registered", then no, the Menu Item is public.
Yes, this... and I'm baffled, as if this is the case, this issue I opened here has no base on which to stand, but this is what I'm seeing in my installation... :-(
I guess I must do yet another new installation from scratch to check this... :-(
Joomla 3.5.x, right?
Perhaps you should first install JCE and see what happens.
As well your shortcode was with a gallery plugin. Maybe it's the problem.
Joomla 3.5.x, right?
Yep.
Care to share your override for the Intro Images?
Can I remove the test code from that "content editors" page?
Care to share your override for the Intro Images?
I'm thinking to share that (here on GitHub), but not right now as I have a couple of things I want to fix before going public. It will happen very shortly, anyway, couple of days max, and I'll advice you directly. Keep in mind that it will be very... different from the standard "Protostar" stuff. I have my own coding standard and probably it will not be very much appreciated here..
Can I remove the test code from that "content editors" page?
yep!
Ahemm... isn't it the case that you have some stuff in your template's "html" directory? That would be "overrides" and they could account for at least some of the differences between what we are seeing...
.
isn't it the case that you have some stuff in your template's "html" directory?
Yes, I have done a couple of overrides. I rearranged where headers display or changed them to H1 instead of H2. They were done for an earlier version; 3.2.X I think. In trying to sort out my Intro Images problem I noticed that some of the J! code has changed.
old version
defined('_JEXEC') or die;
has been replaced with
defined('JPATH_BASE') or die;
The J! TUTOR site is built with a slightly modified version of Protostar, BTW.
hmmmm.... you should check the adherence of your overrides with current code, I guess...
IIRC defined('JPATH_BASE') or die; was used in the "platform", while current code uses defined('_JEXEC') or die;: no big deal, anyway, both check that the file is invoked from inside the Joomla environment and not directly.
Let me know which override you think may be the solution to your trouble and I'll see if I changed it. Got to go now.
1st article without "readomore" text
2nd article with "readmore" text
With 'Show unauthorised' Yes ... then everything in the 1st Article will be seen by anybody whatever its access level. This is because without a readmore all the text is placed in the 'introtext' field in the #__contents table. The 'fulltext' field is only populated when text is placed after a readmore in the article.
Therefore seeing all the article text (when 'Show unauthorised' is Yes) ... is expected behaviour. Because without a readmore then all the text is intro text.
Expected behaviour not a bug.
Addendum
See https://groups.google.com/d/msg/joomlabugsquad/XSvkOLtrMPk/lesmKP51NfwJ
Therefore seeing all the article text (when 'Show unauthorised' is Yes) ... is expected behaviour. Because without a readmore then all the text is intro text.
Expected behaviour not a bug.
Yes, you're probably very right, but I had expected that in the absence of a readmore none of the text would had been displayed (as a cautionary principle), but probably that's just me being a bit paranoid...
In any case the second bug I'd say is confirmed:
- create a custom HTML module with just
<h1>Hello!</h1> - assign it to custom position "test" for all pages
- in the intro text of a protected article put
{loadposition test} - Access to the article through the blog and then as the single article
- See the difference? :-)
Will check when I have time but gut instinct is that it is to do with ' Prepare Content'
... gut instinct is that it is to do with ' Prepare Content'
Nope: you have that in the module, not in the article/blog/etc, and setting it in the module doesn't change a thing...
create a custom HTML module with just <h1>Hello!</h1> assign it to custom position "test" for all pages in the intro text of a protected article put {loadposition test} Access to the article through the blog and then as the single article See the difference? :-)The Title showing twice you mean ? That is a separate issue ... have come across that before. here was a reason given for that. Am searching to see if I can find it. @mbabker answered it in the devs mailing list somewhere if I remember correctly.
@Webdongle
Heck, no... in "Single article" view I have {loadposition test}, verbatim, not "Hello!"...
(memo to me: call the exorcist for my PC)
@smz I have the same with loadmodule:
{loadmodule mod_bt_login,BT Login}
Shows the shortcode not the module on content editors.
Did you got my mail?
Yes.
I will check out your template ASAP.
For the leadership/maintainers:
I'm going to change the title/description of this issue as it currently doesn't represent the main scope of it.
If there is a problem with this, please let me know and I'll close it and open a new one...
| Title |
|
||||||
Better to close it and start a new one - with so many comments that are not
goign to be related to the new title it will be hard to follow
On 9 April 2016 at 14:01, Sergio Manzi notifications@github.com wrote:
For the leadership/maintainers:
I'm going to change the title/description of this issue as it currently
doesn't represent the main scope of it.If there is a problem with this, please let me know and I'll close it and
open a new one...—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#9746 (comment)
Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/
OK!
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-04-09 13:58:31 |
| Closed_By | ⇒ | smz |
Please note that the Menu items above have not been protecetd: I think this is fair as it is not always possible to create "single articles" menu items in order to protect the content and one should be able to rely on what is declared at the article level...