Hi, I haven't been able to find out if the module is already integrated with rules, so I started an integration myself (partly b/c I needed it, partly b/c I wanted to exercise a bit) here: https://github.com/omissis/nodequeue_rules
It's far from being clean or complete, as it just solves my needs at the moment (integration with rules actions, no conditions, validations and whatsoever), but if you think it makes sense I can keep on developing this extension, otherwise if there's already something available, that would be more than welcome :)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

amateescu’s picture

Status: Active » Closed (duplicate)

We're dealing with Rules integration here #952448: Add rules events support.

omissis’s picture

Version: 7.x-2.0-alpha1 » 7.x-2.x-dev
Category: feature » task
Status: Closed (duplicate) » Active

I am reopening it since the ticket you're pointing to is about Drupal 6. I'm providing a first working patch in a few hours. Here's the sandbox in the meanwhile: http://drupal.org/sandbox/omissis/1192572

amateescu’s picture

I saw that sandbox a while ago, but a patch would be much easier to review.

omissis’s picture

yep, I see :)
I am reworking the module a bit b/c I am not really happy with the first implementation i did. I'll keep you updated anyway.

jackalope’s picture

Any new plans to work on Rules integration for Drupal 7? It's a great help in Drupal 6, but that other thread seems to only indicate that work is being done on the 6.x branch.

Mohammed J. Razem’s picture

Well, this is basically the patch (from diffing the sandbox) against 7.x-2.x-dev

patrickd’s picture

Status: Active » Needs work

@ #6
Incomplete patch, rules integration files nodequeue.eval.inc and nodequeue.rules.inc are missing,
this can't work. Please test patches before posting them.

Anyway, I think the rules integration should be included as addon module, so anybody can decide wether he wants to use it or not.

patrickd’s picture

Status: Needs work » Needs review
FileSize
3.82 KB
1.91 KB

I extracted and cleaned the stuff of omissis module that was actually really working:
- action to add a node to a nodequeue
- action to remove a node from a nodequeue

Maybe we can retry implementing the event handling stuff on this base.

I attached a patch that adds the rules integration (nodequeue_rules) submodule to the addons directory and an package holding the current submodule. (maybe people, like me, are satisfied with the working rules actions).

btw: if interested, I'd like to continue further integration of rules and services as co-maintainer

13rac1’s picture

Status: Needs review » Needs work

Yay! I had the project of making that sandbox into a patch on my todo list for an on-hold project. Happy to see it implemented before I needed it. Patch applies and works correctly. Fix the minor whitespace error and I'll set it to RTBC; I'd fix, but then I couldn't set RTBC. Thanks!

../../patches/nodequeue_rules_integration-1125922-8.patch:52: new blank line at EOF.
+
warning: 1 line adds whitespace errors.
patrickd’s picture

Status: Needs work » Needs review
FileSize
3.82 KB

All right, here it goes

13rac1’s picture

Status: Needs review » Reviewed & tested by the community

Perfect. Thanks!

amateescu’s picture

Status: Reviewed & tested by the community » Needs work

I have two issues with this patch.
1) I don't think a new submodule is the way to go, since all we need is a nodequeue.rules.inc file.
2) It's based on qids and we're trying to move everything to queue names (at least in 7.x-2.x).

Also, how about getting rules events support in this patch?

Eyal Shalev’s picture

+1

rogical’s picture

+1

Fidelix’s picture

$ drush en nodequeue_rules -y
The following extensions will be enabled: nodequeue_rules
Do you really want to continue? (y/n): y
WD menu: PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 's.name' in 'on        [error]
clause': SELECT q.*, COUNT(s.sqid) AS subqueues FROM {nodequeue_queue} q LEFT JOIN
{nodequeue_subqueue} s ON q.name = s.name WHERE q.name IN (:to_load_0) GROUP BY q.name; Array
(
    [:to_load_0] => destaques
)
 in nodequeue_load_queues() (line 614 of
/www/somesite/sites/all/modules/nodequeue/nodequeue.module).
nodequeue_rules was enabled successfully.
pavlosdan’s picture

Status: Needs work » Needs review
FileSize
6.89 KB

Here's a patch built upon the one in #10.

Changed to use queue machine names instead of qids.
Added 2 rules events: "After node is added to a nodequeue" and "After node is removed from a nodequeue".
Added 1 rules condition to check if a node belongs to a specific nodequeue.

Kept the module way to add the hooks that invoke the 2 rules events but these could be added after the module_invoke_all of their respective functions if the rules module is present.

seancorrales’s picture

I downloaded patch #16 and it works great. I'm using Nodequeue 7.x-2.0-beta1.

I can only confirm the "Add to nodequeue" rule works as that's the only one I've used so far. Haven't worked with any of the others.

michaelfillier’s picture

#16 is working fine for me against 7.x-2.0-beta1. Like seancorrales, I have only tested the "Add to nodequeue" event.

seancorrales’s picture

Status: Needs review » Needs work

I've been using the Nodequeues rules integration for a week or so now and just finally encountered a bug with it.

The code doesn't seem to handle taxonomy queues, unfortunately. What I'm seeing happen is a new subqueue is created if there isn't one for the term on the node. When adding the node to a subqueue, it just automatically goes into the first subqueue so even though the correct subqueue has been created for the term, the node is not placed in that queue.

I've disabled all my rules working with subqueues and I'll try to come back to the issue when I have some time to look into the code more.

fenstrat’s picture

#16 is working here as well, but like others I've only tested the "Add to nodequeue" event.

MXT’s picture

Hi all,

can you please add a rule that allow something like:

"Pick up the top element in a nodequeue and do some action on that element"

e.g (specific case):

I need that every day the first node in the nodequeue is set to "sticky" (or flag a custom field on it like "put the node in the home gallery)

May be this old solution can provide some ispiration: http://drupal.org/node/374592#comment-3863208

Thank you very much for taking in consideration this request.

carn1x’s picture

MXT, you should create a new issue for this request I think. That said, this is already possible I think using the Views Bulk Operations module? It provides an action called "Load a list of entities from a VBO View" which you could use on a View that selects the top node in a nodequeue. http://drupal.org/project/views_bulk_operations

pavlosdan’s picture

In reply to #19 the code in #16 does indeed make the assumption that there is only one subqueue in the queue which I realise now that this might have been a mistake seeing as a Nodequeue can have many Subqueues (apologies for this).

I am not sure how to handle many subqueues at this stage if we are going forward with using machine names but I will keep looking into it. Another issue that might come up is that subqueues do not have machine names which could make exports tricky to handle as a subqueue might have one ID on a dev site and another on the prod site. Any insights from someone with more experience in this subject would be greatly appreciated.

adriancruz’s picture

#16 is working for me as well, can confirm "Nodequeue the node belongs to" (conditions) and "Add node to nodequeue" (actions) are working.

Anonymous’s picture

Status: Needs work » Patch (to be ported)
FileSize
8.48 KB

I've used the patch in #16 and added a rule for swapping nodes in a subqueue.

The patch contains the full nodequeue_rules addon (diff against the current 7.x-2.x), not an incremental patch on patch #16.

joelcollinsdc’s picture

fantastic work guys. works great.

Angry Dan’s picture

The patch in #16 seems to work fine for me with a rule that adds all new nodes of a content type to a queue.

But I do think that this should be a part of the main nodequeue module, there is no reason to have nodequeue_rules

kbasarab’s picture

#25 works well for general nodequeues. Does run into issues when using SmartQueues though. When adding to a smartqueue taxonomy queue the node automatically generates the subqueues correctly but does not add the node to the subqueue. On firing the rule the second time the node is added to the first subqueue of the item and not the queue of the terms.

kbasarab’s picture

Status: Patch (to be ported) » Needs review
FileSize
1.13 KB
8.12 KB

In response to #28 here is a patch that adds support for subqueue and smart queue taxonomy. Adds some extra functions in to not break anything if smartqueue is disabled.

Included a full patch and the interdiff between my changes and #25.

kbasarab’s picture

Reattaching since interdiff was named "patch" accidentally and that will fail testbot.

RunePhilosof’s picture

Renamed the condition to use the proper namespace.

akalata’s picture

#31 works for me, thanks!

ottawadeveloper’s picture

So I really like this patch - rules are great things, especially with taxonomy smartqueues. #31 worked pretty well but I discovered a few things that could be better (specifically around how multi-select taxonomy references are handled when using Rules to auto-add nodes to the queue).

Most of my changes are based around our particular use case for Rules which I feel will be a common one: using Rules to auto-add nodes to taxonomy smart queues, using both multiple select taxonomy fields (which would involve the same node in multiple subqueues) and using normal taxonomy fields.

  • If a node is added to two subqueues for a single queue, it is only removed from one of them when the remove action is called.
  • If a node is added to a subqueue where it already exists, it is added again, causing all the problems from #593468: adding the same node more than once to a queue causes bad behavior to occur. While this is expected behaviour (from the referenced issue), the condition to check if it's in the queue already is not a perfect solution (since you may want it in multiple differnet subqueues within the same queue but not twice in any particular subqueue).

To solve these, here's a new patch where I've added the following:

  • The remove action will loop through each subqueue and remove it from each one. This is, in my mind, the most intuitive behaviour of removing a node from a queue and really the only way I can see handling taxonomy smartqueues.
  • The add action has a new parameter to prevent duplicates - if selected, it will prevent duplicates from being entered into any particular subqueue. Rules that would like to prevent duplicates from being entered into the queue could use the condition instead of this.
Jean-Rémy Praud’s picture

Hi,

This feature looks nice. Do you thing that the module be updated soon? I'm quite new to patches, and I don't want to break my production website...

Thanks

leanderl’s picture

Thanks for the hard work with this. I found and deployed this patch (#33) to 7.x-2.x-dev (after some confusion with 7.x-3.x-dev) and it works great for my use case. Hope it makes it into the module soon.

It is in my usage scenarios a very important part of using nodequeue when trying to create simple ui for editors to order their content based on "free" criteria. They shouldn't have to first create a piece of content and then add it to the queue and then order the queue. It should seamlessly be inserted the queue as the "newest" item. Then if they feel it shouldn't be displayed first (or last) they do a maual edit of the list order. Limiting number of items displayed is done by views anyway. So there is no reason a node shouldn't be in a queue handling a particular content type.

Thank you again for your work on this.

sambfries’s picture

Found a bug with #33's nodequeue_rules_node_in_queue; if the node is not in any queues, the return value is true, when it should be false. Attached a patch to fix this.

Robin_K’s picture

#36 works for me! Thanks.

shortspoken’s picture

Works like a charme! Thanks a lot!

nunoveloso’s picture

Iteration of #36, to fix a PHP error and fix a var name.

AjitS’s picture

Status: Needs review » Reviewed & tested by the community

I tested this and it works fine. This should have been integrated with nodequeue way back! Well done! Thanks.

bibo’s picture

I further added simple integration to smartqueue_domain with this patch. It is based on #39.

This patch ensures that domain enabled nodes can only be added to smartqueue_domain generated subqueus that belong in one of domains that the node is published to.
Otherwise nodes would fill queues of domains where they can never be shown.

This might not be relevant to m ost people, so I wont mess with "Needs review". The patch might only be useful for the few people who also need to support the (hardly functioning) smartqueue_domain -module.

bibo’s picture

Here is a new version of my previous patch. Fixed a strict error message (that you get at least when using PHP 5.5).

othermachines’s picture

Status: Reviewed & tested by the community » Needs work

@bibo - smartqueue_domain is functioning a bit better now. :-)

Nodequeue has a hook_nodequeue_subqueues() function that will "Fetch a list of subqueues that are valid for this node from the owning module." It is invoked by nodequeue_get_subqueues_by_node().

I think that if we use this function instead of nodequeue_load_subqueues_by_queue() we can bypass the problem that @bibo is trying to solve since it would allow smartqueue modules to prevent certain nodes from being added to certain queues.

Not 100% sure about this - and I hate, hate, hate to revert an RBTC - but I think it's definitely worth a look.

othermachines’s picture

Status: Needs work » Closed (duplicate)

There's work for 7.x Rules integration happening at Issue #952448: Add rules events support so probably better to focus efforts in one place. Haven't done any testing, but it looks like they've built in the smartqueue checks over there.

akalata’s picture

Status: Closed (duplicate) » Needs review

Re-opening, because while the referenced issue has provided Rules support for nodequeue-specific Events, it does not provide any Actions.

fizk’s picture

Status: Needs review » Closed (duplicate)

@akalata Thanks for the heads up. Can you create a new issue Actions support?

akalata’s picture