Bug #85284

Workspace shows unchecked sectionIndex in preview

Added by Patrick Gaumond over 3 years ago. Updated about 1 year ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
Workspaces
Target version:
-
Start date:
2018-06-15
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
8
PHP Version:
Tags:
Complexity:
nightmare
Is Regression:
Sprint Focus:

Description

If you uncheck sectionIndex (Show in Section Menus) of a tt_content it will still be shown in the Workspace preview.

It looks like the WS preview doesn't care about sectionIndex=0 and show it anyway.

Also true for the Menu sections in WS Preview: The tt_content will be in the list even with sectionIndex=0


Related issues

Related to TYPO3 Core - Bug #85934: DatabaseQueryProcessor - doesn't respect the translation configNeeds Feedback2018-08-23

Actions
Related to TYPO3 Core - Bug #88071: Language overlay in DatabaseQueryProcessorNew2019-04-04

Actions
Related to TYPO3 Core - Bug #93336: Enabling translated content in workspace is not previewableClosed2021-01-21

Actions
#1

Updated by Riccardo De Contardi over 2 years ago

I tried the following test on version 10.0.0-dev (latest master)

Prerequisites

  • TYPO3 with a "draft" workspace
  • a page called "Page A"
  • a page called "Page B"

Execution

  1. in LIVE workspace, go to "Page A" and create a new element, CType: "section index (menu_section)"
    1. on the field "selected pages" > select "Page B", save and close
  2. On "page B" create three content elements (CType: header)
    1. element 1 > [header] > write "Test 1 this should be visible in menu"
    2. element 2 > [header] > write "Test 2 this should NOT be visible in menu"
      1. on the tab "Appearance" > edit "Show in Section Menus[sectionIndex]" and put it to off
    3. element 3 > [header] > write "Test 3 this should be visible in menu"
  3. Save and close
  4. Go to "draft" workspace, go to "Page A" and preview it

Results

  1. the link to the element "Test 2 this should NOT be visible in menu" is NOT visible > OK

Execution (test 2)

  1. go to "Test 3 this should be visible in menu" and edit it
    1. on the tab "Appearance" > edit "Show in Section Menus[sectionIndex]" and put it to off
  2. Save and close
  3. Go to "draft" workspace, go to "Page A" and preview it

Results

  1. the link to the element "Test 3 this should be visible in menu" is STILL visible > KO
#2

Updated by Christian Kuhn about 1 year ago

Great reproduce information again, Riccardo. Thank you! Issue still confirmed in current master.

#3

Updated by Christian Kuhn about 1 year ago

  • Related to Bug #85934: DatabaseQueryProcessor - doesn't respect the translation config added
#4

Updated by Christian Kuhn about 1 year ago

  • Related to Bug #88071: Language overlay in DatabaseQueryProcessor added
#5

Updated by Christian Kuhn about 1 year ago

Ok, here is the thing:

Content elements in core are rendered via fluid_styled_content (by default, since which version exactly?). In case of content element based sectionIndex menues, the according file is ext:fluid_styled_content/Configuration/TypoScript/ContentElement/MenuSection.typoscript

This file uses that snipped for the query:

...
                20 = TYPO3\CMS\Frontend\DataProcessing\DatabaseQueryProcessor
                20 {
                    table = tt_content
                    pidInList.field = uid
                    as = content
                    where = sectionIndex = 1
                    orderBy = sorting
                    dataProcessing {
                        10 = TYPO3\CMS\Frontend\DataProcessing\FilesProcessor
                        10 {
                            references.fieldName = image
                        }
                    }
                }
...

This triggers class DatabaseQueryProcessor with the query config. The class calls ContentObjectRenderer->getRecords() which creates a query via exec_getQuery() and receives the (always live, no language overlay, no workspace overlay) records. Those records are then overlayed with workspace versions and languages.

So the result rows DO have the sectionIndex=0 field set correctly, because they have been overlayed.

However, that row information is now too late and rows are NOT filtered again, eg. by given where restriction ... because, well, the query is done already. Thus, the record ("element 3" in Riccardos example) is rendered.

One could imagine a hack in ContentObjectRenderer->getQuery() trying to parse typoscript 'where' a second time to filter rows on PHP level. That approach however would be very limited:
  • First only "additional restrictions" can be applied: Filtering rows that fall out of the query, but should still not be shows. If I turn the sectionIndex from above around and set sectionIndex=0 in live record but =1 in workspace, the approach of additional filtering would fail because the row wouldn't fall out of the query in the first place.
  • Furthermore, a solution would require a parsing of a database where condition into some php pendant. This would be do-able for simple stuff like "fieldname = 42" or "fieldname > 42", but 'where' can be as complex as you want and also has stdWrap properties which could lead to everything ... In short, one does not want to create an sql parser in php ...
  • The approach is also broken for stuff like LIMIT restrictions: "give me only x number of rows" - if a php side post-filter would kick rows, there may not be enough rows coming from the query to fill up with new candidates.

BTW: The old school menu_section index content object from AbstractMenuContentObject->sectionIndex() probably handled that case in a better way, since it considers the sectionIndex=1 restriction after overlays to language and version have been done ...

In general, the DatabaseQueryProcessor approach is very limited when it comes to language/version overlays and typically leads to wrong results. Issue #88071 is another example, and that one is not workspace but "just" language related. I'd actually expect more issues in this area to be reported in the future (please link those issues).

A good solution could be to do the overlays within the very same query, making the database doing overlays transparently (probably by using CTE's) in the first place. That approach would have other significant benefits, and we're thinking about that for some time already. It however requires deeper refactoring. Core v10 already has some important pre-work in this area to solve it, but the real work has not been done.

Thus, at the moment, this issue can't be solved in a good way since you'd always run into further not met scenarios. At the moment, I can only give the advise to somehow hack around those cases if they really need to be solved (for instance in this case by maybe falling back to the old school way of rendering). It would be great if according workarounds could be documented for others here if anyone comes up with something.

#6

Updated by Christian Kuhn about 1 year ago

  • Complexity set to nightmare
#7

Updated by Benni Mack 9 months ago

  • Related to Bug #93336: Enabling translated content in workspace is not previewable added

Also available in: Atom PDF