Sort on Taxonomy: Terms for [your vocabulary]

I'm having the same issue. I thought CCK Taxonomy would solve it, but no. Hmm, maybe I should add this there, too.

Subscribing - I'm trying to work out how to do this too anyone figured it out?

Apparently, it's "not easily sortable" (yet doable in the URL--go figure). See this thread for more info. Be careful you don't offend the "almighty godsend" wizard or you may have your account banned...<eyeroll>

Sorting on multiple terms isn't really doable. Views only supports sorting via SQL statements, and the data you're looking at is a constructed string.

Eep: You're wrong. You can't sort on this field via URL. Maybe you got lucky when you tried it and it appeared sorted that way, but I assure you in the general case, it does not, and you're doing a disservice to everyone by repeatedly stating it does.

Also, if you come into my issue queue and throw insults around, you will be banned again.

Bumping this to 6.x, as 5.x will not get any new major features. However, I don't know whether a different concept is planned or already implemented in Views 2. So there is a chance that we might want to close this issue instead.

Can we revisit for 3.x?

Before rejecting, is core missing features or logic that would make this possible? If so, please expand on this feature request: #495908: Support node sort by taxonomy vocabulary

Marked as duplicate: #478386: Sorting nodes by vocabulary

It's not really possible. I've added a taxonomy term relationship which should let this work *if* you have only one term in a vocabulary, but it'll create duplicates if you have multiple terms. THat's the best I can do.

Is an improvement to core needed to make this work?

Hello, in my case I have a node that is associated to two different taxonomy listings. When I pick "sort on taxonomy: term" it always picks the first term set, never the second [that I actually want it to sort on]. Is there anyway to distinguish WHICH taxonomy dictionary is being used? Something in the settings of taxonomy where you could pick which taxonomy group you wanted to sort on would solve it, and I can't imagine this is outside of possibility...?

Thanks!

Hello friends, still no response to this, would love to know if there is a solution/work around to my sorting on second taxonomy term solution...
thanks!!!

Sebastian.

I closed this in #8. I see no reason that it should have been reopened.

Would you at least add a comment to #495908: Support node sort by taxonomy vocabulary to help guide the core fixes necessary to make this work?

Why is this closed? Surely if you can specify which vocabulary to filter on, you should also be able to select which taxonomy vocabulary to sort on?

Ok. By re-opening again this you effectively call me a liar. Please take it and shove it. I said it wasn't really possible. It's not really possible. Just wishing it to be possible doesn't make it so, and it's just a waste of everyone's time. If you think it's possible, you can write a patch and submit it.

fwiw, i think the use case described in the original issue is different from that described in #11. please see #557454: filtering by a term in one vocab while sorting by another vocab for SQL that apparently solves the issue in #11 (and hopefully soon views code to construct that SQL). a similar approach may or may not solve what appears to be a parent-child term hierarchy issue in the original post.

thanks to all for your investment!

Attached is a patch for Views 2.6 that adds an option to restrict a Views taxonomy term sort by vocabulary.

It should be noted that every taxonomy term sort with vocabulary restriction adds two further joins to the SQL, so on large datasets this approach could be prohibitively costly.

One known limitation is that the Views UI does not detect when the specified vocabulary is deleted. Any advice on how to achieve this within the Views API is welcome!

this should apply to 2.x development, methinks... simple enough change, no? others, please test!

also, ran into an annoying problem with views 2.6: [#428742: Multiple taxonomy arguments => "Not unique table/alias"]. so rewound to views 2.3 and repatched there: patch still works, with only slight tweaking to fit in right places. fyi...

I tried out the patch on #18 and it actually seemed to be working, I just did one quick test only but it really didn't suited my needs. Moreover, I think that what the patch does, can actually be worked out with some ideas I found on http://drupal.org/node/167324 (not exactly as there, but with the same approach).

Even more, by looking at http://drupal.org/node/272424, and then following http://drewish.com/node/127 I actually learned about Views relationships, which, with the use of content_taxonomy, can eventually be used to go with much of the functionality requested in this issue. At least it seems like that.

My needs were to sort nodes based on a specific term name for a specific vocabulary. So:

1. enable content_taxonomy,
2. I add the field mapped to the vocabulary I want to sort the nodes with
3. Add a relationship between that field and the term name
4. Sort by term name and used the relationship which was now available.

Sorting and SQL query seems to be working just fine for now.

I did not tested the patch yet, but it would be nice, if the "all terms" field would be also possible to sort.

Here's a workaround for Drupal 6 (it may not fix the issue for all cases) and an example.

We have a catalogue with taxonomies "Brand" and "Category". The view is restricted by category, and should list nodes ordered by brand. Assume that Brand = ACME, Bodgeware, Chomondley and Category = Apples, Bananas, Cakes.

By default when ordering the view results by "Taxonomy: Term Name", the resulting node listing will be sorted alphabetically by whichever term name is found first; a Chomondley Banana may appear before an ACME Cake.

The workaround for us was to add a filter to the view, which filters nodes to ensure that each has a term from the specified vocabulary. Adding this has the effect of making the results from term_data only be results from the relevant vocabulary. That means that when we hit ORDER BY term_data_name, we're only looking at the entries we want to sort by.

Filter should be something like Taxonomy: Vocabulary = (name of vocab to sort by)

The resulting SQL changes from

SELECT node.nid AS nid,
   node.sticky AS node_sticky,
   term_data.name AS term_data_name,
   node.title AS node_title
 FROM node node 
 LEFT JOIN term_node term_node ON node.vid = term_node.vid
 LEFT JOIN term_data term_data ON term_node.tid = term_data.tid
 WHERE (node.type in ('product')) AND (node.status <> 0) AND (node.vid IN (
  SELECT tn.vid FROM term_node tn
    LEFT JOIN term_hierarchy th ON th.tid = tn.tid
    LEFT JOIN term_hierarchy th1 ON th.parent = th1.tid
  WHERE tn.tid = 130
    OR th1.tid = 130
))
   ORDER BY node_sticky DESC, term_data_name ASC, node_title ASC ;

to

SELECT node.nid AS nid,
   node.sticky AS node_sticky,
   term_data.name AS term_data_name,
   node.title AS node_title
 FROM node node 
 LEFT JOIN term_node term_node ON node.vid = term_node.vid
 LEFT JOIN term_data term_data ON term_node.tid = term_data.tid
 WHERE (node.type in ('product')) AND (node.status <> 0) AND (term_data.vid in ('6')) AND (node.vid IN (
  SELECT tn.vid FROM term_node tn
    LEFT JOIN term_hierarchy th ON th.tid = tn.tid
    LEFT JOIN term_hierarchy th1 ON th.parent = th1.tid
  WHERE tn.tid = 130
    OR th1.tid = 130
  ))
   ORDER BY node_sticky DESC, term_data_name ASC, node_title ASC

The changed SQL is in the WHERE clause, where it adds AND (term_data.vid in ('6')).

I guess it only works for a limited number of cases, and it MAY be what Merlin alluded to in #8 too.

Adding this comment in the hope that it helps someone else avoid getting stuck on this problem too long - I spent a while investigating posted workarounds (eg content_taxonomy and relationships) before discovering there was no need for such things.

If this behaviour is documented elsewhere, I missed it.

I tried out the patch in #18, it seemed to work fine although I have got a lot of duplicate results. I get this whenever I try and sort results by anything to do with taxonomy, I'm not really sure why.

There's a "reduce duplicate results" option in the main views ui which sorts it.

If you install cck module with computed field submodule you'll be able to sort your views however you want. You "only" need to define a weight function to create numeric values for your term(s). Here is the explanation with more details:

http://drupal.org/node/290563#comment-2271238

Not very straightforward but I think it's better than patching/modifying views module since views won't ever have the versatility of custom defined php functions. Not my case, but someone could need a weird sorting method...

Regards.

The patch in #18 worked perfectly for me! Thanks a bunch. I had no problems with duplicates or anything else weird.

Please commit this, it is extremely useful.

Question: Why is this patch better than just using the taxonomy relationship? The relationship seems to be both more powerful and do everything this does?

Does it support sorting if you use multiple terms in a vocabulary? (See #8 above.)

@Mr. Chaos #28: Perhaps relationships are more powerful, but they are certainly not intuitive. I haven't tried using relationships for what I was after when seeking out this issue, but the answer posed here seemed instantly to be what I was looking for so I went for it.

I suspect there are other users that would approach this similarly.

If I had to name a reason that this is a superior approach I would say "usability". Having the filtration directly in the sort takes fewer clicks and is more intuitive. However, I am sure there are cases when relationships would be a more appropriate solution. Nonetheless, that patch gets my vote.

It's only more usable because people don't know about the relationship. Having a workaround for this may seem like a short term usability plus, but it's a long term usability minus, since it fails to train people on an important feature. I think I'm going to stick with the existing method.

I believe you're off the mark. It is an easier means of accomplishing the task than using the relationship. In any engineering problem, there are multiple ways of solving an issue. Why force users to learn a more difficult way when there is an easier one? That is the very definition of 'bad usability'.

Relationships allow you to do very powerful things with views, while this patch allows you to do one simple thing. While I agree that relationships is an important feature that users should learn in order to do powerful things with views, so is SQL an important tool in the developers world that one should learn in order to do powerful things with queries, and yet you've given us the views module which allows those without that knowledge to leverage the potential of database control.

Many users will go their whole lives without ever learning or understanding relationships in views, it can be rather tricky to wrap one's head around. So why not let them have a means of utilizing some features without a complete knowledge of a more fundamental way to accomplish the task in the same way that views allows them to use database queries.

I believe that a short term usability plus is what you want when you are after a short term goal. There is no harm in committing the patch, only benefit to those who find relationships to be beyond their grasp.

I urge you to reconsider.

Apologies for reverting the status, but I would like my last comment to be read.

If you think that it works, then please create a new contributed module that mainly just implements this helper. But be prepared to deal with the support requests, and in case you manage to solve it in a way that no one complains, feel free to get back to this issue queue.

There is no doubt that it works, the only problem is the maintainers of this module won't implement it because they think they know what's best for everyone. Shame.

justindodge: When throwing around rude comments like that, please remember that the maintainers of this module have spent thousands of hours of time so you can have a free product. Yes, that does give me the right to decide what is best for my module. I'm sorry you can't have it your way, but the absolute hardest thing a maintainer has to do is say 'no' to someone who wants something.

And sun is right. You can add your sort handler in a contrib module and maintain it. If you're not willing to maintain this work, what makes you think I should? I have no interest in adding even more to the already massive workload of maintaining this module for a feature I think will only ultimately cause confusion. Please put your actions where your words are. Otherwise you're just someone with a sense of entitlement much larger than is warranted.

There is no harm in committing the patch

I already stated precisely what the harm is, and I still believe it is harmful. Because you choose not to care, perhaps you're the one who thinks you know what's best for everyone. And again, since you do, contrib is a very open place. Please go create a module.

This issue is finished.

merlin: It was not a rude comment, merely a truthful one. There is no doubt that the patch is functional, but you will not commit it because you believe you know a better (not easier) way to do things. You feel that what we should know is more important than what we need to know in order to solve this issue. That is to say, you believe you know whats best for your users. If you can find an inaccuracy here, I will retract the statement. Until then I maintain it is a shame because I (like nearly every other human) prefer easy solutions to problems.

I have enough modules that I maintain (poorly, because I am restricted on time) and I do not have the resources to take on the development of a new one. I have also put in many hours of time so that you and many others may have a free product, however this fact seems quite irrelevant to this issue.

The only reason I would expect you to maintain this work is because the patch has been already laid at your feet and the desire has been expressed from the users for it. Your hard work and status as maintainer of the module certainly give you the right to refuse to do so, but I will maintain the right to present arguments for why this is a shame. I feel no sense of entitlement over your work, simply obligation to express what regular users of this module are feeling when using it. Creating a useful and enjoyable product is the goal of your development I would suspect, so that is why I express these things.

In response to your last paragraph, I clearly care about the issue or I would not be here discussing it. I never claimed to know whats best for everyone, but I speak from experience when I say I know what is easiest, and so have other users in this thread. Being a highly advanced developer such as yourself, I could see how it may be easy to lose sight of this when you understand the workings of it so well.

On the issue of harm coming from the patch, you have not chosen to offer a rebuttal to any of my arguments for why this is not the case, rather spend time at taking offense when the users of your wonderful free product express disappointment that you will not implement something they find to be useful.

On the issue of harm coming from the patch, you have not chosen to offer a rebuttal to any of my arguments for why this is not the case

Except this is completely untrue. I said:

It's only more usable because people don't know about the relationship. Having a workaround for this may seem like a short term usability plus, but it's a long term usability minus, since it fails to train people on an important feature.

This is concise, accurate, and to the point. To elaborate further, it creates a second way to do something which will make things worse when you want to do more than sort. Now you take the view that is sorted by vocabulary and want to use another feature that should be done with the relationship. But it won't work, and it can't work, so the user will be lost and frustrated. for example, you won't be able to display the term you're sorting on, or anything about the term. It won't match up with filters, either. I feel pretty confident that people will not understand why this is so.

You keep talking about how this is easier. Yes, this is easier for exactly one thing. So what? That's not a valid argument. There's no end of features I could put in that would make uncommon feature requests like this easier, but would only add confusion to other features.

I'm happy to try the relationship route if that's what's recommended. So far, I haven't quite got it to work. I tried what was proposed in #20, and it does help in that I get sortable terms. However, it

(1) requires an additional module (content_taxonomy),
(2) sorts the term alphabetically, not by weight,
(3) doesn't use the taxonomy term that the node was associated with, but rather a new version of it that has to be added redundantly into a CCK field.

After reading #8 I tried getting a relationship to the taxonomy term already assigned, but there was no option for that, only for parent and related terms. Am I missing something?

@#39 exactly the same goes for me

Given that this discussion has been a fairly long one now, I've opened a separate docs issue as a support request in the hope that we can use that thread to discuss / document the process of getting it to work (without patches, hopefully without extra modules too).

That might be clearer for future generations of Drupal devs to deal with than getting down to comment #43 before finding The Right Fix (and being tempted by lots of naughty patches along the way).

Summarising some of the clues to be found above:

* #158859: Table View Sortable=yes is not sorting the table
* Forum thread on Views Sort Criteria & taxo relations
* #495908: Support node sort by taxonomy vocabulary
* Screencast on Views Relationships
* #272424: Sorting doesn't work in view
* Workaround with computed fields
* hanoii's comment above indicates some success
* grobot's comment above with one solution which may not suit everyone's use case

The new issue is #717412: Document process for sorting a node view by taxonomy term (various edge cases).

FWIW, #22 worked great for me.

I had filtered links (created with Weblinks) by Type, Published, Taxonomy Term ID with depth, and again Taxonomy (to eliminate dead links, of which I keep a list). I found I could group by Taxonomy Terms All (set to a particular vocabulary), but I could not sort by taxonomy. Inserting the Taxonomy Vocabulary filter before the Taxonomy Term ID filter made my Taxonomy Term sort work. Thanks for a quick solution!

Until now I had been re-applying my patch from #18 to a production site when its Views module was updated. Coming back to this thread and reviewing the subsequent commentary, in my use cases the simple filter approach from #22 achieves exactly the same organisation of nodes. While in theory it may not work in all scenarios, it suffices to replace my patch as the preferred solution for the site in question.

Just wanted to confirm that the approach in #22 worked perfect for me too. Great to be saved the process of patching.

Hello all,
I have added "Importance" field among basic fields for the particular vocabulary (among 5 of which I have) on which I want to sort nodes on. Then for all terms I populated that field with values which are almost exact as term weights.
In Views I've set up the Relationship to that taxonomy reference field, and I was able to use "Importance" value to display and, more importantly, to sort.
No Computed Fields, no patching...
Is this the approach that makes sense?
(I'm using D7)

What about adding an underscore to the beginning of all the terms in the vocabulary you want to sort by? That ensures they're always the first terms to the picnic, making them the ones that Sort by: Taxonomy: Term uses in Views...

I'd follow that with a tried-and-true Regex that checks and replaces all those underscores before the page prints out (client-side). A super-quick flash of underscores on the page would be the only side-affect.

Oh, and I don' think this works if you want different sort options - the use case would be limited to needing to sort a view always by one of the several vocabularies.

UPDATE - My idea here doesn't quite work - it only appeared to at first. Never mind!

#22 also worked for me. Try it...

#22 Thank you very very much! It realy works!

#22 : thanks - so easy when you know...