Strange behaviour of TYPO3_CONF_VARS tests

[hannesbochmann]

I created a test to check the configuration of an extension. The field I'm checking against contains numeric values. I want to make sure that the number in that field is greater than 4 so i would expect to put in the following test configuration:

EXT|extConf|myext|numeric_value_field>=5 or EXT|extConf|myext|numeric_value_field>4

The first line reads to me as follows (like the label of the test configuration field suggests): The actual value of EXT|extConf|myext|numeric_value_field is greater than or equals to 5. But that's not what is done in the code. The check is reversed leading to: 5 is greater than or equal to the actual value of EXT|extConf|myext|numeric_value_field which allows only values from 0-5 and not like expected greater than or equal to 5.

So the only working solution would be to reverse the condition of the first line.

EXT|extConf|myext|numeric_value_field<=5

I thought reversing the condition of the second line would do the same trick but it didn't.

The problem only applies to the lower and greater than comparisons as it matters on which side of the comparison a value is. For equal/not equal and regex comparisons there isn't a similar problem.

Do I miss something, is this intended behaviour or a bug?

[IchHabRecht]

Hi @hannesbochmann,

I guess you haven't noticed that the extension configurations are serialized, thus no direct comparison with any field is possible. If I remember correctly, caretaker doesn't unserialize those values on its own.

[hannesbochmann]

I have noticed that. Memories can be elusive ;-) caretaker_instance unserializes the values on it's own. See here So a direct comparison should be possible.

P.S. This line causes another bug. $value = $GLOBALS seems to create a reference to $GLOBALS. This leads to a changed value in $GLOBALS when unserializing. (See here) If another extension reads it's extension configuration after caretaker_instance has done it's stuff during this request it might happen that an unserialize is done on the already unserialized value leading to a PHP warning.

[hannesbochmann]

ping

[etobi]

thanks for reporting. should be fixed now. could you please retest?

[hannesbochmann]

Your referenced commit only fixes the second problem I mentioned in my second last comment. The initial problem won't be fixed by that. Or did you simply miss to reference the correct commits?