The drop is always movingYou know that saying about standing on the shoulders of giants? Drupal is standing on a huge pile of midgetsAll content management systems suck, Drupal just happens to suck less.Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]Drupal makes sandwiches happen.There is a module for that

On Drupal 7 modules

Submitted by nk on Mon, 2010-09-20 08:54

Drupal 6 modules typically defined their own tables, had their own code to maintain them and then used nodeapi to hook into the system. Or, defined node types but still maintained their own tables. In Drupal 7 instead you should just create fields, instance them on node types you want to work with. Instead of altering a form directly you can write a widget. Display your data with a formatter. Don't worry about data storage, field API handles that for you. And then there is the EntityFieldQuery class to help with finding things. For example, scheduler should use a field instead of its own table and then use EntityFieldQuery in cron to find the unpublished nodes which needs publishing:

= new EntityFieldQuery;
// This is not actual code from scheduler module.
$result = $query
->entityCondition('entity_type', 'node')
propertyCondition('status', 0)
fieldCondition('scheduler', 'value', REQUEST_TIME, '<')
if (!empty(
$result['node'])) {
// $result['node'] keys are nids, values are stub entities.
$nodes = entity_load('node', array_keys($result['node']));
  foreach (
$nodes as $node) {
$node->status = 1;

Note that updating the node table directly would skip all the hooks (and there are quite a few) that would allow modules to react to this change so please don't do that. In general, if you write a SQL query in Drupal 7, think twice whether it can be done with an API instead and use that instead.

Also note that entity bulk updates are not solved well in Drupal 7, if you have a lot of entities such a loop would take quite some time. This likely will be a contrib module and a whole another article :)

Update: to clarify, although I used node as an example in this post, this is also equally true to any entity type, comments, users, taxonomy terms etc. I did use entity_load instead of node_load_multiple however, to show how the querying part is not node specific at all.

Commenting on this Story is closed.

Submitted by Anonymous (not verified) on Mon, 2010-09-20 21:58.

There are modules that don't use nodes as their base entity type, you know.

Submitted by nk on Mon, 2010-09-20 22:32.

Indeed, nowhere is this node specific. Sorry for writing the word node in the article, but it indeed works equally well with any entity type. But then I have compared to Drupal 6 where people strived to make everything into a node. EntityFieldQuery can even run queries that do not an entity type specified.