It seems that when a node that generated a subqueue via this module is deleted, the subqueue sticks around... and there's no way to delete it in the nodequeue interface.

Would this be best done implementing hook_nodeapi? I'm a little surprised the module isn't currently triggered off that - instead it seems to create subqueues when a node of a type than can be added to a queue (rather than a type that is linked to a queue) is created.

Comments

tema’s picture

tema commented

I have quite a while not touching this module, but remember that subqueues were removed, possibly after viewing of it's (former) member. This is explained by design of Smartqueue API, similar to core menu system.

Please, check it again, and if it still not deleted, describe a way to reproduce it.

khalor’s picture

khalor commented

The behaviour is quite weird - after deleting a node that 'owns' a subqueue and then viewing one of the orphaned queued nodes, the subqueue still shows up at admin/content/nodequeue/{qid}, but not if you visit one of the orphaned queued nodes and click the nodequeue tab (node/{nid}/nodequeue).

Checking the 'nodequeue_subqueue' table in the DB shows the subqueues still exist, with a reference number that refers to a no longer existing node.

I'm currently using this Rules snippet of custom PHP code to get around it (triggered off 'After deleting content')
db_query("DELETE FROM {nodequeue_subqueue} WHERE reference = '$node->nid'");

kasperg’s picture

kasperg commented

I consider this a duplicate of #1116406: Subqueue isn't added till a queueable node is viewed. I've added a patch there which should fix both issues.