Bug #18079

slide of cObj CONTENT stops if sysfolder in rootline

Added by Georg Ringer over 11 years ago. Updated 26 days ago.

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

0%

TYPO3 Version:
4.1
PHP Version:
4.3
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 New 2009-08-26

History

#1 Updated by Andreas Rieser over 10 years ago

reproducable even in current TYPO3 4.2.6 with PHP 5.2.9

#2 Updated by tyler kraft over 10 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 9 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 9 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 9 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 9 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 9 years ago

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

#8 Updated by Jo Hasenau almost 9 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 8 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 7 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 7 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 about 5 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 about 5 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 about 5 years ago

  • Status changed from New to Accepted

#15 Updated by Jo Hasenau about 5 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 about 5 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 about 5 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 5 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 5 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 5 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 5 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 5 years ago

Good point, Ernesto

#23 Updated by Jo Hasenau almost 5 years ago

Sounds reasonable. +1

#24 Updated by Ben Robinson over 4 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 4 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 2 years ago

  • Category set to Frontend

#27 Updated by Susanne Moog almost 2 years ago

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

#28 Updated by Clemens Riccabona 9 months ago

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

#29 Updated by Michael Sollmann 26 days ago

Any news on this?

Also available in: Atom PDF