Project

General

Profile

Actions

Feature #77792

closed

Extension Manager and Install Tool ignores values from AdditionalConfiguration.php

Added by M. Stichweh over 7 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
-
Target version:
-
Start date:
2016-09-02
Due date:
% Done:

0%

Estimated time:
PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

Overridden configuration in AdditionalConfiguration.php is not processed by the Extension Manager and the Install Tool. So the only way to verify the current configuration is the Configuration tool. But especially the serialized extension configurations are very hard to read.

I have already read the issue #60650 and understand the problems here. But the biggest issue is if you are using TYPO3_CONTEXT dependent configurations. This is a very nice feature of Typo3 and absolutely essential for Continuous Integration. In Typo3 4.x you could specify these context configurations (eg. with the help of the "environment" extension) in context specific files and since these files were included after the configuration in localconf.php they are also recognized by the Extension Manager and installer. Furthermore if you update some value it was appended to the end of localconf.php and overrides the context config too. So everything worked as expected. Now since Typo3 6 you cannot see the current configuration depending on the TYPO3_CONTEXT and you even cannot change it since it is always stored in LocalConfiguration.php which is overridden by the AdditionalConfiguration.php values. Just enabling logging mode for an extension through the Extension Mananger on a production system is not possible for example.

In my opinion it is absolute necessary to see context dependent configurations in Extensions Manager and installer and to have the ability to (temporary) override them though these tools. Otherwise is it very confusing if you see debug configurations on production systems for example.

There could be two approaches to solve this problem, both require explicit configuration files for different contexts. This would also be one step forwards for the application context feature since you would have an easy and intuitive way to configure Typo3 for each environment:

  1. Provide context specific defaults in separate files which are overridden by LocalConfiguration.php (LocalConfiguration.php has higher priority). In this case only the getLocalConfiguration() method in ConfigurationMananger has to be modified to read these context specific files and merge it with the LocalConfiguration. Modifications in Extension Manager or installer would also override context values. But this approach is a little bit different to the current implementation with AdditionalConfiguration.php and you have to ensure that no value is defined in LocalConfiguration.php if you set it in one of the context specific default files
  2. Another solution will be to have static defined configuration files for the different contexts, like LocalConfigurationOverrides.Development.php or LocalConfigurationOverrides.Production.Staging.php, which overrides the LocalConfiguration.php values. The merge is always done in getLocalConfiguration()@so that Extension Manager and installer shows the correct values. If values are modified and written to file you have to check were the current value is read from. So if the value comes from a context specific file, write it there, otherwise write it to @LocalConfiguration.php. In this case you always see what currently is configured and when storing configuration the correct file is modified, so you can also change values via Extension Manager and installer. This means for the ConfigurationManager that getLocalConfiguration() has to merge the configurations, in the modifying methods setLocalConfigurationValueByPath(), setLocalConfigurationValuesByPathValuePairs() and removeLocalConfigurationKeysByPath() it has to check where to store the config and writeLocalConfiguration() needs to know to which file it has to write.

In my projects I already use a modified ConfigurationManager.php where I have implemented the second case. Please find attached the modified class based on Typo3 version 7.6.10. Furthermore the configuration manager could write empty files for the current context to give a hint about this feature to developers.

I would be very happy to see an implementation of the second case or something else in one of the next releases / updates - would be nice for to have it also for version 7.x. And I think it is a must have for the TYPO3_CONTEXT feature to use Typo3 within Continuous Integration environment.


Files

ConfigurationManager.php (18.5 KB) ConfigurationManager.php Implementation of case 2 M. Stichweh, 2016-09-02 17:14
Bildschirmfoto 2020-03-05 um 23.13.34.png (65.8 KB) Bildschirmfoto 2020-03-05 um 23.13.34.png Georg Ringer, 2020-03-05 23:15
Actions #1

Updated by Susanne Moog over 7 years ago

  • Tracker changed from Bug to Feature
Actions #2

Updated by Peter Niederlag over 7 years ago

Strange this bug has been undiscovered for a long time. While it is perfectly reasonable und technically possible to override something like $GLOBALS['TYPO3_CONF_VARS']['EXT']['extConf']['bug_em_template']= 'a:1:{s:4:"demo";s:16:"hello world ADD1";}'; it is not possbile to read or write this value from the extension-manager.

Actions #3

Updated by Jakob Berlin over 7 years ago

Upvote! Just stumbled over it.

Actions #4

Updated by Georg Ringer about 4 years ago

Several improvements have been made since the issue has been created:

1.) Since 9 extension settions are persisted as regular array and not serialized anymore. For compat. reasons those are still saved serialized as well. Since 10, only array mode is available.

2.) The install tool does show possible troubles, a screenshot is attached

The mentioned option number 2 looks nice on 1st thought but it is not that easy for many people. There are a lot of options how a project can be configured and many issues you can have:

  • e.g, all configuration files don't have any write permissions
  • multiple configuration files, like I seen AdditionalConfiguration_Production.php and additional an extra file for subcontext AdditionalConfiguration_Production_Staging.php and both ship configurations,
  • Using dotenv e.g. https://github.com/helhum/dotenv-connector/

therefore I am closing this issue.

Actions

Also available in: Atom PDF