-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should sorting entries in "Filtered Views" always start with "1" (again)? #74
Comments
So this is partially intended; I'm sure it can be resolved but I'll explain the overall situation.
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. |
@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. |
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:
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.
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.
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.
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? |
@twiro I agree. |
@twiro as a user of the extension I agree with you. |
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 ? |
Hey Guys; the filters are not directly related to the order number. The Having sortable entries which possibly contain a 100+ items makes it fairly Jonathan Mifsud On Fri, Nov 18, 2016 at 2:13 AM, Nicolas Brassard notifications@github.com
|
Thanks for the feedback everyone!
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 ;)
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
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. |
Renamed the issue to "Should sorting entries in "Filtered Views" always start with "1" (again)?". |
@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. |
@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.
The text was updated successfully, but these errors were encountered: