Add to "top" of taxonomy instead of bottom
| Project: | nodeorder |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
The weight_in_tid value assigned to the nid/tid relationship is the new MAX number, so in other words if I have 5 nodes, and 1 is the top node on the drag n drop list, and 5 is the lowest, when publishing a new node, it is assigned weight_in_tid of 6, and on the drag n drop ordering page, goes to the bottom. Then I can drag it to the top.
I'm using Nodeorder extensively for a customer who wants to have automatically filled node views, but still be able to re-order the nodes manually. However, the customer wants new nodes to go to the 'top' of the list instead of the bottom. The MAX numbering should remain the same. Instead, an option to reverse the drag n drop and "move up/move down" sort orders would give my customer what it wants but not alter the numbering system.
This way new nodes could move to the "top" rather than to the "bottom" of a Node Order, same numbering system.
Views that display the sorted nodes are sorted by weight_in_tid asc, just like the drag n drop page, and with the reverse option all one would have to do is sort desc in the View.
I may hack at this for my own purposes but thought I'd suggest (along with the Node Type filtering - that too would rock) such a feature.
#1
#2
So, I've made a hack to do this for my current project, and I hate doing that because if I need to update to a newer Nodeorder, I will have to reimplement this hack - though it's not much code. Not sure how I could do it as a separate module.
I created a new admin setting that, when selected, changes the default behavior in the nodeapi hook for 'update'.
Instead of assigning the node_term relationship the MAX + 1 weight, it first increments the weight of all the nodes in that term, then gives itself a weight of '1'. So, new nodes go to the 'top' of the Nodeorder when published.
Turning off the option in settings, returns Nodeorder to default placement (bottom of list).
Still refining it.
#3
Sounds interesting. Please post a patch so others can have a look.
#4
Although I guess the solution works in practice it doesn't sound very efficient, especially when a taxonomy has a lot of nodes associated to it. Wouldn't it be easier to change the sort order, i.e. DESC vs. ASC? You could probably make this configurable through settings on the taxonomy page and even set this per vocabulary.
#5
I thought about that, but then the sorting page's functionality would have to be completely reversed - from its theme to the way the draggable tables work, and that would be much, much more complicated.
It's one call to the database. 'Set weight_in_tid = weight_in_tid + 1 where tid = %d' - the tid being the one your node is assigned to. If I add the ability to place the node at any position, then the call would be the same but I would add to the where clause 'and weight_in_tid >= %d' where that last number is the position I send to it.
Since the table is locked during operations, it won't get munged by another publish.
#6
marcp,
I will definitely do that once I test it a bit more and feel it's doing things correctly.
Probably not next week, but the week after.
#7
Okay, so I'm deep in this project which is set to launch in the next two weeks. I won't be able to get to this until mid-June at this point. But I will roll out the patch at that time. Just FYI. Thanks.
#8
Hi there,
I'm looking forward to this update - are you still anticipating a release in June?
Thanks!
nkatt
#9
It's just a patch, but I've never created a patch before, and since I'm really busy working on this site launch, I just haven't the time to look at it. I really want to make sure it works before I release the patch.
The site has a soft launch Monday, so maybe I will get a breather before then and I can do it before July 1.