Project

General

Profile

Actions

Bug #88533

open

`persistence.classes.*.newRecordStoragePid` does not get `stdWrap` applied (other than `persistence.storagePid`)

Added by Leonie Philine almost 5 years ago. Updated 6 months ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
Extbase
Start date:
2019-06-09
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
9
PHP Version:
Tags:
configuration typoscript
Complexity:
easy
Is Regression:
No
Sprint Focus:

Description

See \TYPO3\CMS\Extbase\Persistence\Generic\Backend::determineStoragePageIdForNewRecord():

if (isset($frameworkConfiguration['persistence']['classes'][$className]) && !empty($frameworkConfiguration['persistence']['classes'][$className]['newRecordStoragePid'])) {
    return (int)$frameworkConfiguration['persistence']['classes'][$className]['newRecordStoragePid'];
}

This makes `persistance.classes.*.newRecordStoragePid` unusable with the good practice of storing PID values in the site config.yaml as single source of truth, like that:

plugin.xyz.persistence.classes.Vendor\Ext\Domain\Model\FrontendUser {
    newRecordStoragePid.dataWrap = {site:pages.frontendUsers}
}

This approach does work with `persistence.storagePid`, because in `\TYPO3\CMS\Extbase\Configuration\AbstractConfigurationManager::getConfiguration()`, `stdWrap` is applied:

if (is_array($frameworkConfiguration['persistence']['storagePid'])) {
    // We simulate the frontend to enable the use of cObjects in
    // stdWrap. Than we convert the configuration to normal TypoScript
    // and apply the stdWrap to the storagePid
    if (!$this->environmentService->isEnvironmentInFrontendMode()) {
        \TYPO3\CMS\Extbase\Utility\FrontendSimulatorUtility::simulateFrontendEnvironment($this->getContentObject());
    }
    $conf = $this->typoScriptService->convertPlainArrayToTypoScriptArray($frameworkConfiguration['persistence']);
    $frameworkConfiguration['persistence']['storagePid'] = $GLOBALS['TSFE']->cObj->stdWrap($conf['storagePid'], $conf['storagePid.']);
    if (!$this->environmentService->isEnvironmentInFrontendMode()) {
        \TYPO3\CMS\Extbase\Utility\FrontendSimulatorUtility::resetFrontendEnvironment();
    }
}
Actions #1

Updated by Leonie Philine almost 5 years ago

  • Subject changed from `persistance.classes.*.newRecordStoragePid` does not get `stdWrap` applied (other than `peristence.storagePid`) to `persistence.classes.*.newRecordStoragePid` does not get `stdWrap` applied (other than `peristence.storagePid`)
Actions #2

Updated by Leonie Philine almost 5 years ago

  • Subject changed from `persistence.classes.*.newRecordStoragePid` does not get `stdWrap` applied (other than `peristence.storagePid`) to `persistence.classes.*.newRecordStoragePid` does not get `stdWrap` applied (other than `persistence.storagePid`)
Actions #3

Updated by Alexander Schnitzler about 4 years ago

  • Tags set to configuration typoscript
Actions #4

Updated by Bastian Stargazer about 3 years ago

It would be amazing if this feature would still work with Extbase/Persistence/Classes.php. In our system we have multiple storage folders for a lot of different custom records and their dependencies. To configure on a model/entity basis where it should persisted makes absolutely sense, as the TS setting for plugin/module.tx_ext.persistense.storagePid just pointing to the root sys-storage-folder.

return [
    \Vendor\Ext\Domain\Model\Books::class => [
        'newRecordStoragePid' => '123', // this could come from getenv('T3_STORAGE_PID_BOOKS')
    ],
    \Vendor\Ext\Domain\Model\User::class => [
        'newRecordStoragePid' => '987', // this could come from getenv('T3_STORAGE_PID_USERS')
    ],
];

Adding dynamic database IDs hard-coded to site-config yaml or PHP config files always feels bad practice. Background: the PIDs of storage-folders might be different on various environments like test, beta, staging, live, etc...

With this setting, the record persistence could be the same for FE plugins and BE modules, which would be so much easier to handle!

Actions #5

Updated by Johannes Rebhan 6 months ago

So... this bug report is still true in v12.

Actions

Also available in: Atom PDF