TYPO3 Core

I found this issue because I'm having trouble to find out what extendToSubpages actually does in a real-life large setups with thousands of pages and hundreds FE groups.

What I found out: it applies to hidden , startime , endtime and fe_group (all of the four "classic" enable fields). But how it applies remains largely a mystery.

What happens if I set extendToSubpages = 1 and on a subpage I set another starttime? Does it override the inherited starttime but keeps the other inherited enable fields as is? Or does it act as if extendToSubpages = 0 from this point (breaking the recursion)? Or is the new starttime ignored? What value will "win" in which situation?

Or what happens if I set FE group "One" and extendToSubpages = 1 and on a subpage I set FE group "Two"? Does this subpage now restrict the page to the FE groups "One" and "Two"? Or only "One"? Only "Two"? None?

The code in TypoScriptFrontendController regarding this field is totally unreadable.

And the official documentation is totally useless as well because it answers none of these questions... https://docs.typo3.org/m/typo3/tutorial-editors/master/en-us/AccessControl/Visibility/Index.html#publication-dates

When you enable the Extend to Subpages setting, the publication date (and other access restrictions) also apply to all child pages of the current page. This makes it possible to apply restrictions to a whole branch of the page tree.

#91504 confirms my suspicion that extendToSubpages is "final": stopping subpages from setting any enable fields at all and being forced to the first parent page where extendToSubpages = 1.

This is highly confusing because in tree-like structures / inheritance models one can usually always override values.

I collected all issues I could find regarding this topic.

• all documentation is updated to make it clear what this setting does
• the TCA is cleaned up: correct grouping of the fields and adding explicit labels and descriptions that also make it perfectly clear what will happen

@Stefan P cool! Really appreciate it.

You might also consider opening a separate issue (or issues) for your finding, if the behaviour gives unexpected results, preferably with examples.

What happens if I set extendToSubpages = 1 and on a subpage I set another starttime? Does it override the inherited starttime but keeps the other inherited enable fields as is?

Intuitively, I would expect it does. Meaning each individual setting is overridden by the lower nodes in the page tree. Will verify by testing ...

If that is the case, I am pretty sure, this is often not what is wanted - our editors usually only apply starttime / stoptime to a specific page.

Another problem is that you cannot (easily) see in page tree if a page is hidden.

My result is currently, I would like to disable it entirely.
(But then you would have to convert the existing settings and hiding all subpages is a pain - not found the functionality to do that, neither in list nor in info module)

If the current behaviour (extendToSubpages "hard-locks" all enable fields of subpages) should stay it may be a valid improvement to add a display condition to the enable fields that hides the fields if the rootline has extendToSubpages = 1 somewhere. (and if possible adds a small notice that extendToSubpages is active to explain why these fields are not visible)

+1 (for general idea of suggestion in previous comment)

I agree that a field that has no effect because it gets overriden makes no sense. Ideally the actual state should be shown with field greyed out.

however, I have to think about this some more ...

Alternatively, you might want these states, for these kind of fields with 3 states instead of 2:

• auto / on / off (where "auto" uses setting from parent if "extendToSubpages" is on or the default if not)
• start time / off / auto (e.g. have a date / time field and a 3-way toggle: "on", "off" , "auto")
• etc.

auto should be default

I really appreciate OPs thoughts on "extendToSubpages" and how the UI can be improved. It is indeed very, very (I can repeat "very" as many times as the number pi has decimals) unclear, what "extendToSubpages" does and/or should do actually.

So here my bump and +1. Dear "core-stategists" - please have a glimpse look. This needs to be improved. "Centering the add-new-button in page module" isn't the end of UX-improvements - at least I hope so.

IMHO, first of all this setting must be reversed.

The logic should be that a parent's setting is inherited from by his children. If necessary, a child can override the parent setting.

I'm sure any editor would expect, for example, to hide a page and that visiting its subpages will result in 404 as a result. And so it happens with the editors I deal with. I realized yesterday, with great surprise, that many child pages of hidden pages were visible and indexed by search engines :/

Please enlighten me if you think I am on the wrong track.

@Christian Thanks for your input. I guess what you are saying rather that "exendToSubpages" should be the default behaviour for some fields (such as hidden), be "on" by default?.

I'm sure any editor would expect, for example, to hide a page and that visiting its subpages will result in 404 as a result. And so it happens with the editors I deal with. I realized yesterday, with great surprise, that many child pages of hidden pages were visible and indexed by search engines :/

Same thing here. Especially in the case of outdated, unmaintained pages this is a problem, but not intuitive, it is something you have to "know" (or be reminded about or "trained").

I'm sure any editor would expect, for example, to hide a page and that visiting its subpages will result in 404 as a result.

Which is the case if extendToSubpages is activated.

Sybille Peters wrote in #note-16:

@Christian Thanks for your input. I guess what you are saying rather that "extendToSubpages" should be the default behaviour for some fields (such as hidden), be "on" by default?.

I'm saying the option should be the other way around. Something like "Stop inheriting access settings from parent pages".

I guess that it has the same effect of "extendToSubpages" on by default on all pages but this way sounds more confusing to me. I believe that something that changes a default behavior should be off by default.

Also, if you turn "extendToSubpages" on by default on all pages you'll have that [>>] symbol on all icons of the pages in the pagetree. Ok, this can be changed but still I think is a little more intuitive if it is the other way around.

IMHO, first of all this setting must be reversed.
The logic should be that a parent's setting is inherited from his children.

do you mean "by its children"? (otherwise this sentence is a little misleading)

Yes, "by its children". I corrected my post.

By the way, if the idea of reversing the option will make things too difficult to implement, I guess that it is also okay to activate extendToSubpages by default. But we have to fix the [>>] page icon that, in this case, must appear only if extendToSubpages is off and must be different to represent the end of inheritance.

Thanks all for your work here.
I can confirm, that most of our editors expect the subpages of a hidden page to be hidden as well by default.
+1 for reorganizing the groups to make it clear which fields are affected.
+1 that the icon in the pageTree should change, if a hidden page has extendToSubpages set. At least as long as subpages of hidden pages are visible by default.