Behaviour of "hidden" of pages

Archive Discuss Topics
1

tl;dr: Records like content elements are not rendered if set to hidden but what about content of pages, especially of type sys folders, set to hidden? Currently those records are still rendered

The ticket Story #97780: Hide/disable sysfolder does not hide containg records - TYPO3 Core - TYPO3 Forge brought some questions up about an inconsistent behaviour regarding the checkbox hidden.

Status Quo

  • If a record like tt_content or fe_user is hidden, it is not rendered.
  • If a page is set to hidden but the page translation is not hidden, the translation is still not rendered

but

  • if a page is hidden but it got sub pages, those are still available in the frontend
  • if cObj RECORDS is used to render a special content element which is saved on a hidden page, it is still rendered
  • if the shortcut content element is used to render a content element which is saved on a hidden page, it is still rendered
  • if EXT:news is configured to render news from a page which is set to hidden, those records are still rendered.

Problems

  • Editors often disable a sys folder and believe the pages below are also hidden but those are still available in the frontend and e.g. in a sitemap
  • The checkbox “hide” is totally useless in sys_folders because there is no change in behaviour, neither in backend nor frontend

Possible solutions

  1. Remove the checkbox of sys_folders because it does nothing. However this would lead to an even more inconsistent backend because it would be the only page type without the checkbox.

  2. Leave it like it is

  3. Change the current behaviour. See below

Proposal

If a page is hidden (no matter its type), all subpages and possible records are not rendered in the frontend anymore

This affects:

  • Records on that or subpages, e.g. via shortcut element or cobj RECORDS
  • Menus
  • Sitemaps
  • Record selection

Questions

  • What do you think about the current situation?
  • What do you think about the possible solution?
  • Do you got alternative ideas?
2

There is a special field within a page to hide only default translation:
image
Which is even less UX.

I would prefer your proposal. But this is a huge breaking change. Maybe this could be moved behind a feature flag for 1 or 2 LTS versions?

I don’t have an alternative and don’t like the confusing current situation. There might be even more cases and tweaks you and me aren’t aware of.

3

I understand the issue, this is indeed an unattractive behavior.

I agree with your suggestion, and I like Daniel’s idea to temporarily control this via a feature flag.

4

You forgot “extendToSubpages” in the game!

Generally, when thinking about “enable fields” of pages, an editor would assume extendToSubpages=1 (by default)

5

Next to “extendToSubpages” (which only affects pages) a new checkbox might be added: “extendToRecordsInPage” where an editor can hide all records from that page. (including timed access or FE-login group access)

In general I would miss the option to hide some pages/folders but still use the records of that page.

6

if you want to render records of a page, why keeping it hidden? especially a sysfolder?

7

In a hidden page (which is hidden as it should not be rendered) I can store some CEs which can be used (referenced) around the website for having the same information everywhere.
that could be records, but sometimes it is easier to have just plain CEs.
one usage might be contact information. all contacts are stored in one page (which should not be visible) and editors just insert a reference to the appropriate CE.on other sides.

8

A hidden page is not rendered, that has nothing to do with the contents on it. The contents can still be used e.g. with “insert records” on other pages. This is like disabling the news plugin does not disable the news records.
A sysfolder is not a page as such. A sysfolder is NEVER rendered, so the hidden checkbox has no meaning and therefore can be omitted.
Maybe it is a misconception that sysfolders are entries in the pages table/tree. Most TYPO3 installations do fine with just one sysfolder with records (per extension). Maybe we should re-think the concept of sysfolders.

9
  1. Remove the checkbox of sys_folders because it does nothing. However this would lead to an even more inconsistent backend because it would be the only page type without the checkbox.

IMHO this is the only useful, reasonable and non-destructive option we’ve got here. And the assumption, that it would increase inconsistency is wrong.

It’s just the opposite: A page of the type sys_folder already got a lot less options than most of the other page types, because it’s just a container, which does not get rendered in the frontend.

So the solution is quite simple: Since this page type is not rendered in the frontend, there should not be any fields available, that actually deal with frontend appearance; behaviour or access.

There already is just a single field in the Appearance tab and the Behaviour tab because of this, so we can easily remove the useless “visibility” field from the Access tab too, because a sys folder got no visibility anyway.

This will remove the misunderstanding because editors can not guess that something will magically be hidden, if they can not hide the folder itself anymore, and it will not add up to the confusion for all the other page types, because you could not accidentally remove EVERY SINGLE RECORD from the frontend rendrering of a whole branch of the page tree with just a single switch.

There’s even more:

What happens if there are pages within a branch of the page tree, that are not accessible for a specific editor, because of missing user rights? Should they still be fully disabled in the frontend, just because the editor actually got access to the visibility field of a page up in the rootline, without even knowing that those pages exist?

What happens to records that have been inserted on other pages via shortcut/reference, without the editor even knowing about them, while hiding the original page?

The impact of such a “one switch kills all” approach IMHO is way to high to take the risk for it, which is why I would go for the removal of the useless visibility switch of sys_folders.

10

A hidden default language page should only disable its translations when the behaviour is set to “connected mode”, because the definition of that mode makes default language records mandatory.

In “free mode” the translations should still be rendered and if this is currently not the case, I would consider this a bug.

11

BTW: There actually is an inconsistency in the labels of the action, that might cause the misconception:

While the editing form of a page correctly uses the term “Visibility” and “Page visible yes/no” with a switch, the same behaviour is labelled as “enable/disable” in the context menu of a page in the page tree.

“Disabling” something would indeed cause the assumption, that everything it contains would not be available anymore, while “Hiding” clearly states that it is about frontend visibility only.

So we should remove the field for sys_folders, and we should give the action a consistent labelling (i.e. Show/Hide) for the other page types.

Finally we could add a new field that really “disables” anything inside a page, regardless of its page type, which would not lead to the breaking change of behaviour and could be configured as “Admin only” to avoid accidental destruction.

12

From my point of view I think that re-think the concept of sysfolders and maybe pages (cause I think pages that holds CE for other pages are more Content Pools) is a good idea. For Editors the UI of the Backend is not easy comparing with other CMS`s.

13

Yeah you’re right a sysfolder is no page. And so it doesn’t need the same fields.

14

I would agree in removing the “hide” checkbox for sysfolders.

About the “subpages of a hidden page” topic: I don’t know if it would be a good idea to hide all the subpages of an hidden page;
For now I would suggest to add some warning box on the hidden page that tells the editor that the page is hidden and this might affect the consistency for example of menu rendering… I don’t know…

I agree that when the hidden page is the root page, this is a special case it would turn off the entire site.

In this case I would like something like

  • an alert poput which warns the user that the action will disable the whole site
  • an alert/warning box on every page that tells that the page is not online, due to the hiding of the root page.

IMHO the ““extendToSubpages” concept would need a re-thought because it is hard to tell which properties are affected (see: https://forge.typo3.org/issues/93540)

I guess this scenario is well-covered with the sysfolders, am I wrong?

15

Removing the checkbox from sysfolders would only solve a sympton but not solve the actual problem:
As an editor, how can I hide all content from a sysfolder without having to touch every single record?

I think an enterprise CMS should have such possibility to group content (like TYPO3 does with sysfolders) and show/hide containing content quick and easy.
Imagine thousands of records in one folder and you need to disable every single record. Currently, you would have to hire a developer to disable the records via the database.

The shortcut content element only renders content placed on visibile pages, unless dontCheckPid is enabled (it is not by default).
So for pages the behavior is already the same: if you disable a page, all contents on this page (including referencing contents) are hidden in frontend. This is how TYPO3 should also deal with sysfolders and their containing records.

I agree that disabling a page or sysfolder should not disable all underlaying pages. This would mess up a lot of things. The behavior should stay the same as it is: Disable a page should only disable that one page, no subpages. But disabling a sysfolder SHOULD hide containing records in frontend for that one sysfolder.

16

We have use cases where we do import of data into one sys_folder and then move it to another sys_folder for review. The sys_folder containing the direct imports is hidden so editors don’t expect that records from that folder would be displayed. Now we have to hide and unhide every single record instead of the folder. And as there is no mass hiding or unhiding that can be very tiresome.

17

Thanks for raising this topic.

In general, TYPO3 behaves very inconsistent, especially the two special cases:

  • pages.l10n_cfg
  • pages.extendToSubpages
    … in addition to the case you explained.

A similar behavior is when deleting a record on a page, and then deleting the page with other records a month later. Two months later, the editor is using the recycler to restore the page → including ALL deleted records on the page.

The main reason in my opinion is that TYPO3 only stores the “current state” (hidden/unhidden in your case) in the database, but not how this happened. (I think Olly Hader can tell us quite a lot about it).

This means, that the “real solution” is, that if somebody hides a page, all elements (e.g. news records) on a page should be “marked as hidden” as well. If the page is marked as active again, then all elements that were hidden “along with the page” (= in the same process / command) should be unhidden again as well! You can see that you can use the same pattern for pages.extendToSubpages as well (making the checkbox actually obsolete, marking the functionality as default behavior).

What then happens is that while querying the records, one does not need to change anything or do complex recursive queries if a parent page is hidden etc. The more “expensive” part would be in the works when writing to the DB.

18

This topic was automatically closed after 14 days. New replies are no longer allowed.