Allow custom sort order for nodes in taxonomies

personally, i would like to see options like this for content type. but hopefully both could be available.

this patch seems undrupalish at the moment. i suggest alternate sortings be dispayed by via contrib modules. those contrib modules would likely reuse everything from taxonomy.module except for a custom taxonoy_select_nodes()

one way to implement different sort orders, i suggest you write a new module which will handle new urls. if you call your module 'megasort' then you can make up your own urls like

megasort/term/3

then, you control sort order with settings in admin pages. or you can make more complex urls like

megasort/created/asc/term/3

the second 2 arguments above define a sort order. the only issue with this is if you want these to *replace* the regular term urls that are shown in nodes. in order for that to happen, you can probably do some str_replace() inside your theme.

the key function to write is megasort_select_nodes(). ten you will call taxonomy_render_nodes() just like taxonomy.module does.

Using a custom 'megasort' module can be made to work, but this will require patching part of the node display. Currently, when you are viewing a node, category links are automatically generated which point to the taxonomy module: $taxonomy = module_invoke('taxonomy', 'form_all') in node.module. (There may be other implicit dependancies upon the taxonomy module like this, e.g. the theme hacking mentioned above, but this is the main one that springs to mind at the moment). This would have to be changed to allow the admin user to specify which module should handle the classification. This approach could rather messy, and as a number of modules now rely on taxonomy to sort and display things (weblink, image), I think the simplest solution is to add this functionality to the taxonomy module.

I realise that the 'Drupalish' approach is to minimise the amout of switchable code (to avoid code bloat) and use custom modules for tweaking the display, but I think the things we are considering here are too close to the Drupal core for that approach to work. This is all IMHO of course, as I'm not as familiar with the Drupal core as I would like to be, but I cannot think of an neat way of using the module system to add this type of functionality to such a fundamental part of Drupal as the taxonomy.

Cheers,
Andy J.

Scratch that comment about the image galleries - the version I just downloaded has reinstated it's galleries. Perhaps the same will happen to the weblinks module.

I think my own confusion here is perhaps rather common, and it might help to explain it here. The fact that one can browse the site content via the taxonomy module means that when one installs a module that uses the categories to arrange it's contents, you can end up with two different ways to browse the content. For example, images can be examined via the taxonomy module or via the image module's galleries. This would not be much of a problem if they were completely separate interfaces, but the way nodes are presented means that the user will probably end up switching from the gallery view to the taxonomy view (via the post metadata tags/breadcrumbs in the node view), when they were expecting to stay in the gallery view.

I end up thinking that I must be doing something wrong, but I cannot find out what. How am I supposed to view my galleries? Is the image module doing something wrong? Should it be overriding/ignoring the node-view so that the links on it's pages always point to the image module? In that case, *no* module should *ever* use the plain node view for categorised data. But the, if the taxonomy view is not meant to allow you to control how the terms are viewed, why does the taxonomy module support viewing the nodes at all? Or should I stick to the taxonomy view and hack it to make that work?

I couldn't find anything about this in the documentation to clear this issue up. I will happily add a page to the handbook about it if someone explains the idea to me.

Cheers,
Andy J.

A related patch was committed. That patch only covered the API taxonomy_select_nodes() and added a $order parameter.

It is up to a contributed to take advantage of this with an advanced URL scheme. Later, it can be moved into core if it is good enough.

Has anyone updated this patch for 4.6.2? It appears that some of the variable names have changed and I don't have the know how to make the changes.

Or perhaps someone has used this patch (http://drupal.org/node/20963) to give the same functionality described in this thread?

Well, there hadn't had so much changes in the names, so it should not be so difficult to apply it.
You can also use mine, but basically it's the same one. It just depend then where would you use it to define the way to call taxonomy_select_nodes()

an alternative is to use weight.module in contrib. it uses the sticky column to store weights, and drupal just naturally uses it.

Is that patched module (file) available anywhere for download? I'm using 4.6.2 and I think this patch is for the CVS version, maybe that's been my problem with trying to patch it (http://drupal.org/node/14231#comment-50081). In any case, I'd just plain love to get one node (Events) to sort ASC while the other nodes sort DESC. However, at this point, I'd be happy to just make the whole site sort ASC and deal with it later. Thanks. -- Bradley

Remember that this kind of patch is only a way to allow modules using taxonomy to get a way to order nodes. In your case you have to ask to event maintainers a way to allow events to be ordered the way you want.

A similar version of this patch has been commited to CVS, the Drupal 4.7 will be available current september, so I think it worth the wait.

The problem with the weight.module is that doesn't sort alphabetically.

Somebody pointed this thread to me because I was asking some feedback on a small sorting.module I wrote for one of my sites. You can find it here: http://drupal.org/node/37899 and give it a try. It is working with 4.6.3, right now. Please, give some feedback if you try it!

I realize this patch does almost the same mine does :-) I added some more variables to have also promoted nodes ordered by other fields. And other options can be added, like sorting 'product' nodes and flexinode nodes.

I think Views module now gives you these options out of the box.

I'd sure like to see this too. As it is now, I'll be copy-and-pasting taxonomy_term_page() just so I can pass an ORDER string to taxonomy_select_nodes(). If the hook seems too big of a change, how about adding an optional $order to the end of the footprint the way it is in taxonomy_select_nodes()?

Views seems like a heavy price to pay for this little added bit of useful functionality that people are expecting to find in core.

I've been looking at the views builder and it seems to only work on the "standard" node fields.
I would also like to see this work for events and sort nodes by the start date/end date (per the post that started this thread).
B-)

Suscribing, very interested in this option as I need to sort a list of nodes from a taxonomy term (without using views).

@faunapolis - you may want to take a look at Nodeorder if you haven't already. It works fine for ordering nodes in single-level vocabularies. Please post issues with that project, if you try it, to the Nodeorder issue queue (and check out the current issues if you're having trouble).

Nodequeue also brings this feature, and is an extremely useful tool for lots of other reasons.

...which makes this a 'won't fix' in core

Hi,

I think that, for taxonomy, it seems kind of weird to me that all of this time, from the beginning of this issue 2 years ago, till now, that patches have not been worked into core to at least allow taxonomy nodes to appear in alternate orders besides stickiness or date of creation in taxonomy. In particular, I know a lot of people would like to see the option for alphabetical sort order be an *automatic* option. I think Node Order and Nodeque are ok options, but require a lot of manual labor on the part of the user, that a few simple lines of code could alleviate, in creating an option for sort order in taxonomy default listings

I am not active in the development of Drupal, so I lack a literacy to understand over time what happened with the original patch submitted back in 2004 at the beginning of this issue.

Maybe I am missing something here...?

you argument for changing status reads to me like "this is useful and shouldn't be hard". thats not compelling for all the reasons listed here.

maybe I just need to look more closely at Nodeque....

My solution is theme based and works fine for Drupal 6.x:
http://drupal.org/node/10820#comment-1452074