Can't sort repeater elements

[stefan-scholl]

Short description of the issue

Can't sort elements of a repeater as described here: https://processwire.com/talk/topic/1674-sorting-repeater/#comment-15457

Expected behavior

I need new elements to be at the end by sorting them by "created".

Actual behavior

Sorts according to "sort".

See https://github.com/processwire/processwire/blob/3.0.36/wire/modules/Fieldtype/FieldtypeRepeater/FieldtypeRepeater.module#L627

When deleting elements in between and adding new ones you get a sort number lower than the highest sort number. That's why the newest entries aren't at the end.

Optional: Suggestion for a possible fix

Use the sorting set in the (system) template of the repeater. As described in the forum 2012.

Steps to reproduce the issue

1. Fill Repeater with multiple items. Save.
2. Delete items before the last one. Save.
3. Enter new item. Save.
4. See the new item isn't the last in the list.

Setup/Environment

• ProcessWire version: 3.0.36

[Toutouwai]

Use the sorting set in the (system) template of the repeater. As described in the forum 2012.

You would actually have to set the sort order on the parent page/template, not in the repeater template. Ryan explains this a couple of posts down from the post you linked to. Seeing as the parent uses the admin template you would want to set the sort on the page so as not to affect other children of the admin template. This would have to be done on every parent page for each page that has the repeater, so not a practical solution. It doesn't work in any case because the "sort=sort" in the selector ignores the forced sort set for children.

I need new elements to be at the end

New repeater items are added at the end (bottom) by default, aren't they?

I agree that it would be useful to set a forced sort order for repeaters in the field settings. But as a workaround you can force a sort order with a hook. In /site/ready.php...

$this->addHookAfter('FieldtypeRepeater::wakeupValue', function($event) {
    $field = $event->arguments('field');
    if($field->name !== 'my_repeater') return;
    $pa = $event->return;
    $pa->sort("-created"); // or whatever sort you want
    $event->return = $pa;
});

It's not a perfect solution because users can still drag repeater items up and down - the forced sort is only shown after page save.

[stefan-scholl]

The items get the count of all items as sort value. The intention of this may be that it lands at the end of the list. But when you delete items before the last element, the new item gets a sort value below the one of the last item.

This should either be maximum sort value + 1 or after every deletion the whole list needs to get new sort values.

This would solve my problem. It wouldn't make the answer from 2012 possible again because sorting is hard coded to the sort field.

[ryancramerdesign]

I wasn't able to duplicate this issue using the provided instructions. Let me know if I missed something?

1. Add 3 new repeater items (item1, item2, item3) in that order. Save.
2. Delete item1 and item2. Save.
3. Add new item4. Save.
4. The list now shows item3 and item4, in that order.

Note: "item1", etc. is the "title" I used for the repeater items, not the auto-assigned number.

What I was looking for, to duplicate the issue, was to see item4 before item3. Did I miss something?

It's also possible that in fixing the previous issue you posted, it also corrected this issue? Let me know if you continue to experience it, or if I missed something.

Btw, the sort by "sort" is intentional because repeaters are drag-drop sortable. I do have on my roadmap to support an option for custom sort fields in the near future though.

[stefan-scholl]

I'm sorry. I don't have time to try it with the old project. I can't reproduce it in a new project with 3.0.39. The difference is: This time I'm not creating the repeater items from code.

In the hectic of the project I forgot to mention this: Creating a repeater item from code seems to be different from the backend. It uses the current count as the new sort and when you deleted something in the backend the sort values didn't change. So when the third item stays and has a sort of 3 and item 2 gets deleted, the new item gets a 2 as the sort value.

You can give this a low priority until I can make a better description with real code. Sorry for the inconvenience.

[ryancramerdesign]

I'm going to close this issue since it's been a few months and we've not heard of it re-occurring. But let me know if you find it pops up again. As for the values assigned to sort when working from the API vs editing in the admin, it is true that you may need to account for them in some API usages. On the interactive side, InputfieldRepeater adjusts the sorts according to the values submitted in the POST request. If you find things not going in the order you want on the API side, you may need to account for it in a similar manner.