Add support for cron queue to avoid php timeout

Does it mean that you may implement it within VBO?! I hope Job queue will help you make it easier with its almost ready-to-go function.

8D - Love the hook system!

If yes or maybe, I'd like to know when do you think you could achieve such a feature?

Cheers Captain!

STEP 1:

drupal.org hasn't updated the tarball from CVS yet (I thought so, but tried anyway)

In the last dev version I used to test:
$Id: views_bulk_operations.module,v 1.29.2.20 2008/10/10 18:35:31 kratib Exp $
^{Version taken from the "Operations" page after the "no operation enabled" error message. See below}

- The selected actions for my view worked, but once the actions had been performed with the successful messages, I got on the same page a "No operations are enabled" error message. Indeed, all my actions were removed from my VBO_view (I hadn't checked before performing). I guess that the reason it worked is about some views' cache or so.
- All "taxonomy node operations" were available again, compared to the version I used before.

- Kind of bug: Selecting all (884) nodes from the view with 50 of them exposed per page (Image 1) led to a confirmation page where only the fifty of them were selected (Image 2). Actions were effectively performed on the 50.

Note: I forgot to run upadte.php at this stage.

As we could have expected:
- No "Job type" parameters (from admin/settings/job_queue) were available.
- No jobs were queued (admin/logs/job_queue).

-----------

Important: Until now, I've been using the following dev version (tarball release of September the 6th, 2008):
$Id: views_bulk_operations.module,v 1.29.2.17 2008/09/05 09:52:03 kratib Exp $

You commented that it was buggy because:
"settings for bulk ops views are currently stored in the variables table..."

I file you my version of the whole module in a ZIP (.txt for upload grant) in case you couldn't/wouldn't use those from the CVS or your own computer (don't rely on the .info file version), or in case it's less buggy than the current dev release.

-----------

Impatiently looking forward to the tarball release! Best regards.

_{PS: Next time, I won't forget to run update.php and check the "operations" page of my VBO_view}

You were probably right. I've just tested your brand new version:

First, please note that we work with:

- Drupal 5.11
- Views 1.6 patched with:

#218187: Views cache too large
#143888: support subqueries #37

- Apache 2.2.8
- MacOS X Darwin
- PHP 5.2.6 - Memory limit 512M
- MySQL 5.0.45

Please let me know anything else you'd need.

So, I deleted the old VBO folder then put the new one and ran update.php + cleared views' cache.

Then, Image 3:

• I selected ALL image_nodes tagged with "Empty moves I" of the view (no mistake this time).
• I chose the action "Change to a certain workflow status" called "Doc interne"
• Selected the "Perform background" checkbox and validated for "10 nodes + 499 others".

In the next step, Image 4:

• Because I couldn't wait, I opened the "Queued jobs" logs page.
• There it I got succesful user messages but Queued jobs claimed that 654 jobs were queued, while we only asked for 509.
The first 9 nodes you see in the Queued jobs logs are Page_nodes, and were not selected in the VBO_view.
• The following nodes you can see are correctly selected ones.

In the meanwhile, Image 5:

• A small temporary server overload problem. I found that drupal checked for "Available updates" for quite a few modules... at the same moment.

Afterwards, Image 6: I got three "Invalid argument supplied for foreach() in views_query.inc" errors:

• On line 82.
• foreach ($view->filter as $i => $filter) { from the "function _views_view_build_filters".

• On line 16.
• foreach ($view->argument as $i => $argument) { from the "function _views_build_query".

• On line 196.
• foreach ($view->sort as $i => $sort) { from the "function _views_view_build_sorts".

^{Note: I've quoted the lines from my views_query.inc file cause I use a patched views.module (with 143888 #37).}
Could those error ever be related to nodes that wouldn't have a workflow?

Problems now, Image 6:

• I've then checked which node_operations queued were the remaining ones, since 509+9=518 are from 654... Surprise: Job queue has now queued 5002 nodes...
• I can't check each page of the log, but they seem to belong to image_nodes
• Yet, the presence of non-image_nodes at the beginning of the list (Image 4) is scaring me! We have around 7800 image_node but a few hundreds of many other types. While we were about to switch all our image_nodes to the "Doc interne" status, we don't want the other node_types to get it...
• What's strange somehow is that it *seems* that the Jobs queued after the requested ones were some VBO Operations left-overs from yesterday, before I left the office. Indeed, just after the "Empty moves I" tagged nodes are coming the "Les 4 saisons" tagged nodes, wihch I tested yesterday... but it could just be coincidence.

FREEZE!

• No other Background VBO has been performed. Just a normal VBO on a single image_node selected has been performed, with no consequence on the Job queue. Still, they're 5002 waiting!
• I've disabled the poormanscron.module, so that they be not performed.

Aaaaargh... I thought they were so I deleted them!!

Your suspicion that "the Select All feature might not be taking full consideration the filter settings" has been one of mine too.

End of the day, I'll get back next week. Thank you very much!

I have no idea why such a mess happened.

Today, I've deleted the too numerous jobs by hand in the DB, and I've tried again.

With the same settings, it has worked for a single enqueued node job, and for 17 others. Fearing for further issues, I haven't enqueued bigger jobs yet. But it seems to work correctly now. Indeed, I've even got user messages that I haven't had the first times (Image 10).

Just publishing the image of a succesful VBO Job queue for testers to compare.

Feature request I'm going to post for Job queue: add views integration so that my node won't appear anymore in my view "nodes without workflow status" if they are enqueued... and many more useful uses as well.

Many big thanks for what you've done so quickly Karim!

Just an adjustment about this particular feature. This is a very concrete need fed back by my teammates.

My editors would enjoy an option on a "front end" page (such as on the confirmation page "Are you sure you want to perform the Operation..." or even on the main VBO view_page) the possibility to:
- perform now (user message would say: "Please note that this may take a while, depending on the number of node and operation. In case of numerous operation, you should choose to perform background to avoid PHP timeout or server access breakout". This is just an user message example as I probably don't use the correct words and wording).
- perform background (example user message would say: "Please note that the operations will be performed next time the cron [not such an end-user-friendly word] runs. In the meanwhile, you view may not reflect the future update of your nodes. Beware not to queue twice the same job on the same nodes.")

I guess a single checkbox would it. What you could do is add another checkbox in the Setting page to "authorize end user to override this [background] setting" (in a better wording of course!), so that admins may grants end-user or not access to this great option.

I'll be posting the other features request ASAP. Was a pleasure to help testing. BTW, will you commit this?!

Arsène

I hope I consistently centralised a few feature requests around mine for the Job_queue.module: #330027: Adding views support - implementation suggestions.. Feedbacks welcome, if one can.