Node weighting patch

I read this patch and like both its implementation and its functionality.

I find this most useful for taxonomy rendered pages, where I want to provide a brief explanation at the top for the current taxonomy term. It may also be nice to encapsulate these weighted nodes with unique CSS IDs, much like we do with blocks.

REVIEW
- the functionality offerred here is terrific. this patch shows a lot of attention to detail. it is ready for commit IMO. but here are a few small improvement opportunities ...

- the 'Weight' select in the admin page looks odd because of its bold title. perhaps some css could fix override that.
- the up/down arrows on the admin/node page are wrapping to a new line (Firefox browser). some css could avoid that.

I'm not sure 'node weights' are the way to go: I can think of many other ways to sort posts so maybe this is not the task of the node module, but of a specialized module (or theme) that can be replaced. Also, if it turns out node weights are the way to go, we should probably remove the static-flag from the nodes table. I think this needs to mature a bit more before it can be committed.

I have to agree with tdobes about this being the best, global solution.

As for static nodes, I agree that we should set them to weight=-10 but don't touch their 'promoted to home page' bit. that is not implied by 'static'

Is this patch still working on current 4.4 cvs?

Is there any thing specific about applying this patch other than creating an update.php file with the patch text in the file and running it while logged in as the administrator of the site?

Has any other weighted node approach been included with 4.4? This and taxonomy/node permissions are biggies to any site I can imagine other than completely public content sites. -GZ

I'd love the implementation chosen to be extensible enough to do some of the rankings described in this forum.

Cheers!

The integration of the node weight drop-down menu in the node submission/edit form is rather intrusive.

What happens with book pages -- these nodes already have a weight?

IMO the ability to order nodes within a taxonomy term is critical to the many types of Drupal usage. For example I have a need to control the sequence of products node listings (created through the ecommerce module) when selected by product category.

I tried this patch and it works well ... thank you for your efforts and good work.

I do, however, have some reservations with your approach…

Adding a weight to each node could quickly become unmanageable...because …well…there will in most cases be too many nodes. The existence of 22 nodes or more would break the -10 to +10 edit dropdown approach. Of course the size of the dropdown could be increased, or a text box could be substituted….but my main issue centers around the unmanageability of a the ordering of a large number of nodes in this fashion.

I wonder that if this need might be better served by applying a weight to a node / taxonomy term combination, possibly by adding a weight field to the tax_node table.

IMO, increasing the granularity to the node/term level would serve to increase manageability.

After a cursory examination of the current code (pre the application of your patch) I must admit my suggestions are mostly theoretical at this point at least in terms of my willingness and/or ability to implement the change as I am suggesting. I believe the required code changes would be overly invasive to the taxonomy module and would throw me too far out of step with future releases unless it was accepted by the community.

Plus, I have my doubts that my current level of Drupal knowledge is sufficient for me to pull it off.

Also, I do understand that your patch addresses the general issue of node ordering as opposed to just ordering within a taxonomy term.

But I would like to ask if my concerns about the manageability of the current approach and the possible advantages of a more granular approach as outlined above finds any resonance with you or with other users?

Thanks for taking an interest in this patch, Zackp1.

As you say, managing node weights at the term level makes little sense for many cases.

If manageability becomes a problem, someone will develop a Contrib module which sets the Weight according to some rules or other user interface. This patch is flexible enough to handle weights that range farther than -10 -> 10 and is flexible enough for other modules to set weights if they wish. I think manageability is important, but coding for it now is a premature.

FWIW, I'm late to the conversation, but I am definately in need of this and would love to see it integrated into the core. I'll read up on applying patches and see if I can get it going, but it really does seem to be something of a necessity. If you aren't running a pure, slashdot-ish type of news site, you probably have content you'd like arranged in some sort of order, but also would like the flexibility of adding it in terms of a collection of stories. I just loaded the content into a new site without realizing the limitation of chronoligical ordering of stories. If I'd known of that, I would have loaded the stories differently. (Or I may have opted for another system with more flexibility.)

I too am VERY interested in this patch. I am working with it now on a 4.4 install and having a few issues, but the concept is most needed! I hope this makes it in soon.

Apparently there's interest. This is active again.

+1 to introducing a weight for nodes. This is a well-considered patch.

A source of weighing issues is the hard-coding of sort order in taxonomy.module, e.g.,

Comments on some issues that have been raised:

1. This would interfere with node types (e.g., book) that already have a weight.

* Likely this could be addressed by simply removing the weight from book.module and using the new node one instead.

2. Weighing would be cumbersome where there were many nodes in a taxonomy.

* This sort of weighing is best used as an optional way of manually sorting a subset of posts--in other words, as a supplement to other default sorting.

I would love to see this for taxonomy views and forums.

This is an interesting thread to me - I've been using taxonomy_context module to display terms with their dependent nodes (it actually uses taxonomy module functions to recover the nodes to display), and have been very perplexed by this problem:
- my site publishes articles which I normally want to publish in reverse chronological order with the newest at the top (fine: Drupal standard)
- however, I also want to bring certain articles together in a series, with the first in the series at the top (ie in chronological order), and the series are created using the taxonomy.

Using the weight solution would be a pain, because you have to modify all the articles you want in a series to change the weight. Takes a long time.

How about optionally associating sort orders with taxonomy terms? For example, for each vocabulary term I would specify the sort order for:
- created date
- sticky
- weight (have to add a weight column to node)
- title
- user id
- anything else that might seem useful
Then at the same time I would specify whether each criterion was to be sorted ASC or DESC.

Come to think of it, you could write a module along the lines of taxonomy_context which would add these settings to taxonomy terms. Then all you would need to do would be patch taxonomy.module to pass the "order by" as a parameter rather than using it fixed.

Hmmmmm.....

My apologies... I hadn't realised I was going to change the title of the entire thread! Hope I've more or less put it back.

JG

This patch is essential for my largest Drupal site, so I'm very interested in seeing it in the Drupal core. I expect it's a fair bit of work to migrating a patch like this from release to release, and that's why it's been withdrawn. Take this as my vote for getting this Ior something very much like it) implemented in Drupal.

fwiw, I needed this functionality for a client and ported the patch to 4.6.3
had to change some things around, most notably with the node_admin_nodes -- wrote for functionality not beauty (quick dirty, possibly sloppy port)

Any chance there is a version that patches 4.5.2? It's the only version installed by my ISP and I would really like this feature.

Does this patch work with latest HEAD of drupal?
Thanks

Closing, this should be fully addressed with Weight: http://drupal.org/node/35984