Please check your template's layout override, or test this against one of the core templates (Protostar uses the default markup and Beez3 has a layout override). Many of these checks are performed in the layouts so if they aren't implemented correctly there then the layout must be updated.

I checked the override in gantry4 and could not find any difference in logic regarding the readmore button. Furthermore I checked Protostar and experienced the same issue as described in this bug report.

I just made a quick test with 3.8.12-dev, PHP 7.2, Template Protostar.

I can confirm that setting "Use article settings" works wrong with these settings:
Global: No
Article: No (or Use Global)
Featured menu: Use article settings

Introtext and "Register to read more.." are displayed but shouldn't.

@infograf768 Maybe related somehow(?) #19406

@ReLater and @Hg347

#19406 Test were done when the Featured Menu Item Show Unauthorised Links is set to Yes.
It did not consider at all its settings set to No (or Global (No) )

Global is set to No

1. Featured Menu Item Show Unauthorised Links is set to Yes.
   => The settings for the articles is NOT taken into account. Menu item settings is deciding.
   => The article intro will display with a register to read more.
   That is expected.

2. The Featured Menu item Show Unauthorised Links is set to use Global (in our case, it is equivalent to No). UI shows Global (No) in the field.
   => The settings for the articles is NOT taken into account. Menu item settings is deciding.
   => Therefore the article intro will NOT display.
   That is expected.

3. The Featured Menu item Show Unauthorised Links is set to 'Use Article Settings`
   => The settings in this case should depend indeed of the article settings.

Case A: If the article Show Unauthorised Links is set to Yes
=> Therefore the article intro will display with a register to read more.
Case B: If the article Show Unauthorised Links is set to No
=> BUG: article intro will display with a register to read more. WRONG
Case C If the article Show Unauthorised Links is set to Global (N0)
=> BUG: article intro will display with a register to read more. WRONG

Therefore we have to solve the 2 last cases, i.e. the article settings are NOT taken into account when the Featured Menu item settings is set to 'Use Article Settings`

Have not tested, but it may be the same issue when using blog.

~~~I may have an idea.~~~
~~~Will look at it now~~~

I am afraid no.

When doing #19406 I basically copied the code in category blog and I confirm we have the same bug there.

The only possibility I see is to remove the setting use_article for show_noauth in blog and featured views. Because it's a unsolvable(?) bug.

Let's say we set filter.access to false if show_noauth is use_article.

filter.access is used inside the articles model for the db query to get all relevant articles. If there's set a $limit value in getItems you get a specified number of articles.

One cannot remove articles later in the view that evaluates show_noauth for any SINGLE article and maybe doesn't display it.

Because it's a unsolvable(?) bug.

It very well may indeed be.
@mbabker @Bakual What do you think?

I never used that setting myself. So will not comment on the expected bevahior or what would be wise to do there.

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

closed as having Pull Request #21450

Well, I don't think that is a valid solution. Also my initial post is not read carefully.
Basically that switch "show unauthorized links" as it is currently implemented in production - globally or per menu, is just switching all unauthorized article intros on/off. That is not expected from user perspective. Let me elaborate that further

I expect the selected categories and the menu item type to be taken into account.
And actually I would like to have and use the per article setting to intro only specific unauthorized articles.
That is at least my perspective and I assume that was the initial intention / requirement. Btw, could someone link to the initial requirement (user story) of that feature?
Please do not cut functionality only because it is tricky to implement. In other words: When fixing a bug the original requirement should not be changed.

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

reopened for further Discussion.

Well, I don't think that is a valid solution. Also my initial post is not read carefully.

It's not that we don't understand the problem theoretically but the practice is showing that it's not possible at the current state of code (= Joomla) to solve it. And I don't think that it's possible in the future

• without additional database requests and code that will decrease performance in a not acceptable way
• or without a complete rework of the system how articles collections are fetched and that has to be backwards compatible.

Many extensions (e.g. modules) are using the same code base to fetch articles (= so-called articles model).

Anybody can provide a better solution.

Could you please point me to the relevant developer documentation?

Based on code history, 'Use Article Setting' option was added to menu items by mistake 014b52f#diff-6ffd3a7d782585864181873aea4c2c1fR306.

Yep, we should have tested more. That one was useless and passed with the others.

"Let's say we set filter.access to false if show_noauth is use_article.
filter.access is used inside the articles model for the db query to get all relevant articles. If there's set a $limit value in getItems you get a specified number of articles.
One cannot remove articles later in the view that evaluates show_noauth for any SINGLE article and maybe doesn't display it."

Could someone elaborate that more, that I can understand the technical issue here? I would like to search for a solution too.

• Which source files are involved?
  • controller files
  • model files
  • view files
  • config / meta files
• Why has use_article to be removed?
• when all articles are available in view, is it still possible to filter the category accordingly or must that happen earlier in the model?

  ---

  _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/21407.}

@Hg347

Could someone elaborate that more, that I can understand the technical issue here? Which source files are involved?

I myself think that Joomla GitHub is the wrong place to explain the basic MVC design of Joomla (Model-View-Controller). And common Joomla component design.
Maybe somebody else?

The main thing that I'm talking about starts here:
The view calls the relevant items from the own model:
https://github.com/joomla/joomla-cms/blob/3.8.11/components/com_content/views/featured/view.html.php#L55

https://github.com/joomla/joomla-cms/blob/3.8.11/components/com_content/models/featured.php#L116

which calls the getItem method from the parent articles model.
https://github.com/joomla/joomla-cms/blob/3.8.11/components/com_content/models/featured.php#L125

https://github.com/joomla/joomla-cms/blob/3.8.11/components/com_content/models/articles.php#L557

which uses the filter settings for the database request. The filter settings have been defined earlier depending on the global and/or current menu item settings.

Why has use_article to be removed?

Because it's a bug by mistake ;-)

if filter filter.access for the database query is false the $items collection contains ALL registered articles, too. There is no trivial way to manipulate the database query at this point that it also respects the setting for show'_noauth for a single article (JOIN or something).

This collection doesn't contain ALL articles of the database. Just the number that is needed for the frontend page. Let's say 20

And let's say that we now check the setting of param show_noauth for any single article in the collection and you remove an article from the collection. Afterwards you have 19 articles. Maybe OK for a special case.

BUT: You will open a can of worms (e.g. wrong pagination) for many other cases.

I better paste the comment that I posted in [#27856] - Category blog Access, since it seams to be a related issue.

As I've mentioned in the thread at the Joomla Forum, the "Use Article Setting" in the Menu settings doesn't make sense from a logic point of view. I found the following comment that might explain why.

Based on code history, 'Use Article Setting' option was added to menu items by mistake 014b52f#diff-6ffd3a7d782585864181873aea4c2c1fR306.

From a logical point of view it would make more sens that the the setting at the Global level is inherited to the Menu level and the settings at the Menu level is inherited to the Article level, then the "Use Article Setting" could be omitted.

Since the intro of articles, which are restricted to registered users, are shown even when the setting at the Article level of "Show Unauthorised Links" is set to No, which shouldn't be the case. This make me think that the problem might be the SQL query.

Unfortunately, I don't know how the system is built, but it would be of interest to see how the SQL query looks.

Been made aware of this ticket by @Webdongle

As described by @ReLater, a fix for this issue (and I tend to agree that it actually is an issue because it does not match a users expectation) isn't a straightforward thing. The articles are retrieved using one massive SQL query; filtering this last based upon a parameter of an article (that might be set to "use global" which makes stuff even worse) is complex and has a big performance impact.

@SniperSister
So is it an issue or does it need to be fixed by jsst? Who fixes it?

After taking a closer look at the issue, I tend to agree with @ReLater that the best option is to remove the use_article option in the parameter.

@joomla/security any other ideas?

mmmmmmmmm Remove a feature (that used to work) because it stopped working. Is that not going backwards?

Why not change the code (that makes the action) when 'Use Article settings' is selected?
It used to work correctly ... when 'Use Article settings' was selected it took the value of that setting..
Is there not an IF statement that relates to that selection ... what is the condition for that IF statement?

Been made aware of this ticket by @Webdongle

As described by @ReLater, a fix for this issue (and I tend to agree that it actually is an issue because it does not match a users expectation) isn't a straightforward thing. The articles are retrieved using one massive SQL query; filtering this last based upon a parameter of an article (that might be set to "use global" which makes stuff even worse) is complex and has a big performance impact.

It would be interesting to see what the massive SQL query looks like :)

"Use Article settings" is not logical and I believe it's part of the problem.

"Show Unauthorised Links" seams to work down to the Menu level. It's the selection at the Article level that doesn't work.

Without knowing how the code is written my logical solution would be:

• Delete the "Use Article settings" from the Menu level
• Change "Use Global (Yes/No)" at the Article level to "Use Menu (Yes/No) - The Global setting is inherited to the Menu setting and it would make sense if the Menu setting is inherited to the Article setting and not the Global setting
• Ad the missing selection at the Article level in the SQL query

I can't see the this could complicate things too much since the only thing that is needed to be added is a condition where an article is not going to be shown if "Show Unauthorised Links" at the Article level is set to "No". With this simple solution one should also remove the Yes alternative in the "Show Unauthorised Links" at the Article level, because to be able to show articles they need to inherit Yes from the Menu level to be able to be shown.

It would look like the following:

Global - Articles - "Show Unauthorised Links":
Yes
No

Menu - Options - "Show Unauthorised Links":
Use Global (Yes/No)
Yes
No

Article - Options - "Show Unauthorised Links":
Use Menu (Yes/No)
No

'use article settings' is logical because (with the exception of meta data) menu settings override Article settings.

So for consistency 'show unauthorised' (in category blog menu) should override the Article setting.

Therefore 'use article settings' is logical and necessary. Otherwise individual control of Articles showing/hiding intro text would not be possible.

⁣Sent from BlueMail ​

On 10 Feb 2020, 23:21, at 23:21, phpwebtech notifications@github.com wrote:

Been made aware of this ticket by @Webdongle

As described by @ReLater, a fix for this issue (and I tend to agree
that it actually is an issue because it does not match a users
expectation) isn't a straightforward thing. The articles are retrieved
using one massive SQL query; filtering this last based upon a parameter
of an article (that might be set to "use global" which makes stuff even
worse) is complex and has a big performance impact.

It would be interesting to see what the massive SQL query looks like :)

"Use Article settings" is not logical and I believe it's part of the
problem.

"Show Unauthorised Links" seams to work down to the Menu level. It's
the selection at the Article level that doesn't work.

Without knowing how the code is written my logical solution would be:

• Remove the "Use Article settings" at the Menu level
• Change "Use Global (Yes/No)" at the Article level to "Use Menu
  (Yes/No) - The Global setting is inherited to the Menu setting and it
  would make sens if the Menu setting is inherited to the Article setting
• Ad the missing selection at the Article level in the SQL query

I can't see the this could complicate things too much since the only
thing that is needed to be added is condition where an article is not
going to be shown if "Show Unauthorised Links" at the Article level is
set to "No".

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#21407 (comment)

'use article settings' is logical because (with the exception of meta data) menu settings override Article settings. So for consistency 'show unauthorised' (in category blog menu) should override the Article setting. Therefore 'use article settings' is logical and necessary. Otherwise individual control of Articles showing/hiding intro text would not be possible.

I don't agree that "Use Article Settings" at the Menu level is logical. Especial not from the user's (administrator) point of view. As an administrator I'm used to set the Global settings, which then is inherited down to the final level (Article level). Even if the setting at the Article level should work, then it's completely illogical that one has to go to the Menu level and change the setting to "Use Article Settings" for the setting at the Article level to work. It would make more sense to have to choose the setting at the Article level instead and it could then look like the following:

Global - Articles - "Show Unauthorised Links":
Yes
No

Menu - Options - "Show Unauthorised Links":
Use Global (Yes/No)
Yes
No

Article - Options - "Show Unauthorised Links":
Use Global (Yes/No)
Use Menu (Yes/No)
Yes
No

Another alternative is just delete the "Show Unauthorised Links" from the Menu level. Then one can only choose to set the Global and then one has to change every single article at the Article level if one wants a different behaviour then one has chosen as Global. It would then look like the following:

Global - Articles - "Show Unauthorised Links":
Yes
No

Article - Options - "Show Unauthorised Links":
Use Global (Yes/No)
Yes
No

I believe it might have functioned like the last alternative when one is looking at the code.

<option value="">JGLOBAL_USE_GLOBAL</option>
<option value="use_article">COM_CONTENT_FIELD_VALUE_USE_ARTICLE_SETTINGS</option>
<option value="0">JNO</option>
<option value="1">JYES</option>

(github.com/joomla/joomla-cms/commit/014b52f8e3be9061836e01bb261902ef5000d3f0#diff-6ffd3a7d782585864181873aea4c2c1fR306)

The value for use "Global" is an empty string
The value for use "No" is 0 (false)
The value for use "Yes" is 1 (true)
But the value for "Use Article Settings" is "use_article" which is a text string that is 6 integers long.

It would be good if the code could start to work accordingly to my last alternative, which I believe might have been the case before, so one can change the behaviour of each individual article that one doesn't want to behave in accordance to the chosen Global setting.

If one wants to be able to change the setting at the Menu level too, then maybe one should develop the logic in accordance with the first alternative, but where the value of "Use Menu" shouldn't be a long text string.

@phpwebtech

As an administrator I'm used to set change the Global settings, which then is inherited down to the final level (Article level)

You are basing your conclusions on a false premise.

It would make more sense if Global settings were inherited down to Menu then Article but they are not.

They are separate settings that are not altered ... they have no hierarchical connection what so ever. . i.e. Changing a menu setting does not change the corresponding article setting.

Menu settings do not inherit Global settings the default option is set to use global. That is a significant difference to actually inheriting them!!!

Here is the complication. With meta data the Article settings override menu settings but with other options the Article settings are not inherited they are just not used.

In other words they are not inherited down to Articles and changing Article settings has no affect.

Therefore 'Use Article settings' is needed in Category/Featured blog menu items in order to control the display of Articles individually. That is the logic with the current setup.

Further to that ... changing the options (instead of fixing the 'Use Article settings' selection) is a major feature change that would have backward compatibility issues. Not to mention the convention of when feature changes should be made.

Global settings affect all Articles.

Menu item type 'single article' affects only one Article.  Thus Article Option settings are redundant.

Menu item type blog affects several Articles.  Thus 'Use Article settings' is needed for individual control of Article display.

Menu Option settings and Article Option settings are set to 'use global' by default.  They are NOT inherited from global.

⁣Sent from BlueMail ​

On 11 Feb 2020, 23:08, at 23:08, phpwebtech notifications@github.com wrote:

'use article settings' is logical because (with the exception of meta
data) menu settings override Article settings. So for consistency 'show
unauthorised' (in category blog menu) should override the Article
setting. Therefore 'use article settings' is logical and necessary.
Otherwise individual control of Articles showing/hiding intro text
would not be possible.

I don't agree that "Use Article Settings" at the Menu level is logical.
Especial not from the user (administrator) point of view. As an
administrator I'm used to set change the Global settings, which then is
inherited down to the final level (Article level). Even if the setting
at the Article level should work, then it's completely illogical that
one has to go to the Menu level and change a the setting to "Use
Article Settings" for the setting at the Article level to work. It
would make more sense to have to choose the setting at the Article
level instead and it could the n look like the following:

Global - Articles - "Show Unauthorised Links":
Yes
No

Menu - Options - "Show Unauthorised Links":
Use Global (Yes/No)
Yes
No

Article - Options - "Show Unauthorised Links":
Use Global (Yes/No)
Use Menu (Yes/No)
Yes
No

Another alternative is just delete the "Show Unauthorised Links" from
the Menu level. Then one can only choose to set the Global and then one
has to change every single article at the Article level if one wants a
different behaviour then one has chosen as Global. It would then look
like the following:

Global - Articles - "Show Unauthorised Links":
Yes
No

Article - Options - "Show Unauthorised Links":
Use Global (Yes/No)
Yes
No

I believe it might have functioned like the last alternative when one
is looking at the code.

<option value="">JGLOBAL_USE_GLOBAL</option> <option value="use_article">COM_CONTENT_FIELD_VALUE_USE_ARTICLE_SETTINGS</option> <option value="0">JNO</option> <option value="1">JYES</option>

The value for use "Global" is an empty string
The value for use "No" is 0 (false)
The value for use "Yes" is 1 (true)
But the value for "Use Article Settings" is a "use_article" which is a
text string that is 6 integers long.

It would be good if the code could start to work accordingly to my last
alternative, which I believe might have been the case before, so one
can change the behaviour of each individual article that one doesn't
want to behave in accordance to the chosen Global setting.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#21407 (comment)

@phpwebtech

As an administrator I'm used to set change the Global settings, which then is inherited down to the final level (Article level)

You are basing your conclusions on a false premise.

It would make more sense if Global settings were inherited down to Menu then Article but they are not.

They are separate settings that are not altered ... they have no hierarchical connection what so ever. . i.e. Changing a menu setting does not change the corresponding article setting.

I'm afraid you're missing my point. To start with it's a good idea to look at the logic a user (administrator) face. When that is done one can start to think of the logic in programming.

The Global setting of "Show Unauthorised Links" can be set to Yes or No. This setting is then passed on down in the hierarchy where on usually can chose: Use Global (Y/N), Yes and No. When choosing "Use Global" at the lower level, than it follows any changes that are being made in the Global setting. When choosing Yes or No, then it always use this setting regardless of changes in the Global setting.

With only two levels of the hierarchy, then it's quite simple, but when more levels are added, then it becomes more complicated. From a users perspective it's illogical to have to set the "Use Article Settings" at a higher level for the alternatives of Yes and No at a lower level to be able to function. The Yes and No alternatives at the Article level should not change regardless of changes in the Global settings or in any other mid-hierarchy settings like the Menu setting, neither should one have to change any setting at a higher level for the Yes and No alternative to function.

As a user I rather have a two level hierarchy that is logical, then a three level hierarchy that is illogical. Since the three level hierarchy of Global-Menu-Article is not working, then it's advisable to temporary roll-back the introduction of "Use Article Settings" until the current problem has been solved.

@phpwebtech It is you that is missing the point. It is not an hierarchy.

e.g. scenario
In a Category blog the admin wants to allow only two intro text to show but login to see the full text.
This is achieved by

1. Making the Articles view level 'registered
2. Global 'Show Unauthorised' set NO
3. Category blog 'Show Unauthorised' set 'Use Article settings'
4. The two Articles 'Show Unauthorised' set YES

Without the 'Use Article settings' that scenario would not be possible. Now do you see where you are wrong or are you just going to ignore my explanation of how the system was designed to work?

From a users point of view it looks like a hierarchy, where the Global setting can be passed on to lower levels.

The problem is that the design of the system doesn't work. When using the "Use Article Settings" at the Menu level, the setting of No do not work. If the design doesn't produce an expected result, then the design might be poor.

Based on code history, 'Use Article Setting' option was added to menu items by mistake 014b52f#diff-6ffd3a7d782585864181873aea4c2c1fR306.

This is the reason why I begun to focus on the logic from the users point of view, to see if one can come up with a better design of this function. It would therefore be very interesting to know what it looked like before the "Use Article Setting" option was added.

Your example scenario could also be achieved without the "Use Article Setting" option in a design where "Show Unauthorised Links" is excluded from the Menu level.

1. Making the Articles view level 'registered
2. Global 'Show Unauthorised' set NO
3. The two Articles 'Show Unauthorised' set YES

The negative side of this design is that one has to change the setting in every single article that one want to behave different from what is set in the Global setting, but that is something I prefer since one doesn't have to change a setting at the Menu level for making the Yes and No settings at the Article level to work, which I find ilogic.

@phpwebtech It is you that is missing the point. It is not an hierarchy.

e.g. scenario
In a Category blog the admin wants to allow only two intro text to show but login to see the full text.
This is achieved by

1. Making the Articles view level 'registered
2. Global 'Show Unauthorised' set NO
3. Category blog 'Show Unauthorised' set 'Use Article settings'
4. The two Articles 'Show Unauthorised' set YES

Without the 'Use Article settings' that scenario would not be possible. Now do you see where you are wrong or are you just going to ignore my explanation of how the system was designed to work?

@phpwebtech

From a users point of view it looks like a hierarchy, where the Global setting can be passed on to lower levels.

They are not passed down. They are selected with the default selection 'use global'. That is independent selection not inherited.

The problem is that the design of the system doesn't work. When using the "Use Article Settings" at the Menu level, the setting of No do not work. If the design doesn't produce an expected result, then the design might be poor.

The system does work it is the code that is broken. The feature did work but something was changed that prevented the code (for the option) taking affect. It is not the design that is poor it is the implementation of the code that is poor.

Your example scenario could also be achieved without the "Use Article Setting" option in a design where "Show Unauthorised Links" is excluded from the Menu level.

That is incorrect because it is based on the false premise that it is an hierarchy. They are independent settings. Without 'Use Article settings' in the menu item then the Article setting would be ignored.

The negative side of this design is that one has to change the setting in every single article that one want to behave different from what is set in the Global setting,.

Again ... That is incorrect because it is based on the false premise that it is an hierarchy. They are independent settings. Without 'Use Article settings' in the menu item then the Article setting would be ignored.

With your suggestion remove those settings from blog menu item and set Article settings default selection 'Use Global'.

I do see your point and think that would be good except for two things.

1. Article settings are being ignored. It would take a big rewrite of the code for Article settings to be hierarchical and take president over global/Menu settings.
2. If it was done it would be a feature change and that is not done for minor version changes.

The solution is fix the code for 'Use Article setting' (in the drop down box) works. It used to work but now that choice has no affect.

But if you want to create a PR to fit your vision then I will test it.

A general principle in the system is that Global settings are "distributed" down to the "Use Global setting" at lower levels otherwise the Global settings would be quite useless.

No they are not distributed down.
Global settings (for Article Options) are Global in name only. THERE IS NO HIERARCHY.

Menu only uses Global if that is selected.
Menu only uses Yes if that is selected
Menu only uses No if that is selected
Menu only uses 'Use Article settings' if that is selected.

Without 'Use Article settings' the Article settings are ignored.

The problem is not the system. The problem is that the 'Use Article settings' is using Global not Article settings.

But like I said .. if you create a patch I will test it.

Unfortunately, I've never used the system when the "Use Article Setting" have been working. Neither do I know what it looked like before the "Use Article Setting" was introduced.

Without knowing how the code is written and "structured", it's difficult to suggest what changes should be done. Even if it's manly to remove code that goes with "Use Article settings", then for sure it require more changes then correcting a bug.

I would be happy if you could direct me to the different locations where the code related to "Use Article settings" can be found, so I more easily can have a look and see what the code looks like.

With your suggestion remove those settings from blog menu item and set Article settings default selection 'Use Global'.

I do see your point and think that would be good except for two things.

1. Article settings are being ignored. It would take a big rewrite of the code for Article settings to be hierarchical and take president over global/Menu settings.
2. If it was done it would be a feature change and that is not done for minor version changes.

The solution is fix the code for 'Use Article setting' (in the drop down box) works. It used to work but now that choice has no affect.

But if you want to create a PR to fit your vision then I will test it.

I was talking in general, not in particular about the "Show Unauthorised Links". What I meant was that the chosen setting in Global is distributed down to the Global alternative at a lower level, which can be illustrated in the following way:

Alt. 1
Global setting of xx:
No

xx settings at lower level:
Use Global (No)
Yes
No

Alt. 2
Global setting of xx:
Yes

xx settings at lower level:
Use Global (Yes)
Yes
No

The setting in Global is "distributed" to the alternative "Use Global setting", but when one does use another setting then "Use Global setting", then the Global setting has no impact at all.

No they are not distributed down.
Global settings (for Article Options) are Global in name only. THERE IS NO HIERARCHY.

Menu only uses Global if that is selected.
Menu only uses Yes if that is selected
Menu only uses No if that is selected
Menu only uses 'Use Article settings' if that is selected.

Without 'Use Article settings' the Article settings are ignored.

The problem is not the system. The problem is that the 'Use Article settings' is using Global not Article settings.

But like I said .. if you create a patch I will test it.

xx settings at lower level:
Use Global (Yes)
Yes
No

Those settings would not work. The menu setting would be used. Thus All registered intro text would be seen on the blog page or it would not. There would be no way for admin to allow 'teaser' text on the blog page for just a few Articles.

It was just a general example showing what I meant with variables "distributed" from Global to lower level.

xx settings at lower level:
Use Global (Yes)
Yes
No

Those settings would not work. The menu setting would be used. Thus All registered intro text would be seen on the blog page or it would not. There would be no way for admin to allow 'teaser' text on the blog page for just a few Articles.

Is #19601 the same issue?