Explicitly allow ignoring "pidInList" in TS select function
Currently, the implementation of the TypoScript function "select" will automatically set "pidInList" to "this" if it is not set, even when "uidInList" is specified and points to a uid on a different page.
The result will then be empty, even if the record exists and could be displayed. This is confusing and hard to understand, especially since there is no documented way of ignoring "pidInList". Instead, some people implement workarounds with high recursion limits e.g. descending from the site's root page.
My proposal is to add a new setting "ignore" that will lead to the value not being evaluated. This works already, since the non-empty value will prevent the default of "this" from being used. However, it is undocumented behaviour and thus might break in the future w/o any notice. Therefore, let's make it explicit and document it.
Updated by Stefan P over 1 year ago
I'd like add a "+1" here.
This is for example totally relevant when using
ext:news with inline content element rendering. The news records and their CE sit in some folder but the page used in FE is the detail page. So CTypes using custom inline elements and data processors do not work (they needed to be selected from the news storage pid, but are tried to be selected from the current FE page -> not found).
For anyone reading this: A nasty workaround is this:
// set pid list to your siteroot pidInList = 1 // set depth to a reasonably high number recursive = 10
It would be nice if there's a new keyword beside
ignore or something, which then prevents adding the pid condition in the SQL at all.
Updated by Mathias Brodala over 1 year ago
Evidently just setting
pidInList = 0 (thus explicitly setting it to
0, zero) in fact leads to the
pid part being dropped from the query.
However this will by default lead to a query with
uid = 0, so setting
uidInList at the same time is mandatory for a valid query.
We should clarify if this is intended behavior since TYPO3 itself makes use of this in
AbstractMenuContentObject. If yes, it should be documented properly and tests should be added to verify this behavior and ensure it is not dropped accidentally.
Updated by Ayke Halder 9 months ago
PR for change in documentation: