Add to queue from Node edit form

This patch basically removes and replaces all of nodequeue.module in one giant hunk. I tried to apply it to nodequeue 6 rc1 as you specified, but got the message, "Reversed (or previously applied) patch detected!"

I'd like to give some feedback on the patch and am willing to review it even though it's not against a CVS checkout, but perhaps you could reroll so it:

a)applies
b) at least has discrete hunks?

Thanks.

hey guys,
please find patch file attached.
includes functionality to allow you to add nodes to a nodequeue on the node/add form and add/delete nodes from a nodequeue on the node edit form.
code still needs a fair bit of work so open to suggestions / contributions :)

I think this would be a good addition. It should be configurable on a per-queue basis whether this form is added to the node edit form.

I'm unable to apply this patch, and manually adding this implementation of hook_form_alter causes a whitescreen error for me, with "Trying to get property of non-object in ...includes/theme.inc on line 220"

I would be happy to help with rolling these patches. I'm in IRC as ezra_ or contact me and we can figure out another way to communicate.

$ patch -p0 < nodequeue_node_add_form_add_to_queue.patch
(Stripping trailing CRs from patch.)
patching file nodequeue.module
Hunk #1 succeeded at 213 (offset -2 lines).
Hunk #2 FAILED at 284.
Hunk #3 FAILED at 339.
Hunk #4 succeeded at 744 (offset 49 lines).
Hunk #5 succeeded at 761 (offset 49 lines).
Hunk #6 succeeded at 2082 (offset 90 lines).
Hunk #7 succeeded at 2127 (offset 89 lines).
Hunk #8 succeeded at 2666 (offset 133 lines).
patch unexpectedly ends in middle of line
patch: **** malformed patch at line 194:

Hi ezra-g,
I was able to apply this patch to 6.x-2.0-rc1 , did you accidentally try and apply the patch to HEAD?

Thanks
G.

Patches should only be submitted against -dev versions, never stable releases. Applying the patch to -rc1 doesn't do any good since there's no way to check it in.

Changing title for clarity

This is just what I'm looking for but I'm not able to apply the patch...tells me it's malformed. Are others able to apply this (even against rc1)?

what's the status of this patch?
do we need to re-roll against dev?

Yes, it would be easier to read and evaluate if you re-rolled it. In the meantime, some feedback on how it could be improved.

- It would be more efficient to use nodequeue_load_queues_by_type than loading all queues at every node edit form using $queues = nodequeue_load_queues(nodequeue_get_all_qids(NULL));

- To correctly implement hook_nodequeue_form_submit you should use nodequeue_nodequeue_form_submit instead of just nodequeue_form_submit

hi ezra,
thanks for the feedback,
i've now re-rolled patch against dev snapshot =)

thanks
Graham.

I was just about to submit a feature request for this and luckily searched and found this issue first. This would be a great addition to the module!

Patch re-rolled against HEAD, fixed and updated to conform to Drupal coding standards. Now it should be easy for ezra to review and evaluate.

I also tested the feature and it works fine for me.

Thanks for re-rolling this! I took a quick look at this, and as I said in #7, "I think this would be a good addition. It should be configurable on a per-queue basis whether this form is added to the node edit form." -- This is an important detail so as to prevent cluttering the node edit form for folks who don't want this feature. Also, I see some direct queries to the nodequeue tables and I'd encourage you to make sure there's not an API function available.

Thanks!

I really could use this functionality, and I'd be willing to finish this up. I will work on adding the config options to allow the user to select whether the node is added automatically to the queue. As for API functions to replace direct calls to nodequeue tables, did you have anything specific in mind? This is my first foray into nodequeue, so I'm looking for API docs. Does this page look like it's accurate?

Thanks.

I changed the code a bit, because my node was added to all subqueues.
Replace all 3 instances off

$subqueues = nodequeue_get_subqueues_by_node(array($queue), $node);       

with

//$subqueues = nodequeue_load_subqueues_by_queue($queue->qid);
$subqueues = nodequeue_get_subqueues_by_node(array($queue), $node);       

Any change this will be included in the next version?

New patch including the option to show a certain queueu on the node edit form, feedback appreciated

Tested on my one of my sites, but with only the queues defined so needs more testing

Marking as needs review since I didn't see that there was a patch here until just now.

subscribing, thx! would be wonderful if we can add the node to a certain queue directly from edit or submit form ..

Thanks for this patch! It looks like a good start but needs some work:

A) There is no access checking to make sure that the current user can manipulate the subqueues before they are added to the node edit form. See the nodequeue_api_queue_access and nodequeue_api_subqueue access functions

B) It seems like you're identifying the node form in an unconventional way. See an example from og.module or another module that alters the node edit form.

C) The first hunk fails and so the patch won't apply.

This seems like a good start though and I'd love to see this feature added. Thanks!

its been a while since i've been in this issue, but i've re-rolled this patch with the following -

- added collapsible fieldset to the node edit form for the list of queues
- fixed B) in #26, identifying the node form in a more conventional way (same as OG basically)
- fixed A) added nodequeue_api_queue_access check in the hook_form_alter to see if the current user has the ability to manipulate all queues

I haven't added a call to nodequeue_api_subqueue_access, is this neccessary?

hopefully the patch should apply.

some irregularity caused patch to fail locally when i tried to re-apply it again. Re-rolled again, tested locally, seems to apply, this one should work.

Watching this with interest. My problem is that I need to add nodes to queues in a consistent manner (ie only from node-edit, or only from node-view, or only from nodequeue-edit), AND be able to specify a different (usually shorter) title for the node, on a per-queue basis. See http://drupal.org/node/543910 and http://drupal.org/node/442772.

I'm thinking that a logical extension of this idea would be to use a text field instead of a checkbox for each of those "add to nodequeue" fields. Empty = don't add. If there's text, and I can extract that for each added nodequeue item, it could be used to display custom nodequeue link titles.

@johnpitcairn,

This patch does exactly what it says on the tin. The added functionality you suggest, while it does sound valuable, seems out of scope for this patch.

Considering there is no current ability to 're-name' nodes in a queue as you are suggesting, the nodequeue annotate suggestion in http://drupal.org/node/442772, sounds like a good option for what you are after.

I would rather see this patch committed as is (since this issue has been on the go for over 1 year) then when some functionality comes along that allows the ability to re-name nodes in a queue, then we can extend the functionality here to accommodate that at a later date.

Sure, given I had completely missed the existence of nodequeue_annotate, agreed.

Subscribing so I remember to review the patch sometime in the next few days.

Forgot about this for a while. I tested the patch in #29 against the latest dev, which still applies. So far, everything appears to work just fine. I haven't tried it with particularly complex queues, though.

subscribing

The patch in #29 (and to some extent, the entire issue) assumes that a node can only be added to a queue once. That's not actually the case; see #329583: Items in queue show more than once in a view around comment #5 for a little bit of history. With this patch, every time I edit and save a node that's marked as being in a queue, it adds the node to the queue again. You just can't see it in the drag/drop interface (see #593468: adding the same node more than once to a queue causes bad behavior), but it's in the database.

Either the interface for this feature request needs to be reconsidered, or individual queues need to have an option to accept only distinct nodes.

Here's a new version of the patch, which checks first to make sure the node isn't already in the queue before adding it again.

Also in the patch, if the box for the queue is unchecked on the edit form, every position of the node is removed from the queue instead of just the first position. This required some API changes to nodequeue_get_subqueue_position() and nodequeue_subqueue_remove_node() which hopefully should be non-disruptive.

I have used this patch to auto add nodes to the nodequeue. But whenever I change a node from one taxonomy term to another, the node stays in the old nodequeue which causes the node to appear twice on the website.
The only way to solve this is to manually delete the node from the old nodequeue.

Any suggestions on how to auto delete a node from its old nodequeue?

This would be a very useful feature; however the patch needs more work...

+++ nodequeue.module	2010-06-22 12:13:56.000000000 -0500
@@ -174,10 +174,113 @@ function nodequeue_nodeapi(&$node, $op, 
+        foreach ($node->nodequeue_options as $key => $option) {
+          if ($option != 0) {

Use array_filter() here instead and save yourself the if statement. The checkboxes form element is designed to work nicely with this.

+++ nodequeue.module	2010-06-22 12:13:56.000000000 -0500
@@ -174,10 +174,113 @@ function nodequeue_nodeapi(&$node, $op, 
+    //get queues associated with current node type

Comments should start with a capital letter, end with a full stop.

+++ nodequeue.module	2010-06-22 12:13:56.000000000 -0500
@@ -174,10 +174,113 @@ function nodequeue_nodeapi(&$node, $op, 
+              if (variable_get('nodequeue_show_in_nodeedit_' . $queue->qid, 0) != 0) {

Do we have to have a variable for each queue? Why can't this setting be stored in the nodequeue table?

+++ nodequeue.module	2010-06-22 12:13:56.000000000 -0500
@@ -174,10 +174,113 @@ function nodequeue_nodeapi(&$node, $op, 
+ * Function to get the queues a user has chosen to add content to
+ * from the node-add form.

First sentence of the docblock header should be a single line. To shorten this, consider that you don't need to say 'function to'! ;)

+++ nodequeue.module	2010-06-22 12:13:56.000000000 -0500
@@ -174,10 +174,113 @@ function nodequeue_nodeapi(&$node, $op, 
+function nodequeue_get_selected_queues($nid) {

Could do with a better name... I'm not really sure what this does, whether I read the docs or the code.

+++ nodequeue.module	2010-06-22 12:13:56.000000000 -0500
@@ -2028,24 +2146,33 @@ function nodequeue_subqueue_add($queue, 
+ * @param $complete
+ *   Whether to remove every instance of the node or just the first in queue.

I don't really get this variable name. $all maybe?

+++ nodequeue.module	2010-06-22 12:13:56.000000000 -0500
@@ -2190,12 +2317,30 @@ function nodequeue_queue_back($subqueue,
+ * @return
+ *   A non-associative array or an integer. If the node is not in the subqueue,
+ *   an empty array or 0.

Ew, variable return type??? How do you know what you're going to get??

+++ nodequeue.module	2010-06-22 12:13:56.000000000 -0500
@@ -2190,12 +2317,30 @@ function nodequeue_queue_back($subqueue,
+function nodequeue_get_subqueue_position($sqid, $nid, $complete = FALSE) {

Again, $all makes more sense here.

Powered by Dreditor.

I just wanted to chime in and point out something I just noticed: nodequeue has a rule for the rules.module which allows you to add content to a queue (at least in D6). So, it would be simple to create a rule which adds a particular type of content to a particular queue upon creation of the node. Just wanted to point that out.

Good tip Rob! Unfortunately I don't see that option in D7.

This is old, but some people might need it. I created a module that does this (D7 only): http://drupal.org/sandbox/Luxian/1840292

If maintainers agree, I can provide a patch for adding this into the module.