TYPO3 Core

I have just encountered the same issue. As this bug does not seem to get any attention:

Is there a workaround? I mean, how am I supposed to write frontend plugins with extbase if this is not working?

All the best and thanks,

M

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:
<persistence.storagePid>
<TCEforms>
<exclude>1</exclude>
<label>LLL:EXT:lang/locallang_general.xml:LGL.startingpoint</label>
<config>
<type>group</type>
<internal_type>db</internal_type>
<allowed>pages</allowed>
<size>3</size>
<maxitems>50</maxitems>
<minitems>0</minitems>
<show_thumbs>1</show_thumbs>
<wizards>
<suggest>
<type>suggest</type>
</suggest>
</wizards>
</config>
</TCEforms>
</persistence.storagePid>

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

Any news regarding this? I've got the same behaviour in 6.2.15, but i believe i've read about respecting the storage pid by the ce's "default record storage pid" setting should be "default" in between?

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

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:

plugin.tx_xxx_xxx.persistence.storagePid >

Replace the xxx accordingly.

My conclusion:

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.

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

Still not working in TYPO3 10. "Record Storage Page"[pages] field from a plugin does not get respected. Only TS-Constant "plugin.tx_xxx_xxx.persistence.storagePid = xx" get respected.

Still not working in v11 - same issue as mentioned in comment #11 as the actual issue itself.

Could this have to do with the removal of storagePid-functionality in TYPO3 7.4? From the changelog:
https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/7.4/Deprecation-65790-PagesStoragePidDeprecated.html

So the setting in the content-element is not "storagePid" anymore, just a general setting "pages" but without further effect for the storagepid-detection?

Older explanation (2016) for a flexform-field "storagePid", which isn't there anymore. It could probably be re-added for your plugin. But that's not how things are supposed to (generally) work for a plugin "lately" (since 7.4) if I'm right. Interesting :-)
https://www.derhansen.de/2016/02/how-extbase-determines-storagepid.html