Bug #18079

slide of cObj CONTENT stops if sysfolder in rootline

Added by Georg Ringer over 12 years ago. Updated 5 months ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Frontend
Target version:
-
Start date:
2008-01-30
Due date:
% Done:

100%

TYPO3 Version:
9
PHP Version:
7.1
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

The slide-feature is a real great thing but it stops whenever there is a sysfolder in the rootline. No content elements of pages which are on a higher level are shown anymore!

This is especially nasty because sysfolders are often used to create some structures in the page tree.

How to reproduce: Create a page tree with a sys folder and some pages as child pages and place content on the root page.
TS-Code would be something like
page.10 < styles.content.get
page.10.slide = -1
(issue imported from #M7319)


Related issues

Related to TYPO3 Core - Bug #42558: Content sliding doesn't work when using 'show content from page' New 2012-10-31
Related to TYPO3 Core - Feature #20933: Enable working with SysFolders in CONTENT Closed 2009-08-26
Related to TYPO3 Core - Task #90947: Lift doktype restrictions in SlugHelper::resolveParentPageRecord Closed 2020-04-04
Related to TYPO3 Core - Bug #90975: Fix typo in doktype check Closed 2020-04-07

Associated revisions

Revision 6d2db4f7 (diff)
Added by Benni Mack 7 months ago

[BUGFIX] Enable rootline / content access to sysfolders

Only disallow DOCTYPE_RECYCLER in rootline and cObj->checkPid(),
instead of disallowing DOCTYPE_SYSFOLDER.

This makes it possible to fetch content from sysfolder pages.

At the same time, a hard check on accessing sys folders is added
to TSFE.

Resolves: #18079
Resolves: #20933
Releases: master
Change-Id: Ieb54d139bc1e7fc489c35f70510800be8ff14fb9
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64038
Tested-by: TYPO3com <>
Tested-by: Susanne Moog <>
Tested-by: Oliver Bartsch <>
Tested-by: Georg Ringer <>
Reviewed-by: Susanne Moog <>
Reviewed-by: Oliver Bartsch <>
Reviewed-by: Georg Ringer <>

Revision 11e28852 (diff)
Added by Christian Eßl 7 months ago

[BUGFIX] Fix typo in sysfolder related doktype check

The changes in #18079 have a small, but nasty typo, that makes it
impossible to correctly check if the page is a sysfolder.

Resolves: #90975
Related: #18079
Releases: master
Change-Id: Iec8d119a9d29adec742f322a66102ce77a6eb16a
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64095
Tested-by: TYPO3com <>
Tested-by: Georg Ringer <>
Tested-by: Daniel Goerz <>
Reviewed-by: Josef Glatz <>
Reviewed-by: Georg Ringer <>
Reviewed-by: Daniel Goerz <>

Revision eeeacf64 (diff)
Added by Christian Eßl 7 months ago

[TASK] Lift doktype restrictions in SlugHelper::resolveParentPageRecord

The changes made in #18079 lifted the restrictions for using doktypes
with a number higher than 200 in several parts of the frontend.
These restrictions were still present in the SlugHelper upon resolving
a parent page record (which automatically fetches the slugs of parent
pages for a child page upon creating its slug).
This hard restriction made it impossible to automatically resolve the
slug of a parent page with a doktype higher than 200.

The check is now adjusted to solely exclude the following doktypes:
  • DOKTYPE_SPACER (199)
  • DOKTYPE_SYSFOLDER (254)
  • DOKTYPE_RECYCLER (255)

Resolves: #90947
Related: #18079
Releases: master
Change-Id: Ia71ad2251969a73875124c80ea7521212e459150
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64073
Tested-by: TYPO3com <>
Tested-by: Benni Mack <>
Tested-by: Georg Ringer <>
Reviewed-by: Guido Schmechel <>
Reviewed-by: Benni Mack <>
Reviewed-by: Georg Ringer <>

History

#1 Updated by Andreas Rieser over 11 years ago

reproducable even in current TYPO3 4.2.6 with PHP 5.2.9

#2 Updated by tyler kraft over 11 years ago

I think this might be because you can't do a select from sysfolder and styles.content.get uses the select function

(although I could be mistaken on this)

#3 Updated by Henrik Ziegenhain about 10 years ago

This issue is still reproducable in TYPO3 v 4.4.1

Are there now some ideas to solve this ?

#4 Updated by Daniel Nienhaus about 10 years ago

The problem seems to be in class.tslib_content.php (at line 3081 in 4.4.2). The function tslib_cObj->getSlidePids() uses t3lib_pageSelect->getPage() which eliminates all sysfolders. If you change it to t3lib_pageSelect->getPage_noCheck() it works fine. I think it would be safe to use getPage_noCheck() at this point as we shouldn't need to worry about parent-pages to be hidden or inaccessible. If that was the case, we shouldn't be at the child-page in the first place.

If you don't want to mess with core files, I created a quick extension, lfslidefix, which uses XCLASS to override getSlidePids(). Tested only with 4.4.2 and it should be a few hours before it's visible in TER.

#5 Updated by Steffen Kamper about 10 years ago

that's wrong - getPage only restrict to non - deleted and pages without start- and endtime.

The part where this happens is tslib_cObj::checkPidArray where sysfolders are excluded..

cObj has a $checkPid_badDoktypeList which is responsible. Changing this would solve the issue, maybe it could be a new config var for TS?

#6 Updated by Daniel Nienhaus about 10 years ago

$checkPid_badDoktypeList is just set to 255 over here and does not exclude sysfolders. My change wouldn't even work if this was the case.
On the other hand $where_hid_del in class t3lib_pageSelect, which is used in getPage(), contains "AND pages.doktype<200". This is set by setSysPageWhereClause() in tslib_fe. If this could be configurable, it should work.

#7 Updated by Marc Bastian Heinrichs almost 10 years ago

Annoying bug - any chance to get this fixed in version 4.5?

#8 Updated by Jo Hasenau almost 10 years ago

It's not a bug, it's a feature ;-)

IMHO a sysfolder should never be taken into account while fetching visible data from the pages table.

If you just want to structure a page tree, a sysfolder is not the way to go, since this is the job of the type "visual menu separator"

So IMHO the actual bug is to abuse a sysfolder for this purpose.

#9 Updated by Susanne Moog over 9 years ago

This is actually a change of behavior. Just compared the behavior in 4.3.3 with 4.3.10 --> in 4.3.3 the slide works across sys folders, in 4.3.10 it does not work anymore. so something changed here. didn't have time to investigate this further currently.

#10 Updated by Stefan Neufeind over 8 years ago

  • Target version deleted (0)

Just experienced the problem in an updated 4.5.16 and it worked until some time in the past (can't say until what version).

Imho using a "folder" for something like "footer navigation" (holding pages which are only reachable through the footer) is/was a clean way to do this.
For now changed the page from "sysfolder" to "page, hidden in menue" - dirty :-)

#11 Updated by Bernd Wilke about 8 years ago

IMHO a sysfolder should never be taken into account while fetching visible data from the pages table.

just stumbled over this problem:

configure newsletters with direct_mail:
some content might be equal to most of the newsletters: try to slide it from page above.
so the page above the individual newsletters is a sysfolder (otherwise direct_mail will not accept the pages as newsletter) I can not slide the content.
A solution is very complex and not intuitive just because sliding breaks at sysfolders.

If you insists on taking no content from sysfolders, skip over sysfolders on sliding, but do not break it.

#12 Updated by Helmut Hummel over 6 years ago

  • Description updated (diff)
  • Category deleted (Communication)
  • Is Regression set to No

Bernd Wilke wrote:

If you insists on taking no content from sysfolders, skip over sysfolders on sliding, but do not break it.

I agree. @Joey Do you also agree?

I now use the menu separator for such structural pages, but I see no reason for the different slide behavior for folders.
I do not even see a reason why folders should not be taken into account when fetching content

#13 Updated by Helmut Hummel over 6 years ago

Jo Hasenau wrote:

IMHO a sysfolder should never be taken into account while fetching visible data from the pages table.
If you just want to structure a page tree, a sysfolder is not the way to go, since this is the job of the type "visual menu separator"
So IMHO the actual bug is to abuse a sysfolder for this purpose.

This is not about fetching data from pages, but fetching content from pages. Folders are meant to store content (of arbitrary type, not only but also tt_content). I don't see any abuse here...

#14 Updated by Helmut Hummel over 6 years ago

  • Status changed from New to Accepted

#15 Updated by Jo Hasenau over 6 years ago

Helmut Hummel wrote:

Jo Hasenau wrote:

IMHO a sysfolder should never be taken into account while fetching visible data from the pages table.
If you just want to structure a page tree, a sysfolder is not the way to go, since this is the job of the type "visual menu separator"
So IMHO the actual bug is to abuse a sysfolder for this purpose.

This is not about fetching data from pages, but fetching content from pages. Folders are meant to store content (of arbitrary type, not only but also tt_content). I don't see any abuse here...

I guess you misunderstood my objection. Actually I don't care, if sysfolders will be taken into account when sliding up the page tree, but IMHO this is just not necessary. :-)

The original bug description said:

This is especially nasty because sysfolders are often used to create some structures in the page tree.

So in the described use case the sys_folder does not contain any data but subpages. IMHO using sysfolders for this purpose is the abuse here, as this should be done with separator pages, since this is the only job they got: Creating structure in the backend view of the page tree.

#16 Updated by Jo Hasenau over 6 years ago

But we should be aware of the fact, that this issue is quite old and people might have created a lot of page trees this way.

So if we reactivate sliding over sysfolders now, this might be kind of a breaking change, since it might have content appear in the frontend, that currently is not visible.

#17 Updated by Stefan Neufeind over 6 years ago

Do we probably need a TS-setting like "stopAt..." which would default to enabled in 6.2 for compatibility and which we might consider to default to disabled (and deprecated?) if we like for 6.3? So people would still have a way to "migrate" once they update and run into that error.
Or just introduce the change for 6.3 and assume that somebody upgrading can take care of the change (needs to be mentioned in changelogs, ...) without a "stopAt..."-switch?

#18 Updated by Ben Robinson about 6 years ago

Jo Hasenau wrote:

So in the described use case the sys_folder does not contain any data but subpages. IMHO using sysfolders for this purpose is the abuse here, as this should be done with separator pages, since this is the only job they got: Creating structure in the backend view of the page tree.

IMHO separator pages are to create a visual separator between two pages, not necessarily to group subpages. F.e. they may be used to create a space or line between two menu-items (in TSREF they are called "Spacer" – menu item state SPC). I prefer to use folders to group pages (f.e. for the meta-navigation), but sliding should work with both page types.

Until sliding works properly a workaround is to use shortcut-pages (or separator pages) with the option "hide in menus" (only neccessary for separator-pages if SPC is in use). BTW separator pages with the option "hide in menus" unfortunately have the same icon like those without that option.

#19 Updated by Stefan Neufeind about 6 years ago

I agree with Ben about (usually) not using spacer-pages, but sysfolders instead.

Another example: If using things like Direct Mail you are (or at least were in direct_mail foro 4.5?) required to use a sysfolder to place your newsmail-pages into, as far as I experienced. And if you then want to show those newsmails on the website as well, you end up having a sysfolder in the middle of your tree.

#20 Updated by Jo Hasenau about 6 years ago

Well - maybe we are talking about different things here - still I get what you mean. But actually the meta navigation container is just the contrary of "creating structure in the page tree", since it takes pages out of the usual page tree structure to be presented in a visually different menu structure.

And of course there is no need to place a direct mail container within the actual page tree, since you just can't create menus with containers in between, so you have to access the content in a special way already.

Which brings me back to the actual problem: If you position your container folders the way you described it and other people did so as well, we will get a breaking change as soon as sysfolders will not stop the slide mechanism. The reason is, that sliding would suddenly start working, where it was not supposed to be working before. This will result in content being visible on pages, where it was just not accessible before due to the behaviour of slide in combination with sys folders.

So IF we were going to "fix" this, we have to make sure to mark it as a breaking change and inform people about some maybe unwanted new behaviour.

#21 Updated by Ernesto Baschny almost 6 years ago

We could just add a new option to the "slide" parameter: "-2" will also slide accross SysFolders. So the "-1" would be unaffected by the change.

#22 Updated by Henrik Ziegenhain almost 6 years ago

Good point, Ernesto

#23 Updated by Jo Hasenau almost 6 years ago

Sounds reasonable. +1

#24 Updated by Ben Robinson almost 6 years ago

I have opened a new issue "groupe pages – show subpages of SPC in menu" https://forge.typo3.org/issues/64428 and think it is related to this one, by now. We started to discused if a new pagetype for grouping is necessary, sysfolders should be used (maybe renamed to just "folders") or if the spacer-page should be renamed and be used for spaces and groups ... Anyway, the use of each pagetype needs to be clearly defined and grouping pages (incl. slide-functionality) should be one of those use-cases; otherwise everybody is struggling with workarounds.
If we find a good solution, there won't be a need to abuse any page-type for grouping pages and so we maybe wouldn't need slide-functionality here. What do you think?

#25 Updated by Andreas Allacher over 5 years ago

Actually, I understand that the sliding functionality might skip content from the sysfolder.
However, I don't think it should stop there, e.g. there could still be a normal page afterward.

But I guess with the group idea this would be fixed too.

#26 Updated by Susanne Moog almost 3 years ago

  • Category set to Frontend

#27 Updated by Susanne Moog almost 3 years ago

  • Related to Feature #20933: Enable working with SysFolders in CONTENT added

#28 Updated by Clemens Riccabona almost 2 years ago

Wow. Still in progress, it seems ... ;)

#29 Updated by Michael Sollmann about 1 year ago

Any news on this?

#30 Updated by Lina Ourima 12 months ago

  • TYPO3 Version changed from 4.1 to 9
  • PHP Version changed from 4.3 to 7.1

Still having the Problem on LTS 9. Any plan to integrate it?

#31 Updated by Urs Braem 11 months ago

Just stumbled over this. So a +1 from me

#32 Updated by Dmitry Dulepov 8 months ago

I also got a problem with this :( +1 for changing this. We have a content on the root page for the footer. It must appear on all subpages. Some pages (like 404 or sitemap) are in a folder (they should not be editable by normal backend users). And they do not show content for the footer because of this strange restriction.

#33 Updated by Eugène Fritz 8 months ago

i have the same issue, +1

My fix, Im using the menu separator, but a folder would be better.

if the Behaviour could be defined through the config, it would be great.

The reason why I don't want to use normal pages is that they appear in the slug and there is no possibility to exclude it from speaking URL like RealUrl did it!
I then have to adjust the slug manually from /footer-meta/sitemap to /sitemap.

#34 Updated by christian rauch 7 months ago

Haha

Same, also just stumbled upon this... Would be nice if content would also slide through sys folders

#35 Updated by Gerrit Code Review 7 months ago

  • Status changed from Accepted to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/64038

#36 Updated by Gerrit Code Review 7 months ago

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/64038

#37 Updated by Gerrit Code Review 7 months ago

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/64038

#38 Updated by Gerrit Code Review 7 months ago

Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/64038

#39 Updated by Benni Mack 7 months ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100

#40 Updated by Christian Eßl 7 months ago

  • Related to Task #90947: Lift doktype restrictions in SlugHelper::resolveParentPageRecord added

#41 Updated by Christian Eßl 7 months ago

  • Related to Bug #90975: Fix typo in doktype check added

#42 Updated by Benni Mack 6 months ago

  • Status changed from Resolved to Closed

#43 Updated by Peter Reichenbach 5 months ago

Done for TYPO3 10.

Also available in: Atom PDF