Project

General

Profile

Actions

Bug #87951

closed

Silent configuration upgrade removes existing entries in $GLOBALS[EXTENSIONS]

Added by Stefan P about 5 years ago. Updated about 4 years ago.

Status:
Rejected
Priority:
Must have
Assignee:
-
Category:
-
Target version:
-
Start date:
2019-03-19
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
9
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:
Needs Decision

Description

We already used $GLOBALS[EXTENSIONS] in a TYPO3 8 project to be prepared for TYPO3 9. We accessed them "by hand" (reading from $GLOBALS[EXTEMSIONS][our_ext]@ directly), and wanted to convert to the new API.

When installing TYPO3 9 the silent configuration upgrade removed these entries and we had to re-add them manually.

All our projects are versioned, so we could easily restore everything, but the core should not silently just drop existing entries in LocalConfiguration.php, it should rather only add them.

Actions #1

Updated by Stefan P about 5 years ago

I just found out that the problem is even worse. All custom entries are dropped always.

Is it mandatory to have the settings also in ext_conf_template.txt starting with TYPO3 9? This is not documented as far as I can see.

We always stored settings in LocalConfiguration.php at the extensions, even if not editable in backend (i.e. having no explicit ext_conf_template.txt). Is the only way to creatre one?

Actions #2

Updated by Georg Ringer about 4 years ago

  • Sprint Focus set to PRC
Actions #3

Updated by Susanne Moog about 4 years ago

  • Status changed from New to Rejected

$GLOBALS['EXTENSIONS'] is TYPO3s reserved space for extension configuration. The configuration there needs to be defined in ext_conf_template, to allow TYPO3 to keep the configuration in sync (and react to changing configuration options on ext upgrades). The synchronize feature means that if an extension removes or adds options in its configuration definition, TYPO3 automatically takes care of updating the settings avoiding missing or superfluous configuration.

ext_conf_template provides the schema for the configuration, ExtensionConfiguration class provides the API.

If you want a simple global space without an API available, you should use something more unique to your own project / namespace, if you want the benefit of using TYPO3s intended API you need to use the defined schema file.

Further notes: One thing that the API should achieve would be to make future migration to different configuration storages easier. If accessing extension configuration is done via the API one could think of further features like moving the configuration away from the globals space, overlaying extension and site configuration etc.

Actions #4

Updated by Benni Mack about 4 years ago

  • Sprint Focus changed from PRC to Needs Decision
Actions

Also available in: Atom PDF