Bug #14775
closed
Editing ExtList in Install Tool prevents Extension Manager from installing any more extensions.
0%
Description
If someone accidentally changes the ExtList in the Install Tool (for instance, by 'tabbing' through and accidentally hitting some key or other as they go by) or, even if they change it on purpose, the Extension Manager is no longer able to install or uninstall any extensions, because it modifies the first instance of ExtList in localconf.php, and the Install Tools's second instance takes precedence.
I would recommend one, or both, of the following solutions:
Solution A:
Create a simple Checkbox just above ExtList. This wouldn't store yet another variable, but would instead have a simple JavaScript function attached to that would enable editing of the 'ExtList' textbox upon clicking it (i.e. editing that 'ExtList' textbox would be disabled by default.) It might says something like:
[_] I understand the risk associated with editing this value outside of the EM, and want to change it anyway (NOTE: This might render the EM unusable!)
Solution B:
Add a feature to the extension manager where it checks for multiple occurances of 'ExtList' in localconf.php and output an error if there are multiple instances. You could take it even further by doing any number of the following:
-Compare all instances of 'ExtList' and tell what differences there are. If there aren't any, delete all but the first occurance.
-Just automatically remove all but the first occurance of 'ExtList', no warning,
-Always add an additional entry every time something is changed (this would make localconf get big real fast. Not very good option)
-Offer the error, and provide a list of options to automatically fix the error, including possibly the option for the user to manually edit an entry that would then be saved as the first occurance deleting all other occurances.
-Something else?
(issue imported from #M1137)
Files
Updated by Rupert Germann almost 19 years ago
I can reproduce this:
if the extlist in the install tool was changed it's impossible to install extensions. The double occurence of $TYPO3_CONF_VARS['EXT']['extList'] seems to prevent this.
Updated by Stephane Schitter over 18 years ago
The root cause of the issue actually is the fact that the install tool writes variable names into localconf.php with double quotes (such as $TYPO3_CONF_VARS["EXT"]["extList"]) whereas the extension manager uses variables with single quotes (like $TYPO3_CONF_VARS['EXT']['extList']).
Typo3 has variable finding code (look for "setValueInLocalconfFile") but this one works only when variable names are really identical (same quotes system). Therefore we simply need to rationalise which quotes we use.
Given the move to single quotes these days, I have therefore submitted here a patch that changes all double quotes from the install module into single quotes.
This removes the issue (for people who have not yet encountered it -- for the others, they should remove the $TYPO3_CONF_VARS["EXT"]["extList"] with double quotes that was added by the install tool).
We also need to make sure future packages (dummy, etc...) include a localconf.php with single quotes only. There is also the upgrade path, for someone who has a localconf.php file with double quoted variables.
Updated by Stephane Schitter over 18 years ago
My last comment was confusing : it should read "We also need to think about the upgrade path, for someone who has a localconf.php file with double quoted variables. Should install tool reload existing localconf.php and rewrite it with all single quotes?"
Updated by Stephane Schitter over 18 years ago
The installtool-quotes_v2.patch now resolves the issue of someone having an existing localconf.php with possible mixed single-quotes/double-quotes variable names.
The new patch will make sure that existing double-quotes variables are converted internally to single quotes and written as single-quotes variables when the user changes a value through the install tool. Therefore the localconf.php will gradually be converted to single-quotes variables, as the admin uses the install tool to change values.
Updated by Karsten Dambekalns over 18 years ago
Isn't 1182 fixed by now (by Ingmar?), so that this bug would be solved, too?
Updated by Stephane Schitter over 18 years ago
As far as I can see, it is not fixed in the latest CVS code...
Updated by Karsten Dambekalns over 18 years ago
I just proposed a patch fpr #14806, it would fix this one, too.
Updated by Stephane Schitter over 18 years ago
The patch for 1182 does not seem to cover all cases where the install tool writes double quotes, and I think we need to handle the case where variables with double quotes exist in the already present localconf.php for the old installs getting upgraded.
Updated by Karsten Dambekalns over 18 years ago
shelob, could you explain this in more detail?
The only issue I see is indeed that this will not change the quotes for existing settings until they are eventually changed. So it will not "repair" existing localconf.php files.
Besides this case, are there more?
Updated by Karsten Dambekalns over 18 years ago
I had another look. Indeed it seems as if not all changes to localconf.php are made through the method affected by the patch for #14806. I'll check again.
Updated by Stephane Schitter over 18 years ago
Karsten,
Basically if you only try to make Typo3 generate single quoted variable from now on, and not dealing with existing double-quoted variables you have a problem, as the setValueInLocalconfFile will have trouble identifying that the double-quoted variable and the single-quoted variable are actually the same value. So could end up with a localconf.php file having for example:
TYPO3_CONF_VARS['SYS']['whatever'] = "value1";
TYPO3_CONF_VARS["SYS"]["whatever"] = "value2";
This should not be a big problem as TYPO3 and php will only use the last value defined, in this case "value2". However the function setValueInLocalconfFile will always try to replace the songle-quoted instance of the variable, hence the "value1". This has the effect described in this very bug report --> you are trying to update values in localconf.php through TYPO3 (for example adding an extension), however the effect is that only the first instance is changed, and the second instance is the one that PHP will read, as it is the last one.
Quite difficult to explain, but please look at my patch , it's not too long, and it should handle all these difficult cases.
Updated by Oliver Hader over 15 years ago
No change required anymore since install tool writes with single quote.
Closed during Bug Day 07/2008