Milestone changed to Elgg 1.8.5 by cash on 42105657-07-19

trac user sembrestels wrote on 42346236-01-28

The problem is in PHP usort function, that inverts the order when two items are equal:

php > $array = array(1,2,3,4);
php > function srt($a,$b) {return 0;}
php > usort($array,"srt");
php > var_dump($array);
array(4) {
  [0]=>
  int(4)
  [1]=>
  int(3)
  [2]=>
  int(2)
  [3]=>
  int(1)
}

This may be fixed reverting the array before sorting.

trac user sembrestels wrote on 42346267-03-12

This is the easiest solution that I can think. Maybe you think we can do something else.

#212

brettp wrote on 42359375-01-30

Perhaps a cleaner solution would be to change the usort() function to return 1 if items are equal. Will still need a unit test for this, though.

trac user sembrestels wrote on 42359621-10-11

Yes brettpp, this can be a good one:

    public static function compareByWeight($a, $b) {
        $a = $a->getWeight();
        $b = $b->getWeight();

        return ($a < $b) ? -1 : 1;
    }

trac user srokap wrote on 42359724-10-18

sembrestels, see: http://php.net/manual/en/function.usort.php

The comparison function must return an integer less than, equal to, or greater than zero if the first argument is considered to be respectively less than, equal to, or greater than the second. 

So Your function should look like this:

    public static function compareByWeight($a, $b) {
        $a = $a->getWeight();
        $b = $b->getWeight();
        return $a - $b;
    }

trac user sembrestels wrote on 42359978-06-20

srokap Yes, we know. The problem is when the weights are equal, and the function returns 0, usort returns values in the reverse order.

For this reason, my first idea was reversing the array before sorting. An alternative is modify the function to return -1 when the first argument is considered less than the second and 1 when the first is equal to or greater than the second.

Milestone changed to Elgg 1.8.7 by cash on 42460627-02-17

cash wrote on 42506724-03-14

I think we are going to have to redesign the structure so that registration order is preserved. I'm pushing this off until Elgg 1.9. If someone comes up with a great solution before then we can always pull it in.

Milestone changed to Elgg 1.9.0 by cash on 42506724-03-14

trac user srokap wrote on 42506780-09-24

I was thinking about quite simple solution:

#293

Not very elegant but should do the trick. I didn't test this particular code but some time ago I wrote very similar one that worked fine.

cash wrote on 42506865-11-16

Thanks Paweł - that does look to handle the problem for Elgg 1.8.

Milestone changed to Elgg 1.8.9 by ewinslow on 42653928-09-20

trac user mrclay wrote on 42678192-01-10

I'm happy to test Paweł's branch if someone could tell me steps to reproduce the bug.

trac user srokap wrote on 42737080-11-08

If you register one by one, several menu items (A, B, C) without specifying priority and display them in menu ordered by priority, you expect them to stay in registration order, but receive random order. Apparently sorting algorithms in php are not static, so original order is not preserved.
Error appears randomly, try few cases.

trac user srokap wrote on 42819330-03-06

I see it's merged to 1.8 branch. Closing this ticket then.

bdb6d69

trac user Steve Clay <steve@... wrote on 42948158-05-10

In [changeset:"bdb6d69bc9d81b3cef39bc1b60df731ee81844d3/elgg"]:

#!CommitTicketReference repository="elgg" revision="bdb6d69bc9d81b3cef39bc1b60df731ee81844d3"
Merge pull request #293 from Srokap/ticket_3035

Fixes #3035 - menu items appearing in reverse registration order

trac user srokap wrote on 42948158-05-28

In [changeset:"86acb5cca828931505593c97d969ac60c2bc084f/elgg"]:

#!CommitTicketReference repository="elgg" revision="86acb5cca828931505593c97d969ac60c2bc084f"
Fixes #3035 - menu items appearing in reverse registration order