Posted by Coyote on February 29, 2008 at 7:18pm
| Project: | Views |
| Version: | 7.x-3.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
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?
Comments
#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!
#80
received the below errors when patching:
patching file views.module
Hunk #1 FAILED at 984.
Hunk #2 FAILED at 1063.
2 out of 2 hunks FAILED -- saving rejects to file views.module.rej
patching file handlers/views_handler_sort.inc
can't find file to patch at input line 280
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: plugins/views_plugin_exposed_form.inc
|===================================================================
|RCS file: /cvs/drupal-contrib/contributions/modules/views/plugins/Attic/views_plugin_exposed_form.inc,v
|retrieving revision 1.1.2.1
|diff -u -p -r1.1.2.1 views_plugin_exposed_form.inc
|--- plugins/views_plugin_exposed_form.inc 11 Nov 2009 01:42:53 -0000 1.1.2.1
|+++ plugins/views_plugin_exposed_form.inc 11 Nov 2009 03:19:16 -0000
--------------------------
#81
I don't think you have the latest views 3 dev, which is why the patch is not applying.
#82
So, here is a new patch. I am very pleased with this patch because it comes with:
This patch is dependent of this two patches marked as RTBC:
#645150: Call to undefined method views_plugin_display_page::get_exposed_form_plugin()
#645146: Filters cannot be exposed anymore after "Retool exports to drill down properly"
And again, this patch is for views 3. Please don't apply to views 2 because you will get something like #80.
In my opinion this patch is 95% ready, so please test it and give me your comments.
#83
ahh - I got the folders mixed up when patching so I thought it may have been the several week gap that resulted in changes.
using the correct version: views 6.x-3.x-dev
I first applied the dependent two patches - both successful
1st #645146: Filters cannot be exposed anymore after "Retool exports to drill down properly"
patching file plugins/views_plugin_display.inc
Hunk #1 succeeded at 1963 (offset 7 lines).
2nd #645150: Call to undefined method views_plugin_display_page::get_exposed_form_plugin()
patching file handlers/views_handler_filter.inc
patching file includes/admin.inc
But then with views_exposed_sorts-228510.patch i get the following result. Is this expected?
patching file handlers/views_handler_sort.inc
patch: **** malformed patch at line 171: Index: plugins/views_plugin_exposed_form.inc
#84
Yes, sorry I deleted parts of the original patch because it was including the other patches. And probably I deleted more than I should.
Here is a reroll.
#85
Hello dagmar,
Thanks for the reroll. Patching was successful, however on re-activately the Views module I got this fatal error:
Fatal error: Call to undefined method view::render_exposed_form() in /home/example/public_html/drupal/sites/all/modules/views/plugins/views_plugin_display.inc on line 2083
Found your patch that looked like it may be for similar issue http://drupal.org/node/639094#comment-2291180
But patching resulted in the below result:
(Stripping trailing CRs from patch.)
patching file plugins/views_plugin_display.inc
patch unexpectedly ends in middle of line
Hunk #1 succeeded at 2079 with fuzz 2 (offset 6 lines).
Hope this information helps. Thanks!
#86
Here we go again...
This patch is a rerroll and includes some small changes that take advantages of the exposed_form_alter() function introduced into exposed forms plugins.
To test this patch you only need the last version of views 3, no extra patches are needed.
#87
Some thoughts:
Would it be possible to Display the sort order before the other exposed filters?
+++ views.module 3 Dec 2009 21:28:03 -0000@@ -994,7 +994,7 @@ function views_exposed_form(&$form_state
- '#value' => t($form_state['submit_button']),
+ '#value' => t('Submit'),
Why do we force it to be submit?
I did exposed a lot of sorts and they worked like a charm. I guess the documentation should be updated. Thats a killer feature :)
#88
Update status, too.
#89
Rerolled because #99370: Add a 'reset' button to exposed filters was committed.
This was the old mechanism of views. Now this feature is implement using exposed_form_alter() function.
#90
This patch check if 'reset' button is active and move it to a better position in the exposed form.
#91
Works fine again.
#92
Here is updated patch from #69 that applies to Views 2.8
#93
@vgarvardt: Thanks for the patch. However, because this issue is marked as RTBC I have to make a note about this.
Exposed sorts were finally implemented using a new kind of plugin that will not be available in view 2. So when you are installing patch #92 your are in fact applying (at least) to views 2 all this patches:
#458140: Allow any handler to use exposed form
#535868: Exposed forms as plugins
#633482: pre_execute is never called on exposed forms plugins
#639094: Exposed Forms do not work?
#645150: Call to undefined method views_plugin_display_page::get_exposed_form_plugin()
#99370: Add a 'reset' button to exposed filters
As you can see, there is a high risk that this not work as you expected into views 2. So, the status of "Reviewed & tested by the community" is for patch #90. And this backport to views 2 is complete untested.
#94
#90 worked great! Patched with no problems, easily exposed some sorts and I like how we are able to easily change the text for ascending/descending and labels.
I wasn't able to locate the string to translate the Asc/Desc to other languages though..will continue to try. Thanks!
#95
tagging
#96
subscribe
#97
I testet it for fun again, it is really cool.
#98
yes works here too +1
#99
#90 committed to the 3.x-dev branch. needs to be ported to 7.x
I created to follow-up issues to this:
#666870: Exposed sorts do not properly default and #666874: Exposed sort order by field needs some work
#100
Subscribing
#101
Another followup: #670388: don't show exposed sort selector when only one sort is exposed.
And a meta-issue: there's an issue component 'exposed filters', so one for exposed sorts might be needed too.
#102
subscribe
#103
-removed-
#104
cerup -- your question does not seem relevant to this issue. Please post your question as a separate support request.
#105
Is this going to go into 2.9 or should we upgrade to 3.x if we want this?
#106
I guess, this will not go into 2.9, because it needs also exposed form plugins and other stuff.
If you really want it you can try out 3.x or use some workarounds available out there(custom code)
#107
I have feature frozen the 2.x line, so it will not be going into any Views 2 version.
#108
remove tag.
#109
#110
The same bug: http://drupal.org/node/698270#comment-2537800
I'm not sure how to solve it.
#111
commited.
thx!
#112
Automatically closed -- issue fixed for 2 weeks with no activity.
#113
I used this method mimic sorting for views 2:
1. Create A View for search.
2. Add different page displays for each sort criteria.
3. Add below code to the header of view, selecting PHP input.
<?php
$newurl = str_replace($_GET['q'], '', $_SERVER['REQUEST_URI']);
?>
Sort By: <a href="/find-by-distance<?php print $newurl; ?>">Distance</a> | <a href="/find-by-rating<?php print $newurl; ?>">Ratings</a> | <a href="/find-by-popularity<?php print $newurl; ?>">Popularity</a>
Ofcourse, links need to be changed.
Also it doesn't work where request uri returns full URL, like domain.com/someurl/, and needs clean URLs. Otherwise you may need to explode it to get $newurl
#114
subscribe
#115
subscribing
#116
subscribe
#117
looking for more information on this feature... subscribing. Is this workaround a good way of handling it? http://stackoverflow.com/questions/2471361/drupal-sorting-a-view-program...
#118
sub
#119
I think this may be more usefull:
<?phpfunction Hook_views_query_alter(&$view, &$query) {
// fyi, anonymous sessions need a record in the user table of 0 to work at all....
if ($_SESSION['pref']['state_color'] == 'red') {
// we'll have to do the less popular red query
// which's key is [1] (weighted second in the views sort order interface)
unset($query->orderby[0]);
}
else {
// otherwise, don't do the hill billy logic at all....
unset($query->orderby[1]);
}
}
?>
#120
Is it possible to make exposed sort optional?
I have added one exposed sort to my view but would like to make it optional.
At the moment it is the only sort that is shown in the dropdown select list so therefore not optional.
Thanks!
#121
Here's a patch reroll of the version in comment 92 above for views 2.11, just in case anyone still needs it for D6
#122
Subscribing.
#123
subscribing..
#124
@stella: thanks but patch contains a patch for itself and fails against 2.11 for views.module
#125
seems that when in a table with ajax on, they don't work..ajax on and html list works fine
#126
Great work on the patch, but I'm not a fan of the front-end ui.
I don't like how there are multiple select widgets, each with asc/desc options. I think there should be one select (with each sort as an option) and a toggle for asc/desc. See attached.
#127
Hi, does the patch #121 works for 2.11 even there is this warning message for views.module??
#128
Please don't change version.
#129
Apparently #107 was not crystal clear.
Please do not hijack issue versions.
Please read the entire issue before you ask questions that are already answered in the issue.
#130
#131
I've found workaround, which works quite good for me.
switch ($_GET['sort']) {case 'created':
unset($handler->view->sort['totalcount']);
break;
case 'totalcount':
unset($handler->view->sort['created']);
break;
default: break;
}
return TRUE;
Notice1: Insert "dpm($handler)" in PHP validator to find name of sorting objects, which should be deleted.
Notice2: Sorting criteria in page display should be overwritten. It builds sorting objects, which we can delete.
Now, we can put links "my_view?sort=created" and "/my_view?sort=totalcount" into MY_VIEW header.
Please let me know if this solution has drawbacks .
#132
cute
#133
sub
#134
I had a similar requirment, the way i did it was to turn the sortable items (authors ect) into taxonomy and then use arguments.
#135
Hello,
Just wondering if this is being worked on for Views for Drupal 7?
If not it would be willing to give it a go but did not want to try at it knowing someone on the team is already at it?
Thanks
#136
yurtboy please see #111 this was committed in D7 almost 20 months ago.
#137
thanks pcambra
now for the infamous question is there one for d6 ( -:
#138
can anybody help?
How to display in form exposed sort filters AFTER exposed filters?
Thanks.
#139
definitly the wrong thread to ask that....
but take a look at views templates to do that...
#140
yes, i understand, that in views...tpl I have array of widgets.
But how to revers sorting and display them in that way.
#141
The 6.x 228510.patch (#92, #121) introduces a bug that breaks random sort by appending "ORDER BY _random UNSORTED" to the generated query.
Encountered the problem in Drupal Commons 2.3, which used to apply this patch by default. Latest Drupal Commons 2.x no longer applies it though, so problem went away for me:
http://drupal.org/node/1342452
http://drupal.org/node/1302984
Yet info might still be of use to others.