Bug #58857

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

Added by Pascal Maechler over 7 years ago. Updated 11 months ago.

Status:
Accepted
Priority:
Must have
Assignee:
-
Category:
Extbase
Target version:
-
Start date:
2014-05-16
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

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.

#1

Updated by Mario Colombo about 7 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,

M

#2

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

#3

Updated by Alexander Opitz almost 7 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
#4

Updated by Mathias Schreiber almost 6 years ago

  • Target version deleted (next-patchlevel)
#5

Updated by Jan Kornblum almost 6 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?

#6

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

#7

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:

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.

#8

Updated by Susanne Moog over 1 year ago

  • Status changed from New to Needs Feedback

Can anyone confirm that this is now working as expected?

#9

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

#10

Updated by Susanne Moog over 1 year 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 :)

#11

Updated by Tobias Gaertner 11 months 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.

Also available in: Atom PDF