Closed (fixed)
Project:
Views (for Drupal 7)
Version:
6.x-2.5
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
22 Apr 2009 at 22:24 UTC
Updated:
12 Mar 2010 at 22:21 UTC
Maybe I'm doing something wrong...
I have a simple view, block display, that shows a list of nodes tagged with a certain taxonomy term. I want to show the nodes in order of most recent posted on top, except if a node is marked sticky, put that one on top. So, sort criterion #1 is stickiness, descending and #2 is post date, descending.
Result is seemingly random order, even if no nodes are marked sticky. If I remove the stickiness sort criterion, it works properly, ordering the nodes by post date. If I put stickiness back, it breaks it again.
Am I missing something obvious?
Comments
Comment #1
merlinofchaos commentedCan you paste the query that the View generates?
Comment #2
toddwoof commentedHere it is. Note: It looks to me as if the query is generating a sort order of created descending then sticky ascending. This is not what's selected in the Sort Criteria. I have it set to Node: Sticky desc, then Node: Post date desc.
SELECT node.nid AS nid,
node.title AS node_title,
node_data_field_photo.field_photo_fid AS node_data_field_photo_field_photo_fid,
node_data_field_photo.field_photo_list AS node_data_field_photo_field_photo_list,
node_data_field_photo.field_photo_data AS node_data_field_photo_field_photo_data,
node.type AS node_type,
node.vid AS node_vid,
node_revisions.body AS node_revisions_body,
node_revisions.format AS node_revisions_format,
node.created AS node_created,
node.sticky AS node_sticky
FROM drupal_node node
LEFT JOIN drupal_term_node term_node_value_0 ON node.vid = term_node_value_0.vid AND term_node_value_0.tid = 12
LEFT JOIN drupal_content_field_photo node_data_field_photo ON node.vid = node_data_field_photo.vid
LEFT JOIN drupal_node_revisions node_revisions ON node.vid = node_revisions.vid
WHERE term_node_value_0.tid = 12
ORDER BY node_created DESC, node_sticky ASC
Comment #3
dawehnerIt seas that node_sticky is added after node_created. So its sorted by node_created DESC.
Comment #4
toddwoof commentedRight -- that's the problem. In the view I selected sort order as node:Sticky and then node: Post date -- so the view should render an order by post date, but with sticky items on top. Instead it evidently renders an order of created date, then sticky.
Note: I just gave up on "sticky" as a sort-order option, at that point, so I'm not sure if this is still a problem in the current version.
Comment #5
merlinofchaos commentedAre you using a table with tablesorting going on?
Comment #6
dawehnerTherefore it would perfect if you would export your view :)
Comment #7
toddwoof commentedI think it's a problem inherent in the sort order logic, and how I thought "sticky" was supposed to work.
What I want is to be able to mark one or more nodes as sticky, and have them float to the top -- but I want the newest nodes on top, within each set. In other words:
Sticky nodes first, with the newest on top, then
Non-sticky nodes, with the newest on top.
This, I guess, is impossible, because the "sticky node" function is evidently really just a tag. It doesn't actually float the nodes to the top. It only does that if you select sticky/desc. If you select sticky/ascending, it puts them at the bottom of the list (not, as I want, on the top of the list, but in descending order).
Example:
Suppose I have four nodes, posted in order, A, B, C, D -- so D is the newest, and A is the oldest.
I'll make B and C sticky, so the desired order is C, B, D, A
If I do this:
1. sticky/desc
2. posted on date/desc
It will render D, A, C, B -- because first it puts all the sticky nodes on the bottom, then filters unsticky for latest on top, and then sticky for latest on top.
If I do this:
1. sticky/asc
2. posted on date/desc
It will render B, C, D, A -- because first it puts all the sticky nodes on top, then filters them for oldest on top, then the others for newest on top.
1. sticky/desc
2. posted on date/asc
Will render B, C, A, D
1. sticky/asc
2. posted on date/asc
Will render A, D, B, C
And, none of these work, because putting posted-on date first results in an absolute asc or desc order by post date. The "sticky" filter won't do anything, because in fact each node has a unique post date, which is the primary filter.
1. posted on date/desc
2. sticky/desc
Will render: D, C, B, A
1. posted on date/asc
2. sticky/desc
Will render: A, B, C, D
1. posted on date/desc
2. sticky/asc
Will render: D, C, B, A
1. posted on date/asc
2. sticky/asc
Will render: A, B, C, D
So: Any suggestions on how to get the sort order I'm looking for? I have this sense that there's something blindingly obvious that I'm missing...
Comment #8
Doomd commentedI would like the same functionality...
Comment #9
merlinofchaos commentedOk, folks, I'm really confused.
What we're talking about here is really basic functionality. My best guess is that this is configuration error. Views does not normally reverse the order of sort criteria, but without an export of the view that's giving you trouble, I have no way of really telling you what's wrong with it.
One thing that may be of value. Sticky is a boolean, and booleans are 1 == yes and 0 == no, so you want to order them descending to get sticky on top.
You are wrong, it orders them C, B, D, A. Which is what you want. I tested this, even though I didn't need to.
Sticky/descending will put all sticky nodes on top, ordered by newest first, and then all not sticky nodes beneath them, newest first.
Comment #10
toddwoof commentedGaa! I gave up on the view in question in September when I posted that and went another route. I did actually test the permutation in question at that time, and it did fail as noted -- but just now I did the same test on a bare-bones site and it worked properly, as you note in #9.
So, evidently there is some other module/factor affecting the view output in the site that I was working on. I'll see if I can reconstruct it.
Comment #11
merlinofchaos commentedMy immediate guess is the tablesorting -- sometimes when using a table style, the sorting looks funny because it's not immediately obvious that tablesorting is overriding the prepared sorting.
Comment #12
esmerel commented