TYPO3 Core

I've had a look at your TS and made a simplified version to test it.
It looks like that because of the if.negate an OR is perfomed, so it doesn't check if both conditions are met, but if one of them is met.

Due to the structure of the "if" construct, it's simply not possible to use both isLessThan and isGreaterThan. isLessThan will override isGreaterThan, because the evaluation of isLessThan happens after that of isGreaterThan in the source code (see method tslib_content::checkIf()).

What you are trying to achieve is not possible. It would require to add logical operators support to the "if" construct and I think that would make it overwhelmingly complicated.

If I guess correctly, you are trying to achieve a multi-column menu. Is that right?

TSref tells you how to use it, but most of the people think, that "isLessThan" means the same as "<", but actually it means:

The value that follows is less than the value given as "value"

So the problem is not the order of the different conditions, but the fact that the values given to "isLessThan" and "isGreaterThan" are flipped in this example.

More precisely:
(({register:count_menuItems}+1)/4)*3
will return a higher value than
(({register:count_menuItems}+1)/4)*2

To give you an example:

10 = TEXT
10.if {
value = 2
isLessThan = 1
isGreaterThan = 3
}

will return true, because 3 > 2 and 1 < 2

But the example of the OP says

10 = TEXT
10.if {
value = 2
isLessThan = 3
isGreaterThan = 1
}

This will return false, because 3 !< 2 and 1 !> 2

So IMHO this bug can be closed.

But still it's not possible to use multiple conditions inside an "if". If you look at the code in tslib_content::checkIf(), you can see that - for exemple - if isTrue, isFalse or isPositive are evaluated to true, then none of the other conditions are going to be evaluated.

And isLessThan comes after isGreaterThan, meaning that the global result will be the one from isLessThan and not the one from isGreaterThan. In effect, it's behaving as a kind of "OR".

It could be an idea to clean up this method so that it behaves fully as if it used an "OR" operator, and introduce a flag to make it use a "AND". That would not be so complicated.

Actually it already uses AND, since $flag will be set to 0 as soon as any of the conditions returns false.

First it checks for stuff that doesn't need a value to compare.

If any of these returns false, the rest is not checked at all, which is ANDed behaviour.

If $flag is not set yet, it checks for isGreaterThan, isLessThan, equals and isInList in that particular order.

In my example:

3 is greater than 2 => go on
1 is less than 2 => go on

nothing to check for "equals" and "isInList", so return true.

You could even do something like this (although it's pretty useless)

10 = TEXT
10.if {
value = 2
isLessThan = 1
isGreaterThan = 3
equals = 2
isInList = 1,2,3,4
}

So a combination of conditions IS possible but only with ANDed conditions. But since the negation of AND is OR, you just have to use negate = 1 to get that behaviour.

Thanks for the clarification, now I get it. I didn't read the code properly. "if" is really awkward...

So I agree that this bug can be closed.

Not a bug.