During batch recompute, scheduler data is wiped out

My challenge is that now, when I run the code below, it clears out the
scheduler table data that I previously populated during node creation.

The simple problem here is that to remove items from Scheduler's table requires a "DELETE FROM {scheduler}....." and there's very few places that's called. I see no reason why a node_load() followed by a node_save() should wipe scheduler's table. I'd need more info (I suggest you add debugging code before all of schedulers "DELETE FROM" statements to nail down where exactly the deletion occurs. That would help try and figure out what's going on).

Hey there,

First off a disclaimer, I've never used scheduler module before and I'm not familiar with the specific code and node set ups in this case. Plus its a little late and I've had a couple of beers. However, I took quick look at the code for the scheduler module and found this:

/**
 * Implementation of hook_nodeapi().
 */
function scheduler_nodeapi(&$node, $op, $teaser = NULL, $page = NULL) {
  if (user_access('schedule (un)publishing of nodes')) {
    switch ($op) {
      case 'load':
        if ($node->nid) {
          $result = db_query('SELECT * FROM {scheduler} WHERE nid = %d', $node->nid);
          if ($result && db_num_rows($result) > 0) {
            $row = db_fetch_array($result);
            $row['published'] = $row['publish_on'] ? date(variable_get('date_format_long', 'l, F j, Y - H:i'), $row['publish_on']) : NULL;
            $row['unpublished'] = $row['unpublish_on'] ? date(variable_get('date_format_long', 'l, F j, Y - H:i'), $row['unpublish_on']) : NULL;
            $node->scheduler = $row;
          }
        }           
        break;

      case 'submit':
        // right before we save the node, we need to check if a "publish on" value has been set
        // if it has been set, we want to make sure the node is unpublished
        // since it will be published at a later date
        if ($node->publish_on != '') {
          $node->status = 0;
        }
      
        //adjust the entered times for timezone consideration
        $node->publish_on = $node->publish_on ? strtotime($node->publish_on) + $node->timezone : NULL;
        $node->unpublish_on = $node->unpublish_on ? strtotime($node->unpublish_on) + $node->timezone : NULL;

        break;
      
      case 'insert':
        //only insert into database if we need to (un)publish this node at some date
        if ($node->publish_on != NULL || $node->unpublish_on != NULL) {
          db_query('INSERT INTO {scheduler} (nid, publish_on, unpublish_on, timezone) VALUES (%d, %d, %d, %d)', $node->nid, $node->publish_on, $node->unpublish_on, $node->timezone);
        }
        break;

      case 'update':
        $exists = db_result(db_query('SELECT nid FROM {scheduler} WHERE nid = %d', $node->nid));
          
        //if this node has already been scheduled, update its record
        if ($exists) {
          //only update database if we need to (un)publish this node at some date
          //otherwise the user probably cleared out the (un)publish dates so we should remove the record
          if ($node->publish_on != NULL || $node->unpublish_on != NULL) {
            db_query('UPDATE {scheduler} SET publish_on = %d, unpublish_on = %d, timezone = %d WHERE nid = %d', $node->publish_on, $node->unpublish_on, $node->timezone, $node->nid);
          }
          else {
            db_query('DELETE FROM {scheduler} WHERE nid = %d', $node->nid);
          }
        }
        //node doesn't exist, create a record only if the (un)publish fields are blank
        else if ($node->publish_on != NULL || $node->unpublish_on != NULL) {
          db_query('INSERT INTO {scheduler} (nid, publish_on, unpublish_on, timezone) VALUES (%d, %d, %d, %d)', $node->nid, $node->publish_on, $node->unpublish_on, $node->timezone);
        }
        break;
  
      case 'delete':
        db_query('DELETE FROM {scheduler} WHERE nid = %d', $node->nid);
        break;
    }
  }
}

So basically it seems that the scheduler module works in a routine to the node load and node save routines which re-freshes the values- fine if you are genuinely saving the node as you will be inputting the data, not so good if you are re-saving and can't input data.

Anyway all this leads me to the simplest work-around/solution which is before you run the batch re-compute code just disable the module in admin>modules options and then re-enable it after you have run the batch re-compute code. This will be fine if the batch re-compute is a once a week/blue moon thing but if you're doing it regularly it might become a drag.

In this case I'm sure it's possible to add in two lines of code one before the query starts which disables the module and one at the end which enables it. Another disclaimer: I don't have any experience with drupal 5 but I understand it is possible to totally unistall modules (i.e delete the stuff in the database) you really don't want to do that!! Take the normal precautions if experiement with this and back up your database or use a test site.

So try manually disabling and enabling the module before and after and if that works perhaps somebody could suggest some code which does it manually or I could have a look for some code (no idea of hand how to do it).

Hope this helps,

Neil

oops

could suggest some code which does it manually or I could have a look for some code (no idea of hand how to do it).

I meant automatically!

So I was hunting around in 4.7 code finding no easy answers only to look at the Drupal 5 code and see that it is rather straight forward as both module_disable and module_enable functions exist. So the new code should look like this:

<?php
//NEW: this part disables the scheduler module (drupal 5.x only!)
module_disable('scheduler.module');


// This query is used to load all the nids of a specific content type into an array. Change `node_content_profile' to the name of the content type.
$query = 'SELECT nid
FROM content_type_deals';

// Create an array to store the query info
$profilenidarray = array();

//exectue the query using db abstraction stuff
$profilenidarray = db_query($query);

// For each nid this will load and then save the node
while ($nodeID = db_fetch_array($profilenidarray)){

//This time limit is important, if it is removed the query will exceed the 30sec limit.
set_time_limit(5);

$PNID = node_load($nodeID["nid"]);
node_save($PNID);

}

//NEW: this part re-enables the scheduler module (drupal 5.x only!)
module_enable('scheduler.module');

// Just so you know its done!
echo 'done';
?>

As I don't have access to drupal 5 nor the scheduler module I can't test it. There are 2 things that might need tweaking:
1) the name of the module might be 'scheduler' without '.module'
2) the module_enable functions want an array, but I'm guessing just giving one name will be ok. You mighty need something like:

//NEW: this part re-enables the scheduler module (drupal 5.x only!)

$module_to_enable = array('scheduler.module');
module_enable('$module_to_enable');

So this is a good automatic work around but not necessarily the most elegant solution. It would probably be better to call node_load and node_save as they are in the core without any hooks. But I have no idea how to do this.

good luck,
Neil