Introduction

Some of these ideas are taken from a page I started on the WordPress Codex to mull over workflow ideas.

WordPress is built to cater to the single user running a personal blog up to the global company running an entire website. In the big cases such as the latter, some controls and processes need to be in place to restrict what users can do and to assure that certain events take place in the correct order. Collectively, I’ll call these controls and processes a workflow and they’re the heart of the project I’d like to do for Google Summer of Code.

Wikipedia defines a workflow as:

A workflow is a reliably repeatable pattern of activity enabled by a systematic organization of resources, defined roles and mass, energy and information flows, into a work process that can be documented and learned.

This definition can be trimmed and refined a bit to better suit its application to WordPress, yielding:

A workflow is a reliably repeatable pattern of activity enabled by a systematic organization of resources, defined roles, and information flows, into a work process that can be documented and learned.

Use Cases

• category editors – to be published in a category, a post/page must be approved by an editor for that category
• writer->editor->designer – the writer writes text, which is edited by the editor, and then made pretty by the designer
• the big boss – everything that gets published must get the ok of the boss

System Design

I envision the workflow system being implemented as a plugin. I don’t think the number of people needing workflow controls justify putting it in the core. I do, however, think there is a critical mass of sites that would benefit from the plugin.

My initial thinking about the plugin leads to three main components: design, notification, and moderation.

Design

Under ‘design’, I categorize the definition of the workflow. This would be a ‘Settings’ page and would utilize some kind of GUI to create a funnel-like representation of the workflow. Posts/pages enter the system at the wide end of the funnel, go through a number of workflow stages, and emerge published at the other end. Designing the workflow would consist of creating vertices and edges in this tree. Vertices are moderation checkpoints that must be passed in order to move towards the root (publication). Edges are the path that documents travel along.

Another facet of the workflow design is assigning users to the vertices. A user at a vertex is the gatekeeper (moderator) of that stage, allowing documents to pass unscathed, modifying them, and/or sending them back to the previous stage. Here, I picture a drag/drop interface to assign users to vertices. Multiple users can occupy a vertex, as can one user occupy multiple vertices.

Notification

Notification is simply the idea that a user be notified when a document reaches his/her stage. This would naturally occur when a document has passed from the previous stage, but also when a document has been turned back from the next stage. Some options would be useful here to prevent a user from getting swamped with notification emails. For example, only notify a user once between logins or at most once per day.

Moderation

This is really the heart of the plugin. In order to pass through a stage, a moderator for that stage has to approve a document. The moderator can optionally modify the document before approving it. Once approved, a document either moves to the next stage or is published. A rejected document is sent back to the previous stage. Comments can be attached to the document to provide a justification for the decision.

Implementation

The design component will be implemented as a settings page that allows the user to graphically design the workflow. When saved, the workflow will be captured as a tree structure and written to the options table.

Each stage of the workflow will have a shortname (think post slug). This short name will be used to call an action when a post {enters, exits, …} that stage. For example, the action ‘workflow_editor_entered’ would be called with the post/page id when an author submits a document to the editor stage. Default action handlers would be included that would email the users in that stage. This is the notification component. These default action handlers could be disabled if a user wanted to just notice the waiting posts, or a different action handler that twittered or SMSed a user.

Forcing posts to go through the workflow would be largely accomplished with the current capabilities system. Many of the capabilities are meta-capabilities and are also sent through a user_has_cap filter before being processed. The plugin would add a handler to this filter that looked up in the workflow to see if that action was allowed. For example, in the case of an author X working on post 100 in the editing stage, the filter would receive the values (X, 100, editing). The plugin would determine if the user is able to pass posts through that stage.

There are a couple open questions about the implementation. If a published document is edited, where does it enter the workflow pipeline? Is the published version un-published? How does the revision control introduced in WP 2.6 play factor in?

Existing Functionality

WordPress introduced the concept of a ‘pending review’ state in version 2.3. This was a big step towards providing a workflow system, but it doesn’t go far enough. Indeed, it only covers the last use case above. In that case, the ‘big boss’ would need to be the only user with permission to publish. All other users would be able to create posts/pages and submit them for review. This only provides the moderation component of the design. There’s no built-in mechanism to notify the boss that a post is waiting for review. The only way to design the workflow is to designate the boss as having the publishing capability. There’s no further way to design such a trivial workflow.

The pending state doesn’t provide a workflow, but it makes it much easier to implement a full workflow system. Basically, the entire workflow exists inside of the pending state. When the original author thinks that a document is ready to be published, it is submitted for review, at which point it enters the workflow system and is given the pending state. The editors at that first level of the workflow are notified that a document is waiting for them. An editor makes any necessary changes and passes the document through to the next stage in the workflow. It is still in the pending state at this point. Until the document reaches the root of the workflow and is green-lighted to be published, it’s in the pending state.

When Mark Jaquith posted about the new pending state in June 2006, he wrote that “There are obviously a lot more ‘editorial process’ types of features that we could implement”. In addition, the comments on that post requested many of the features that this GSoC project would provide.

Previous Work

I’ve previously implemented a much simpler 1-stage workflow in a plugin called Zensor. It hasn’t been updated in quite a while due to external time constraints. This work was done for a high school in Germany where all changes to the website needed to be approved by the headmaster.

Public Comment

I solicited comments for this idea on the wp-hackers mailing list, but didn’t receive too much feedback. Maybe more comments will appear below.

Updates

4/10/2009: I added the Existing Functionality section and expanded on the Implementation details in response to comments from Jane Wells on the GSoC site.

I don’t think this has enough information. There is a review process built into WP core already… what actual functions are you proposing to built, how will they differ from current functions, and how will you approach it technically? Those are the questions that the application needs to answer.