Project

General

Profile

Actions
Copy link

Bug #88533

closed

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

Added by Leonie Philine over 5 years ago. Updated 5 months ago.

Status:
Rejected
Priority:
Should have
Assignee:
-
Category:
Extbase
Target version:
Candidate for patchlevel
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();
    }
}

Related issues 1 (1 open — 0 closed)

Related to TYPO3 Core - Bug #90949: persistence.storagePid ignores startingpoint (pages), when it is a stdWrapNew2020-04-04

Actions
Actions
Copy link
 #1

Updated by Leonie Philine over 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
Copy link
 #2

Updated by Leonie Philine over 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
Copy link
 #3

Updated by Alexander Schnitzler over 4 years ago

  • Tags set to configuration typoscript
Actions
Copy link
 #4

Updated by Bastian Stargazer over 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
Copy link
 #5

Updated by Johannes Rebhan about 1 year ago

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

Actions
Copy link
 #6

Updated by Ayke Halder 6 months ago

  • Related to Bug #90949: persistence.storagePid ignores startingpoint (pages), when it is a stdWrap added
Actions
Copy link
 #7

Updated by Georg Ringer 5 months ago

  • Status changed from New to Rejected

we try to get rid of stdWrap as it makes things complicated because evaluating stdwrap requires a lot of performance. however, your requirement can now be easily configured by using env variables.

give me an example:

TS

plugin.tx_ttaddress.persistence.classes.\FriendsOfTYPO3\TtAddress\Domain\Model\Address.newRecordStoragePid = {$newId}

the newId can either be configued in sites/yoursite/config.yaml with

newId: 4

or by using env variable and

newId: '%env(MYENV)%'
Actions
Copy link

Also available in: Atom PDF