TYPO3 Core

reproducable even in current TYPO3 4.2.6 with PHP 5.2.9

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)

This issue is still reproducable in TYPO3 v 4.4.1

Are there now some ideas to solve this ?

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.

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?

$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.

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

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.

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.

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.

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...

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.

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.

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?

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.

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.

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.

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.

Good point, Ernesto

Sounds reasonable. +1

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?

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.

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

Any news on this?

Just stumbled over this. So a +1 from me

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.

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.

Haha

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

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

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

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

Done for TYPO3 10.