Mysteries of the StoragePid

Versions:

  • TYPO3 CMS: 7.6.4
  • Extension builder: 7.6.0
  • Extbase: 7.6.0
  • Example plugion: tx_xxx_pi

Why did you come to this page? Maybe you experienced a szenario similar to this.

You created an extension with a plugin by using the Extension builder. You put some entries into a sysfolder and select this folder in the plugins form as Record Storage Page. In the FE the list the entries show up.

Pretty!

Now you include the static template into TypoScript and the entries vanish from the list. You enter the sysfolders ID into the Constant Editor as Default storage PID and the entries occur again:

# Constants
plugin.tx_xxx_pi.persistence.storagePid = 18

# Setup
plugin.tx_xxx_pi.persistence.storagePid = {$plugin.tx_xxx_pi.persistence.storagePid}

Something feels wrong with this static template. It seems the Default storage PID overrules the settings of the plugin form. Even if nothing is set, it disables the selection of the plugin form. Shouldn’t a default be a default be a default, that can be overruled by the form?

As we will see, it’s not actually the fault of the static template but rather the algorithm by which Extbase resolves the storagePid.

A Workaround First

If you are not deeply interested in the sources, here is a workaround. Disable the Default storage PID in the TypoScript setup (and remove it from the constants):

# Setup
plugin.tx_xxx_pi.persistence.storagePid >

The drawback is, that you loose the option to set a default, but you can use the settings of the plugin form again. That is espacially important, if you have multiple forms with different sysfolders.

The Order of Overrules of the Storage Pid

Classes:

  • TYPO3CMSExtbaseConfigurationFrontendConfigurationManager
  • TYPO3CMSExtbaseConfigurationAbstractConfigurationManager

The class FrontendConfigurationManager extends the class AbstractConfigurationManager. In AbstractConfigurationManager the resulution of the configuration is started by the function getConfiguration.

When I speak of the storage pid here, this may be a list of comma separated ID as well. However, overrules apply as if it a single value.

The Absolute Default

The absolute storage PID default is set as:

AbstractConfigurationManager::EFAULT_BACKEND_STORAGE_PID = 0

Extbase Settings

If config.tx_extbase.persistence.storagePid is set in TypoScript, this value now overrules the default.

TypoScript Plugin Configuration, First Call

Now FrontendConfigurationManager::getPluginConfiguration is called for the first time. A TypoScript setup of the storage pid will overrule taken from:

plugin.tx_xxx_pi.persistence.storagePid

Three Steps Called from a sub method

Next FrontendConfigurationManager::getContextSpecificFrameworkConfiguration is called, wich itself calls three steps in order.

Important

Here it gets most interesting. Form settings are overruled by plugin TS.

  • Form
  • Plugin TS
  • Flexform

This explains the unexpected behaviour.

Let’s see thee thre steps in details.

Reading the Plugin forms

Here the forms are read by FrontendConfigurationManager::overrideStoragePidIfStartingPointIsSet.

TypoScript Plugin Configuration, Second Call

FrontendConfigurationManager::getPluginConfiguration is called a second time and overrules the settings of the form.

Important

This not only causes the odd behaviour. It looks strange to call this settins a second time at all.

It’s to discuss if this part couldn’t be removed from the sources.

Flexform

As the last of the three steps flexform settings overrule.

FrontendConfigurationManager::overrideConfigurationFromFlexForm

This is the reason why you find the advice in the web to use flexforms as a workaround to overcome the strange order.

Applying stdWrap

After all configurations are merged into a common array, stdWrap settings are evaluated:

$GLOBALS['TSFE']->cObj->stdWrap($conf['storagePid'], $conf['storagePid.']);

Recursive Folders

If the storage folders have subfolders, recursion can now be applied. It is taken from the setting:

$conf['persistence']['recursive']

This was basically resolved within the same process as the storage pid and hence shows the same odd behaviour, that TypoSccript settings overrule the form.

The final result is a comma separted list of storage pid.