Finder::standardizeOrderingValue() doesn't properly support multi-column sorting

[Xon]

Affected version

2.3.9

Finder::standardizeOrderingValue() doesn't correctly handle the direction argument, and this results in the multi-column sorting via the ThreadRepository::getDefaultThreadListSortOptions not working as expected.

Suppose an add-on defines a new multi-column sort option like so;

public function getDefaultThreadListSortOptions($forAdminConfig): array
{
    $options = parent::getDefaultThreadListSortOptions($forAdminConfig);
    $options['MyNewColumn'] = [
        ['MyNewColumn'],
        ['last_post_date'],
    ];
    return $options;
}

If this custom sort is then a thread default, the Finder::setDefaultOrder is called like this:

$finder->setDefaultOrder([
 ['MyNewColumn'],
 ['last_post_date'],
], 'desc');

But this generates this SQL

order by MyNewColumn asc, last_post_date asc

This makes defining custom multi-columns filtering via getDefaultThreadListSortOptions basically impossible, as the direction filter option is ignored.

 

[Xon]

Looking into this, the issue is somewhere in standardizeOrderingValue not respecting the $direction flag as expected.

This is the root cause behind this bug; https://xenforo.com/community/threa...-differences-in-multi-column-ordering.195270/

 

[Xon]

The standardizeOrderingValue function overwrites the $direction argument, reliably triggering this is annoying

protected function standardizeOrderingValue($field, $direction = 'ASC')
{
    if (is_array($field))
    {
...
        foreach ($field AS $entry)
        {
            if (is_array($entry))
            {
                $direction = strtoupper($entry[1] ?? 'ASC');
                if (!$direction)
                {
                    $direction = 'ASC';
                }

 

[Xon]

Finder::order() basically interleaves the functionality of Finder::standardizeOrderingValue + Finder::renderToOrderSqlParts, but ends up having some subtle differences that make keeping the two copies in sync complex