monline

Let's assume you want to mass-update a set of nodes or create a new revision for each of them. You could do this through the UI, but of course for hundreds (or thousands) of nodes this is not really an option. You can do this programatically with a small PHP script.

First of all, you should have some means of running your own PHP code inside your Drupal environment. There're a number of ways for doing this (eg. you can create a page with an input format that has the PHP filter enabled and execute your code simply by viewing your page node), but the Devel module has already this feature and is usable for our purpose. Install this module and add the "Execute PHP" block to one of your site regions (eg. to the left sidebar under the navigation, if you're using the default Garland theme).

Now for the code. It's really simple. We've to fetch a list of the nodes to be modified, load the node, modify it's values and save it. The loading is done with node_load(), the saving with node_save(). The latter is a bit tricky though.

You can create a new revision of a node by loading the node, setting the revision attribute in the node object to TRUE and calling node_save(). However this procedure overwrites the uid of the last revision of the node with the one of the current user (that you're logged on with, when you execute this code). In case you're creating a new revision, then the uid of the new revision will be set as the current user. Since you're mass updating nodes, this is probably not what you want. node_save() sets the uid of the new revision to the current user's uid, so we can change that (eg. to the uid of the last revision of the node) and trick node_save().

Another problem with updating nodes with node_save() is that the changed (time of last modification) field of the node and the timestamp field of the revision is updated and there's no workaround for this. The only thing you can do is to save these values and update them manually afterwards with a direct SQL update. There's no other way around this.

Now here comes an example that will create a new revision for each story node in your system and the author of the new revision will be the author of the last revision of the node (or the initial author of the node if there're no revisions yet):


This works if you run it with the Drupal superuser (the one with uid=1), but might fail if you run it with any other user. I'm not sure whether node_save does any access permission tests or not (I didn't see any, but that means nothing). Another solution to the problem could be not to mess with the $user->uid, but simply let node_save() create the new revision with whatever uid it wants to and do an UPDATE on the node_revisions table afterwards and set the uid directly in the table. This is quite brutal again, but Drupal5 has no API for manipulating individual revisions (not that I'd know of).

And if you ask yourself what might be the purpose of all this, here's one example: computed CCK fields. If you're developer of a Drupal based website and you've added a new computed field to a content type that already has a lot of existing content (nodes), chances are high that you want to have a proper value in the computed field even in your old content. Mass updating nodes (either with creating a new revision or without it) causes the computed fields to be recalculated and saved.

PS: in the example above I've included a call to ini_set() to increase the max_execution_time limit. However (depending on your setup) this might not be the only place where you've to adjust limits to increase the max execution time. Eg. if you're using PHP via FastCGI, you've to increase the CGI wrapper's communication timeout too. The max_execution_time parameter is only interpreted by the PHP engine and the CGI wrapper runs the PHP engine, thus the CGI wrapper's execution timeout must be equal or higher than the PHP max_execution_time setting.