Should sorting entries in "Filtered Views" always start with "1" (again)?

[twiro]

@jonmifsud - While playing around with the latest version of this extension (using filtered ordering for the first time) I wondered if the current behavior is the intended one:

I would have expected that sorting a filtered view (after having set the corresponding field as "filtered ordering"-field) would result in a "subset"-sorting that always starts with "1".
That at least is what this extension was doing before the latest changes and which was a useful behavior for tasks like sorting images for articles and like.

At the moment the first number when sorting a filtered view, seems to be somehow dependent on the lowest number that's currently existing in the filtered subset of entries. So if I start sorting 3 images with the sorting values "4, 8, 9" i get "4, 5, 6" instead of the expected "1, 2, 3".

If I manually change the sorting nr. of the first entry to "1" I actually achive the "1, 2, 3"-sorting, but it looks like a manual change causes quite some chaos in other entries that do not belong to the filteres subset.

I hope this is a bug and not the way this feature is intended to work.
Setup is latest integration branch on S.2.6.3.

[jonmifsud]

So this is partially intended; I'm sure it can be resolved but I'll explain the overall situation.

1. If you're not using 'filtered ordering' yet you use filters in your view, resetting the order to 1 every time is not ideal. It will mess up your unfiltered orders. (I think this might have been the case before and not sure how far the issue goes)
2. Since there is also pagination for very long lists, the page starts off with the current minimum value as a starting point (or if this is too low, the minimum value possible considering the page you are on). As here again setting the value to 1 would have unexpected results.

I'm happy to set the sorting to start from 1 or give an option. But I want to make sure it doesn't cause issues with anyone's workflows.

[nitriques]

@jonmifsud I do not know if it's related but when creating the first entries in a new section the ordering is at 0 for everything... I must investigate further because after the first manual sort, it works.

[twiro]

As Nicolas is currently cleaning up the issue-list of this extension (hooray!) and this seems to be the last current issue left I think it's about time to write a follow-up to my initial post.

First things first: I misunderstood what "Filtered Ordering" actually meant in my initial post. This issue has nothing to to with that feature. It's solely about the basic functionality of sorting entries in a "Filtered View".

Before version 2.2.0 sorting entries in a filtered view always resulted in "1" as sorting value for the first entry followed by "2", "3" and so on for the following entries. I admit that one could argue if this is the "right" logic behind the sorting-process as without doubt this produces a lot of entries with the same sorting value in a section, but - if by intention or not - this was the way this extension handled sorting entries in filtered views from the beginning on and so it was not only the expected behavior for a long time but also the one that perfectly matched the way I used this field in nearly every Symphony project over the last years.

@nickdunn himself described this (as I guess pretty common) use case back in the early days of the extension - but I'll try to put it down more generally:

• You have a section "Parents"
• You have another section "Children"
• Entries of the section "Parents" are associated with entries of the section "Children" via SBL/Association-field in the latter one (in a one-to-many-relationship)
• Entries in the section "Children" can be sorted via order entries
• Watching/Sorting children-entries only makes sense in "filtered views" showing a subset of entries belonging to one single parent-entry. (Therefore I usually remove the Children-section from the backend-navigation and make it only accessible through links to filtered subsets)

This setup matches a lot of scenarios but the most common one might be linking a bunch of images (children) to an article/product/project/gallery/whatsoever (parent). And in this case getting sorting values starting with "1" when reordering children-entries in a "filtered view" not only makes perfect sense but also avoids some confusion.

If you're not using 'filtered ordering' yet you use filters in your view, resetting the order to 1 every time is not ideal. It will mess up your unfiltered orders. (I think this might have been the case before and not sure how far the issue goes)

Well apart from having entries with the same sorting value (which is not a problem at all in the scenario outlined above) sorting a filtered set of entries never messed up the currently "hidden" entries. It simply doesn't touch them - which is exactly what I want.

Since there is also pagination for very long lists, the page starts off with the current minimum value as a starting point (or if this is too low, the minimum value possible considering the page you are on). As here again setting the value to 1 would have unexpected results.

I see how the new behavior makes sense in that context but I must admit that I never used order entries in combination with paginated publish-index-views - as far as I understand there is no way to drag and drop (=resort) entries across pages. Meaning pagination introduces totally arbitrary "limits" for my possibilities to manually resort entries. So even for the rare edge cases where I have a really huge set of entries that can be sorted manually I would always prefer an unpaginated table of entries with "full" sorting capabilities.

And as manually sorting entries is getting less comfortable and useful with every single entry added I most exclusively use this feature for sorting rather small (and therefore often filtered) sets of entries (<30) in my projects.

So in my eyes having really large manually sortable lists (500+) that require pagination to stay manageable looks a lot more like an uncommon edge case than the scenario described above.

I'm happy to set the sorting to start from 1 or give an option. But I want to make sure it doesn't cause issues with anyone's workflows.

Well... at least for me the current solution is causing issues with my workflow. Right now I'm still stuck with version 2.1.3 of this extension in nearly all of my Symphony projects.

I guess changing the behavior of sorting filtered entries was simply meant as a "bugfix" in your eyes, but I hope I made clear why for me (and probably others too) this change is not fixing issues but rather introducing new ones.

And as I see this change as a "breaking change" (and therefore something that shouldn't have been introduced before version 3.0 of this extension) I'm all for reverting the 2.X-branch back to the old behavior and adding the new behavior as an option.

If the new behavior fits better into the workflow of the majority of Symphony developers I'm all fine with changing things in the next major release of this extension and making the old behavior an option and the new one the default one.

So I would be really interested in what others think about this? @nitriques @michael-e @animaux @nilshoerrmann - any opinions?

[animaux]

@twiro I agree.

[munki-boy]

@twiro as a user of the extension I agree with you.

[nitriques]

While I can see the use case, I do not use it. So it's hard for me to take that decision. I would be willing to review any PR that would fix bugs, even if it's by removing some feature (sadly) if the community express this wish.

But I like the idea of the concept of having multiple order based on the filter. Maybe we need to fix some bugs ?

[jonmifsud]

Hey Guys; the filters are not directly related to the order number. The
order number not starting from 0 was actually linked to allowing
pagination. So maybe there is a fix to implement there.

Having sortable entries which possibly contain a 100+ items makes it fairly
hard to 'assume' that we know what the sort order is. I have no issue if we
consider this a breaking change and switch it to version 3.x which would
have made sense. The issue I'm still facing at times when sorting and
paginating, is how would you deal with moving an item from page 2 to page
1, and viceversa

Jonathan Mifsud
Founder and Lead Developer
T +356 9983 0394 <+35699830394> E jon@maze.digital W maze.digital

On Fri, Nov 18, 2016 at 2:13 AM, Nicolas Brassard notifications@github.com
wrote:

While I can see the use case, I do not use it. So it's hard for me to take
that decision. I would be willing to review any PR that would fix bugs,
even if it's by removing some feature (sadly) if the community express this
wish.

But I like the idea of the concept of having multiple order based on the
filter. Maybe we need to fix some bugs ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#74 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA0efxDtMbk_WhyyKtzs7w9NCRbnJxxZks5q_PuvgaJpZM4GJp7y
.

[twiro]

Thanks for the feedback everyone!

While I can see the use case, I do not use it. So it's hard for me to take that decision. I would be willing to review any PR that would fix bugs, even if it's by removing some feature (sadly) if the community express this wish. But I like the idea of the concept of having multiple order based on the filter. Maybe we need to fix some bugs?

You got me wrong here, Nicolas - I'm not proposing to remove the new "Filtered Ordering"-feature - which I too don't use yet, but understand the concept and its possible benefits.

I'm solely talking about sorting entries in "Filtered Views" - this has been possible from the beginning of this extension, but with version 2.2.0 the logic behind calculating sorting values has changed - an imho not in a way that improves the behavior of this extension.

Regarding the new "Filtered Ordering"-feature I only dislike the fact that it makes talking about the functionality of this extensions way more complex than before... and obiously produces a higer rate of misunderstanding ;)

The order number not starting from 0 was actually linked to allowing pagination. So maybe there is a fix to implement there.

I guess you mean "1" instead "0" - right? I totally understand that the change you implemented is required to make it possible to combine pagination and sorting of entries, but after playing around with the latest version of this extension a little bit I must say that this is the only use case where the new sorting-values-logic introduced in version 2.2.0 makes sense too me.

In all other cases the old solution looks superior to me - especially as the new behavior doesn't prevent producing multiple entries with the same sorting value at all. It just adds rather random starting values for sorting entries in "Filtered Views".

And as the scenario of manually sorting entries in paginated publish-index-tables really looks like the more uncommon use case to me (compared to sorting entries in an unpaginated table) I would propose to implement the following changes:

Proposal

1. Disabled pagination should be the default - "Enable Pagination" should be an option.
2. Sorting entries in a "Filtered View" should always start with "1" as sorting value for the first entry.
3. When pagination is enabled the sorting-logic should shift to the new/current behavior and respect the lowest sorting-value of the current page as starting point for calculating sorting-values.
4. When creating a new entry in a "Filtered View" the sorting-value of this entry should be based on the highest sorting-value of the subset of entries included in that particular "Filtered View" - and not on the highest sorting-value of all entries in the section. (This indeed would be new behavior too, but when using filtered views to sort entries and agreeing upon using "1" as starting value I can't see how this would not make more sense then the old/current solution)

---

This would mostly respect the "old" workflow (the way this extension used to work before version 2.2.0) and additionally make paginated sorting possible.

Things would get complicated if one would start to combine pagination and "Filtered Views" and then try to resort entries, but thinking about this I'd say - this simply should not be done at all!!!

So I would like to know what others think about this proposal - I guess @animaux and @munki-boy agree, but more opinions would be welcome!

And - to be honest - this is just conceptual thinking. I probably won't be able to implement these changes myself if we'd agree upon them... though I'd surely give it a try if no one else would take care of it.

[twiro]

Renamed the issue to "Should sorting entries in "Filtered Views" always start with "1" (again)?".
For a better understanding what it's really about :)

[munki-boy]

@twiro I don't understand all the conversation but I agree because the old way seemed odd but workable and I used it a lot.

@jonmifsud You can always go in and type the position you want if you allow the field to be shown within the entry page. After saving the rest of the sequence gets shifted to make room. Maybe pagination can be more flexible though so we can show a certain chunk of entries at a time, with the little filter control above the list of entries. Which would also be useful for picking entries in ERF.