Exposed Sorts
Coyote - February 29, 2008 - 19:18
| Project: | Views |
| Version: | 6.x-3.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | merlinofchaos |
| Status: | needs review |
| Issue tags: | views 3.x roadmap |
Description
You can sort in table views. But about 99% of the stuff I am working with for clients requires list views, but they still want users to be able to sort by things like author, date, etc.
It would be nice if, in addition to the standard paging, if you could easily have sort links appear for users in list views.
Is this here, and I'm just completely mad?
#1
This doesn't exist yet, but it will.
#2
I have a similar requirement (but don't need to expose the ability to the user). I would like the sort order of items in the list to be controlled via one of the fields in the view. Also, will this functionality be back-ported to 5.x ?
#3
CoolDreamZ: While I'm not sure precisely what you mean, I don't think what you ask is possible.
#4
Thanks, in writing up a more detailed explanation I have discovered that there is another configuration setting for a View. At the bottom of the View Edit page there is a collapsible section titled Sort Criteria. I added the required criteria here and voila I now have a List View sorted as I wish! So my requirement is fulfilled (but not that of the original post).
#5
That's also for VIews 1.0 and this issue is against Views 2 =)
#6
Just a note; I've pushed this feature back to Views 2.1. Sorry.
#7
#8
OK, darn! Thanks for all your work on this - it's a really great module.
I noted your suggested work around way back in 4.7 that we should create a clone view and then change the sort order. Then we can put links in a block, the view header or where ever we want.
#9
I am also in support of exposing sorts, so hopefully it gets into 2.1! Thanks!
#10
Yep, I was just looking for this as well :)
#11
+1 !!! =)
#12
Also looking for this.. nice to hear that it's in the works!
#13
subscribing
#14
I just installed 2.1. Has the feature been pushed forward or have I missed where you expose the sorting?
#15
subsribe, not just in list, hope to see this in grid too.
#16
suscribe, very interesting feature
#17
subscribing also.
#18
sounds great
#19
Based on the messages, Exposed Sort Funtionality will be available ? Which version of Views is targeted now, or is it dropped out of picture. Thank Merlin!!! Looks like we depend on you and you are very busy.
#20
could do with this feature also.
#21
Until the Sort Views Functionality becomes available, I am trying to find a way sort search results (or taxonomy/term/tid) via Views and Tabs.
Created a view for search results (default drupal search) with taxonomy term as argument, and
return arg(2) as php code. It works fine and I can sort this view in the way I want.
However, this way, I can set only 1 view.
The path for this view includes % parameter (related to the argument) and as such Views Menu tabs can not be set.
This is the point I stopped. What is the next step ???
Tried to use Quick Tabs, no result so far.
Any suggestions ?
Thanks,
#22
As a workaround, one could hack one of the views_alter hooks to change the sort order (e.g. based on an HTTP GET value) - but I haven't tried that yet.
Another possibility is to write a filter that does not filter, but only sorts (then you can expose it). I did that back in views1 and it kinda worked - not sure if this is still possible in views2.
#23
Thanks for the feedback. I was thinking to try exposed filters for this purpose. Will post if works somehow.
The other solution I found this morning is by using Quick Tabs along with Views. There is a patch that allows passing views arguments with %. Currently it worked with Taxonomy/term/tid and I will check to see for Sorting Search results with multiple tabs. Will post if works.
#24
+1 for sortable list (and grid) views!
#25
just subscribing, would love to have this feature
#26
subscribe.
#27
subscribing, and also echoing the requests for Grid sorting as well.
#28
subscribing
#29
The next person who posts to this issue had better post a patch, because it doesn't do anyone any good post 'Yea me too" to this issue. Yes, we know you want it.
#30
subscribing, sry just kidding :)
i worked now a little on the patch, its not a even a first development version, just playing around
one problem is that i cannot get a table in the style options, see the attachment
#31
My work around is to manually case some sorts the PHP header of a view...
<?php$view = views_get_view('uc_products');
//drupal_set_message('<pre>'.print_r($view->display['page_1']->display_options['sorts'],1).'</pre>');
if (arg(1)=='popular') {
$view->display['page_1']->display_options['sorts']= array(
'totalcount'=> array(
'order' => 'DESC',
'id' => 'totalcount',
'table' => 'node_counter',
'field' => 'totalcount',
'override' => array('button' => 'Use default'),
'relationship' => 'none',
));
$view->save();
}
elseif (arg(1)=='new') {
$view->display['page_1']->display_options['sorts']= array(
'timestamp'=> array(
'order' => 'ASC',
'id' => 'timestamp',
'table' => 'node_counter',
'field' => 'timestamp',
'override' => array('button' => 'Use default'),
'relationship' => 'none',
));
$view->save();
}
//drupal_set_message('<pre>'.print_r($view->display['page_1']->display_options['sorts'],1).'</pre>');
?>
(Left in some commented debugs in case you need them to track down the sort array values you need to push in.)
#32
subscribing
#33
subscribing
#34
I've done some work on this and ran into the fact that even if you get this working Views won't display it because there are places in the Views code that expect all exposed forms to be filters. So I created #458140: Allow any handler to use exposed form to get that fixed.
Once that is in, we can build a sort form similar to the one used by the filter and it will have the option to select a sort and then choose to expose or not expose the form, just as filters do. I have some preliminary code to do that, but am waiting to be sure what is going to happen to the other issue.
#35
Here's the preliminary, broken patch for adding an exposed sort, based on the Views patch mentioned above. This is just to see how the patch would be implemented for the sort handler. Several things need to be worked out yet like how to handle multiple sort fields and all you can do so far is select a sort, it won't actually do anything with that information.
#36
subscribing
#37
Subscribing! This would be a great feature!
#38
Sign me up as a tester for this - especially now that the initial patch is in the 3.x branch.
#39
Subscribing.
#40
Subscribing
#41
Subscribing
#42
subscribing
#43
While working on the port of the project module for D6 and Views 2, I wrote an exposed filter handler that acts as an exposed search box. The code for that handler can be found in project_handler_filter_project_sort_method.inc. KarenS's patch in #35 kind of looks similar, but I didn't look in detail.
Caveat: The last time this code was tested was probably some time ago, maybe around Views 2.2 or so. It's possible that it no longer works with the current version of Views.
#44
Subscribing
#45
subscribing
#46
Subscribing
#47
Subscribing
#48
adding a tag and pumping to 3.x
#49
The Views Display Tabs module sidesteps this missing feature by exposing the displays of a view as AJAX tabs. We developed it to address this particular feature. The original idea was to expose sorting but we figured exposing an entire display was way more generic and useful:
http://drupal.org/project/viewsdisplaytabs
#50
any other news?
#51
need that feature, too ..subscribing
#52
I have created a patch based on #35
It is working for now. But probably need some work yet.
I'm not sure if we have to display an select for each exposed sort. It is a bit confusing. And users can not select the order of application for sorts.
Maybe implementing a new exposed form plugin we can get a list of sorts like this the attached image. See #535868: Exposed forms as plugins
#53
+++ handlers/views_handler_sort.inc 2 Sep 2009 15:53:08 -0000@@ -10,52 +10,264 @@
+ if (!empty($sort) && $sort == 'asc' || $sort == 'desc') {
Oops, wrong operator precedence.
New patch.
#54
Testing this out.
#55
subscribing
#56
Ok, new patch.
Random Sorts shouldn't be Exposed.
Some improvements in usability.
Small bug fix.
People, please stop "subscribing" and test this patch.
For testing:
#Download the patch
wget http://drupal.org/files/issues/views-228510-exposed-sorts.patch
#apply the patch
cd sites/all/modules/views
patch -p0 < views-228510-exposed-sorts.patch
This patch is valid
for 2.x and3.x views version.We need also a solid method to check if an identifier is duplicated into a same views.
Since exposed sorts also use ids in url, a exposed sort for a node nid, and a expose filter for a node nid will have the same node_nid id.
By now , I'm using an "_sort" suffix to avoid collisions.
More information about this issue. See #363516: No validation to ensure exposed filter identifiers are unique
#57
Exposed sorts works for other style plugins that only lists. Changing title.
#58
#56 Hi Dagmar thank you for the patch, iam using views 2
i found this error when i want to add sort of "Node: Last comment time"
Fatal error: Call to undefined method views_handler_sort_date::show_expose_button() in /home/inkuiri/public_html/sites/all/modules/views/handlers/views_handler_sort.inc on line 27
#59
@rizqi: Thanks for try the patch. I make a mistake, this patch is not compatible with views 2 since #458140: Allow any handler to use exposed form was not commited to 2.x branch.
You have to apply both patches to get this working.
However, maybe views 3 is the right way to test this patch, then we can backport this later.
#60
subscribing
#61
@dagmar: I applied this patch to views 2 with minor modifications. It works fine for exposed sort, but sort that is not exposed does not work at all. Also default sort is not applied when exposed filters form is not submitted.
Here is my backported patch for views 2
#62
So, we have to fix that. Changing status.
@vgarvardt: Thanks for your review. I think that we should code this feature for views 3. When is ready, we can backport it into views 2.
#63
Thanx, this helps my for a great part.
#64
I have reviewed this patch again. There is a lot of changes. Please if you build a backport for views 2, use this patch.
Changes from #56:
To test this patch, please, create a new view. hook_update_N() is not implemented yet and previous sorts will not be recognized.
I'm marking this as "needs review" if no problems are detected I will code the update script.
#65
Well, I created a new view, went to add a sort and when I hit "update" I got a JS alert dialog:
An error occurred at http://mydomain/admin/build/views/ajax/add-item/expose_sort_test/default....
I hit OK and am unable to update.
#66
@dafeder are you using views 3?
If yes, please deactivate javascript and copy the complete message error.
#67
Ack, my bad. Got my patches confused. Trying the views 2 version now.
#68
Patch from #61 adds the exposed sort to the form but it has no effect when changed and submitted. I'm a little confused though on whether I needed to apply http://drupal.org/node/458140 also.
I wonder if we should break this into two separate threads, one for Views 2 and one for Views 3?
#69
So, new patch. For easy testing I have created two version. For Views 2 and Views 3.
This patch has some nice improvements from #64.
If you are going to test this patch in views 2, probably you get something like:
Hunk #1 succeeded at 957 (offset 1 line).patching file handlers/views_handler_filter.inc
patching file handlers/views_handler_sort.inc
patching file handlers/views_handler_sort_date.inc
patching file handlers/views_handler_sort_formula.inc
patching file handlers/views_handler_sort_random.inc
patching file help/sort.html
patching file includes/handlers.inc
patching file includes/view.inc
Hunk #1 succeeded at 571 (offset -7 lines).
This happens because the patch is build against 2.x version and stable version of views is 2.6. Anyway the patch apply without problems.
@merlinofchaos: I have a question about views_handler_sort_menu_hierarchy.inc. It can be exposed? Is really useful?
#70
By the way. Patch for 2.x includes #458140: Allow any handler to use exposed form so it isn't necessary apply both patches.
#71
Ok, I just took a quick look at this.
One of the reasons that I never implemented this functionality as is has to do with the typical use-case. If you look around at websites that implement exposed sorting, it is usually a single select box. Often you'll find something that looks like this:
Order by
Name
Date
Color
Etc
Direction
Up
Down
You select one and a direction. Yes it is not as flexible as selecting several (but then, with this as it is you can't re-order them, so selecting several doesn't really do it).
I think this is the most important use-case to solve. So I'm a little hesitant about this version of the patch.
#72
Good point merlin. That is certainly the ideal scenario for me, and what is evolving here is much better than nothing but certainly not the most intuitive thing... for instance, if the list style (and/or others) had options similar to the table style's options, with fields that can be sortable having checkboxes. If one or more is checked, some widget is added to the top of the view allowing us to sort.
The ideal thing would be that, if we have exposed filters, it could be part of the same form, so that it would be submitted with all the changes to filters. A way around this might be to add a row of links similar to the headers of a table. But I'm not sure how intuitive that is on a view that doesn't have columns. Maybe just a second form, laid out in such a way it's obvious that it needs to be submitted separately from any filters, would be a good start though.
Trying to think if this could be accomplished with a contrib module ("sortable list" or something) or if views needs to be patched necessarily.
#73
The style doesn't *have* to be involved in the tablesorting -- mostly it's the fields that do the real work and the style is just a middleman. We could move that out of the style and make it a global option.
#74
To do this, we need to delegate the sort in other class different than handlers. This is because handlers can't know which element is defined to sort all the query.
Also, at this moment, there isn't a solid way to alter the query from some Exposed Form object.
I'm working in #535868: Exposed forms as plugins to allows exposed forms alter the views query.
So, what I did was merge both patches (with modifications) to allows exposed forms to generate the select box with all the exposed sorts and apply only one when is selected.
This patch is for views 3. And introduces 3 new plugins, so probably need a big revision before port it into views 2.
#75
This probably won't be targeted for Views 2 in any case.
#76
Relloled since #535868: Exposed forms as plugins was commited. I'm attaching a screenshot of what this patch does.
#77
Thanks dagmar for this great patch. I executed views-2-exposed-sorts-228510-69.patch "#69", it worked perfectly, but i wanted the style that you attached in the screenshot views-228510-exposed-sorts.patch "#76".
I tried to execute the last patch views-228510-exposed-sorts.patch" "#76" but it seems that it's for views 3. Do you intend to do it for views 2? If you did many people will appreciate it especially me.
Thank you in advance.
#78
Sorry, Views 2 will not receive this functionality.
#79
tested patch @ #76 several days ago and it worked great =)
very excited to see this new feature!