Bug #58857


Not possible to set the storagePid via "Record Storage Page"

Added by Pascal Maechler almost 10 years ago. Updated 10 months ago.

Must have
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


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.

Steps to reproduce:
  1. Create a content element of type plugin and select an extbase plugin which at least outputs some list data
  2. Set the persistence storagePid in the static constants
  3. Open the FE and navigate to the page where the plugin has been placed
  4. Everything seems to work fine, records will be loaded from the defined storagePid
  5. Manipulate your repository find method and output $query->getQuerySettings()->getStoragePageIds()
  6. 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
  7. Remove the storagePid from the persistence settings
  8. If you reload the FE, you will see no records and no output of the storagePid (of course, you deleted it)
  9. Instead of re-setting the persistence storagePid via TypoScript, select the storagePid in the "Record Storage Page" in your plugin content element under behavior
  10. If you reload the FE, you will see the storagePid as output of the $query->getQuerySettings()->getStoragePageIds(), but you cannot see any records

Expected behavior:
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.

Current behavior:
The set storagePid is recognized as storagePid, but was not considered in the query.

Actions #1

Updated by Mario Colombo almost 10 years ago

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,


Actions #2

Updated by Bernhard Berger over 9 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 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..

Actions #3

Updated by Alexander Opitz over 9 years ago

  • Project changed from 534 to TYPO3 Core
  • Category set to Extbase
  • Target version set to next-patchlevel
  • TYPO3 Version set to 6.2
  • Is Regression set to No
Actions #4

Updated by Mathias Schreiber over 8 years ago

  • Target version deleted (next-patchlevel)
Actions #5

Updated by Jan Kornblum over 8 years ago

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?

Actions #6

Updated by This Mächler about 8 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

Actions #7

Updated by Elmar Hinz about 8 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:

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.

Actions #8

Updated by Susanne Moog about 4 years ago

  • Status changed from New to Needs Feedback

Can anyone confirm that this is now working as expected?

Actions #9

Updated by Jan Kornblum about 4 years 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...

Actions #10

Updated by Susanne Moog about 4 years ago

  • Status changed from Needs Feedback to Accepted

Thanks for the quick feedback, I'll have a look if we can get this in without breaking setups :)

Actions #11

Updated by Anonymous over 3 years ago

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.

Actions #12

Updated by Mati Sediqi over 2 years ago

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

Actions #13

Updated by Stefan Neufeind about 1 year ago

Could this have to do with the removal of storagePid-functionality in TYPO3 7.4? From the changelog:

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

Actions #14

Updated by Stefan Neufeind about 1 year ago

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 :-)

Actions #15

Updated by Stefan Froemken 10 months ago

  • Status changed from Accepted to Closed


thanks for your report. I have tried to reproduce that issue with EXT:news, but as it works with its own DTO and TypoScript "startingpoints" I have switched to one of my own extensions.
After removing the value from TypoScript no records will be shown, but after setting the storage in a content element it works like expected.

I will close the ticket now. If you feel this is the wrong decision, let me know, and I will re-open it and please add a TYPO3 extension where I can reproduce that issue.



Also available in: Atom PDF