Today I released the Node Reminder module.  The Node Reminder module was based upon the code for the Post Reminder module.

The idea behind the Node Reminder module is to have a very simple way to remind you to look at a particular node to update the content.  An example use case would include licensing issues where you may have rights to use an image for only one year.  Setting the reminder for 11 months gives you time to either delete the post or update the image.

Features
• Allow Reminders per content type.
• Template for email Subject and Body with Tokens integration.
• Views integration.
• Actions integration.

You can make an administration page using Views Bulk Operations.

Since getting started with Drupal over two years ago, the sites I’ve built with it have naturally gotten bigger and bigger in scope. As your sites get bigger and bigger, you always look for ways to keep your site running as smoothly as possible, and this usually ends up meaning getting rid of queries wherever you can.

One feature of Views which is often used by module developers is the ability of a module to expose a set of default views. The calendar module, for example, provides a default calendar view in both its Drupal 5 and 6 versions. This is an obvious asset for developers of contributed modules: if your module interfaces with Views, it makes sense to provide a default view that users can modify.

Implementation and Potential Benefits

The hook used to do this is hook_views_default_views(). Since most modern sites are run off of a number of Views, you can also realize several benefits by building your sites with a custom module that implements hook_views_default_views():

1. It improves performance. Views implemented via hook_views_default_views() do not require a database query to instantiate. You will realize an even greater performance gain if you also use an opcode caching system such as APC or XCache.
2. Providing views in code will allow you to override the default view to make changes, and you can then choose to keep the changes in the database, update the module file to reflect the changes, or revert back to the version in your module file.
3. Because the view (and theoretically, changes to that view) are stored in files, you can put them in version control and see how the views used in your site change over time and revert to an earlier version without having to go to a database backup.

Introduction

The Need

Our clients and other Drupal site administrators would like to use the Workflow module to schedule transition states in their publishing workflow.

The Problem

Currently, within the Workflow module a node cannot be assigned a scheduled state change upon node creation. A node must be saved first, then edited a second time by the user.

After reading this comment in the Workflow module issue queue: http://drupal.org/node/189572#comment-704334 I decided to try to add a little more automation to the process of creating a node and adding a scheduled state change.

In this Post

You'll learn how to create a publishing workflow for your website, and how to improve the process of scheduling a transition change during node creation.

Let's begin.

Note: This demonstration is build on Drupal 6. The process outlined below may be adapted for Drupal 5 install.