Not possible to set the storagePid via "Record Storage Page"
After a short chat with Felix Oertel, i now open this bug report.
In the current version of extbase 6.2.0, there is no way to set the persistence.storagePid via the field "Record Storage Page" in the plugin content element under Behavior.
- Create a content element of type plugin and select an extbase plugin which at least outputs some list data
- Set the persistence storagePid in the static constants
- Open the FE and navigate to the page where the plugin has been placed
- Everything seems to work fine, records will be loaded from the defined storagePid
- Manipulate your repository find method and output $query->getQuerySettings()->getStoragePageIds()
- After reloading the FE, the records will be loaded and because of the added line above, the storagePid will be displayed on the page, too
- Remove the storagePid from the persistence settings
- If you reload the FE, you will see no records and no output of the storagePid (of course, you deleted it)
- Instead of re-setting the persistence storagePid via TypoScript, select the storagePid in the "Record Storage Page" in your plugin content element under behavior
- If you reload the FE, you will see the storagePid as output of the $query->getQuerySettings()->getStoragePageIds(), but you cannot see any records
If I set the storagePid in the Record Storage Page field of the content element, I expect that this will be considered in the query.
The set storagePid is recognized as storagePid, but was not considered in the query.
Updated by Bernhard Berger about 7 years ago
I'm having the same trouble.. I need to a) filter the output of a select box according to the storagePID (there are hundreds of records in there in a multitree environment) and I need to be able to set the storagePID from the extension.
2 Possibilities I had in mind:
1) If I add this to my Plugin-FlexForm:
It works for overwriting the storagePID in the settings for the frontend. But I have no way of accessing it because of the DOT in the variable name via the usual markers.. ###REC_FIELD_[fieldname]###
2) second idea was to use the default storage page in the content element in the behaviour tab, but this doesn't seem to have any effect in the persistence settings. I however can access it in my select box configuration like this:
<foreign_table_where> AND tx_myextension_domain_model_mymodel.pid IN (SELECT pages FROM tt_content WHERE uid = ###THIS_UID###)</foreign_table_where>
Still I cannot use this field for overwriting the persistence.storagePid...
This bug needs some serious attention I think.. can't believe how broken 6.2 LTS is at the moment..
Updated by This Mächler over 5 years ago
This might be not the place to post this (as it is not a bug), but I did a lot of research when my extension's frontend plugin (TYPO3 7.6.4) refused to use the 'pages' field of the plugin ("Record Storage Page"), so I would like to share my findings:
My extension's name is 'tx_dhsnews', my plugin's name is 'infobox'
1. setRespectStoragePage must be set to true (default): $query->setRespectStoragePage(TRUE)
2. In the typoscript-setup, the plugin-specific storagePid plugin.tx_dhsnews_infobox.persistence.storagePid MUST NOT be present at all! Not event with an empty value! Else the 'pages'-field will not be respected!
That's all. The Extensions Builder just created a typoscript-setup with the storagePid for the specific plugin 'infobox' set to nothing. That resulted in the plugin not respecting the 'pages' - field.
It's no problem to set the storagePid on extension-level (e.g. 'tx_dhsnews..persistence.storagePid'), the value will be merged with the value(s) given in 'pages' ("Record Storage Page"), but as soon the plugin-specific tx_[extension]_[plugin].persistence.storagePid exists in the typoscript, it will overrule everything else!
Hope this will help somebody to save some time + nerves
Updated by Elmar Hinz over 5 years ago
Only twelve hours later I encounter the same issue and confirm This Mächler. This one line into your TS does the trick, when you started with the extension builder:
Replace the xxx accordingly.
I would call this a bug, because the "... MUST NOT be present at all! Not event with an empty value! " requirement doesn't make sense, but causes an issue, when trying to set it by constant.
Updated by Jan Kornblum over 1 year ago
What about making „pages“ (if set) always override the TypoScript variable (even if last one is empty)? That would follow the approach to override settings per content element.
So in my opinion ist is still a possible optimization - and it doesnt work as „expected“ currently...