Taxonomy Sync Queue

As I suspected when we talked about this on IRC, this is clearly the functionality required/bug reported here:

#332461: Removing term from Node does not remove node from tax queue
#939544: nodes catagorized with terms are not automatically put in the smartqueues for taxonomy queues

So I'm closing those issues even if they are older, because here we have some actual code and someone (hopefully) willing to work on it :)

Now, about the implementation, I really think that this functionality should be provided by the smartqueue module, with a setting like 'Sync queues with vocabulary' or something like that..

The big question is: will you post this code as a patch for smartqueue? :)

@jiv-e, I *really* think that the sync option should go straight into smartqueue because it's a very small feature that doesn't need the overhead of a full blown module :) But maybe that depends on what do you mean by "more advanced syncing options"..

Anyway, I'm happy to hear about your learning experience and I'd gladly accept your help in the issue queue, but I've just been assigned as a co-maintainer so that's not my call to make. For the present, though, I think the current team can manage the issue queue pretty well, but feel free to post some patches and we'll see how it goes :)

Subscribing. I no longer work at the newspaper (where I needed this functionality), but I might need this for another project at some point in the future.

Great plugin. Unfortunately for me, the 'sync nodequeue with terms' checkbox doesn't stay checked after hitting save.

D7 version would be wonderful:)
thanks for the work on this.

i'm also interested! is there any news with this project?

Any news on this??

I needed this functionality for a project (which just happens to be on D7 with nodequeue 3.x - since that is now the latest development version, I also changed this issue to that version).

Attached is a patch that adds this functionality to nodequeue 7.x-3.x. It is heavily inspired by jiv-e's module from the issue description, although in some cases D7 is so different from D6 that it made more sense to just implement from scratch.

There is no implementation for hook_nodequeue_add, because the way 7.x-3.x functions doesn't make the subqueue available for adding if the taxonomy term hasn't been added. Potentially, this is something that might be changed (i.e. make subqueues available in the nodequeue tab if the corresponding term hasn't been assigned; with this functionality implemented, that makes somewhat more sense than it does now).

Another problem is that currently, the use_parent flag is not honoured by the code. I personally don't need it, so possibly someone else could look into adding that.

New version of the patch, just with different export options (test framework seemed to choke on the fact source and destination had no prefix in previous version).

There was a small issue with the update hook that adds the field. I rewrote it.

Yet another update, previous version would not correctly handle new terms for which no subqueue existed yet.

Here's an updated patch that works with 7.x-2.0-beta1.

patch for 7.x-2.0-beta1 works fine for me to input a new content in the right subqueue automaticly.
also if you delete the content it will be deleted in the queue.
but if you change the term of the content it will be doubled in the queues -> the old queue-entry will not be deleted....

Unfortunately, this is still not a feature in the actual module, so if you find a bug in the patch that means the patch simply still needs work, not that the issue suddenly becomes a bug report (you may have thought you set the status for your comment, but it is for the entire issue). I made these changes.

Updated issue summary to reflect the fact this has evolved into a patch for Smartqueue taxonomy instead of a separate module

I ran into the same problem as @hans_dampfer and I think he is right. The above patch addresses the new content and not the case of changing the taxonomy terms. Shouldn't the module sync the subqueue (sqid value) directly when the node tid is changed just in the case of a single taxonomy term field and not multiple ones.

I guess having such feature would be great unless its there and I'm not finding it.

@hans_dampfer and/or @operations: Could you check whether it works if you save the node a second time? I am wondering if the data for terms assigned to the node is the *new* data that is being saved at the moment the logic is executed. The logic in itself looks sound; it simply checks for all eligible subqueues whether the associated term is assigned to the node and adds it or removes it (or leaves it alone) as appropriate. This might suggest that the logic should be applied from a different hook than hook_node_update (although I don't see a more appropriate location at this point) or the data about eligible subqueues needs to be retrieved in a different manner.

Right, I did some testing and confirmed the issue. I do now also have a better understanding of why #332461: Removing term from Node does not remove node from tax queue was marked as a duplicate and I have my doubts whether I actually agree with that. The attached patch does solve that as well, but it does it unconditionally, for all queues, regardless of whether the queue is configured to keep node assignments and tags in sync. The rationale behind that is as follows:

When a tag is removed from a node, the corresponding subqueue is no longer available for the node to be added to or removed from (at least from the nodequeue tab on the node itself). This makes a lot of sense, the whole point of the feature is to allow nodes with a certain term on them to be added to a nodequeue specific to the term. It is not unreasonable to remove the node from the subqueue when it no longer has the required term assigned. However, the node does remain assigned to the subqueue (this is basically the issue reported by @hans_dampfer, @operations and from #332461). This fact is now hidden from the user for an important part, because the subqueue for the old term is no longer shown in the nodequeue tab (the fact the node is still assigned to the subqueue *can* be seen from the nodequeue admin pages).

@eelkeblok Many thanks for the patch, I will test it soon and let you know. However, I understand that it adds the checkbox of resync and also fixes the term changing issue which myself and @hans_dampfer raised above. The question is if I don't want every created node to be added directly to the nodequeue and I want the last fix , would I apply the last patch to the dev version and deselect the sync checkbox? Is that true?

Thanks again.

Yes, that is correct (by the way, there should not be any need to turn off the syncing, it should be off by default, unless you turned it on previously). This is exactly why I think #332461: Removing term from Node does not remove node from tax queue should have remained a separate issue. Removing a node from a subqueue as soon as the corresponding term is removed from the node seems to be desired (or at least expected) behaviour in all cases. The desire to have a node also automatically *added* to a subqueue (and consequently have the tag removed when the node is removed from the subqueue, just to keep things consistent) is a separate scenario.

Of course, the two issues have a strong relation and from a purely technical point of view (they would both need to add a hook_node_update), it probably is quite practical to combine them in a single patch.

Aside: One consideration for the auto-removal from the queue if the term is removed in all cases is this; in some circumstances, the user experience actually deteriorates. A consequence of the old behaviour was that once a node was ever added to a subqueue for a certain term, its position in that queue would be retained, which could be beneficial when the term was ever re-added (of course, it would have all sorts of unexpected side-effects as well, like the node still showing up on the screen where the order of nodes in the queue is manipulated and in Views, unless an extra filter on the term itself is added). It's probably up to the module maintainer to decide whether this is a point worth considering. If it is, I would advocate some sort of mechanism that complements the solution in this patch by still removing the node from the queue, but storing the old position somehow, and re-adding the node in that position when the term is re-applied.

Add fact there is also a patch for 3.x

@eelkeblok Great stuff! I confirm the last patch works as desired and solves my problem specified above. I think it makes sense to remove the node from the sub-queue when the term is changed, so that it should be added manually again to the new sub-queue. This omits a step of removing the node from the old sub-queue manually and I think it is the best practice unless the maintainer of the module has another thoughts as you mentioned above. Thanks for the patch anyways..

Anyone facing a problem with 7.x-3.x-dev version? @eelkeblok After updating to this version and applying the above patch, I can't access any nodequeue other than the smartqueues (taxonomy ones) through the nodequeue tab. After tracing the problem I found that this version removes the qid fields and adjust keys and indexes to use machine name, as stated also in the update_7300 (maybe to be exportable as features, don't know!).

However, it looks like this version is not so stable and I'm thinking of rolling back to the 7.x-2.x-dev or 7.x-2.0-beta1. Can the patch be applied to any of those versions? or we need to re-create a new one?

Thanks!

Updated issue summary.

subscribe

@goatvirus: No need to post subscribe comments any more, you can "follow" issues without posting a comment for some time now (look for the button at the top right of the page).

@operations: I'm not sure what is involved with getting the patch to work with 2.x. It might be a simple matter of applying the patch on the 3.x branch and than cherry-picking the change on the 2.x branch, I don't know how different the 2.x and 3.x codebases are. lookatthosemoose provided a 2.x version of the patch previously, maybe they can be tempted to do the same for this version.

Hello, here is the patch for the 2.x version of the module.

@operations: it might help you :)

@eelkeblok: thanks a lot for your patch ! But I think I noticed a small issue : in "smartqueue_node_update", the "if ($items)..." statement may be skipped when the node had some terms previously and no more after edit. So some nodes may still appear in nodequeues whereas they should have been deleted. What do you think ?

Regards,
Renrhaf

Yes, looks like you're right. What would be required is to check if the node is eligible to be added to any synced subqueues and if so, first check in which queues it still is where it shouldn't be, and then add it to queues it should be in but isn't in yet. It might be tempting to just remove it from all queues and re-add it to those it needs to be in, but then the queue position would get lost.

Feel free to submit an updated patch, I don't expect to get time to work on this again soon.

I set up a workaround for this with Rules, whereby the node is added to the desired Smart Queue(s) each time it is saved. This has the effect of automatically ensuring it is in the right queue and not the wrong queue.

@millionleaves can you post actions you made with rules ? thank you

It's a simple rule - see below:

The machine name of my content type is product_display_without_image - you will need to change the rule to match yours.

{ "rules_update_smartqueue_when_add_or_update" : {
"LABEL" : "Update smartqueue when adding or updating items",
"PLUGIN" : "reaction rule",
"OWNER" : "rules",
"REQUIRES" : [ "nodequeue", "rules" ],
"ON" : {
"node_insert--product_display_without_image" : { "bundle" : "product_display_without_image" },
"node_update--product_display_without_image" : { "bundle" : "product_display_without_image" }
},
"DO" : [
{ "nodequeue_action_add_node" : { "node" : [ "node" ], "queue" : "catalogue", "unique" : "1" } }
]
}
}

[edit to fix minor typo]

@millionleaves I don't think that's the right rule for this issue.

The part that is missing is that when you switch your taxonomy reference the node should be deleted from subqueue in which it is located before it is saved to a new one. That is not something you can achieve with Rules.

Is anyone still working on a solution for the 7.x-2.1 version?

Since the 3.x version is unsupported, re-classifying this issue for 2.x.