WorkFlow in WordPress?

[Mike Schinkel-5]

Hi Hackers:

I to bring up a discussion about Workflow in WordPress.  But first  
some background:

I have recently been working on a personal project that needs some  
built in workflow so that several processes can be automated related  
to links. I decided the best way to do that was to use a Link Category  
with non-visible links as a workflow queue and use link metadata to  
store the the current workflow state for each link (which is why I  
started this[1] discussion.)

Today Simon Blackbourn emailed the list [2] about the email address  
and name used in notification messages to which Jennifer Hodgdon  
suggested a configurable option, separate from the "admin" user's  
email address and I agree with that.  Of course adding such an option  
would increase the complexity of an install and thus I would expect  
the community would fight against such an option as if its life  
depended on it.

However what I could see working would be to have a notice in the  
admin section that shows up after initial installation that says "You  
haven't set your blog email address yet. Click here to set it now!"  
That way the email address could default to wordpress@...,  
not require any additional conceptual load on the user during install,  
and be very simple to update after the user gets past being  
overwhelmed by the initial installation (I'm assuming the least  
technical user possible here. :)

Of course that looks so very similar to a workflow system to me  
especially since I've been thinking about exactly the same for my  
existing project.  And as I write this it occurs to me that WordPress  
could benefit from essentially a checklist of "todo" items that could  
be added as notifications upon initial install. And it also occurs to  
me that many plugins could also benefit from the same, i.e. "You just  
installed me, now go set my options!"

Akismet actually currently does this using the "admin_notices" hook  
and this hook could be used by any plugin to generate the types of  
notices I'm mentioning but doing so needs to be implicitly coupled to  
arbitrary data items, such as the Akismet API key in wp_options. But  
this approach isn't formalized and it's not standardized in any way to  
handle workflow so there are no obvious pattern for developers to  
follow in creating workflow and no "economies of scale" where numerous  
coding could be contributing to the same overall system.

So this makes me think it makes sense to introduce a simple workflow  
system into WordPress, possibly first as a plugin, that would create a  
queue for arbitrary workflows that could be defined and used by other  
plugins.  To see if anyone has come before with these concerts I  
googled and found than an Edward Dale of University of North Carolina  
(cc'd on this email) has done some work [3][4][5] in this area along  
with a plugin called Zensor[6] though I didn't see that anyone else is  
really touching on the subject. Looking at Zensor it seems to address  
workflow related to moderation of post contributors and not generic  
workflow in general.

What I have in mind was a generic workflow system, something that  
could handle the Zensor use cases but also a while lot more. Something  
like adding a wp_workflow table to contain a list of in-process  
workflows with fields for id (int), name (varchar), type (varchar),  
state/status (varchar), meta (text, for serialized array) and probably  
a few other fields I haven't thought of yet.  The code would include  
some schedule tasks that process the workflow queue periodically and  
then call hooks to process the workflow queue and move each workflow  
items from state to state as appropriate. It would also include  
various helper functions to streamline the process of using the  
workflow system. By itself this plugin/functionality would do very  
little for end users; it would only be something that other plugins or  
even core could use to implement workflows.

I'm emailing to get your thoughts on this. I'm thinking seriously of  
implementing this since I pretty much need it for my own use but I'd  
like to know what others think about it, if others have previously  
spent any time thinking about this, if others may even already have  
code for it, and if others here think this is something that could  
make it's way into core.

So, thoughts?

-Mike Schinkel
WordPress Custom Plugins
http://mikeschinkel.com/custom-wordpress-plugins/

[1] http://comox.textdrive.com/pipermail/wp-hackers/2009-June/026584.html 
  (Link Metadata)
[2] http://comox.textdrive.com/pipermail/wp-hackers/2009-June/026706.html 
  (Address and name used in notification messages)
[3] http://comox.textdrive.com/pipermail/wp-hackers/2009-March/025470.html 
  (GSoC2009 idea: Workflows/Moderation in WordPress)
[4] http://codex.wordpress.org/User:Scompt/Workflow_With_WordPress
[5] http://scompt.com/archives/2009/03/29/wordpress-gsoc-2009-idea-workflow
[6] http://wordpress.org/extend/plugins/zensor/

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Otto-19]

On Thu, Jun 25, 2009 at 2:15 PM, Mike
Schinkel<mikeschinkel@...> wrote:
> Today Simon Blackbourn emailed the list [2] about the email address and name
> used in notification messages to which Jennifer Hodgdon suggested a
> configurable option, separate from the "admin" user's email address and I
> agree with that.  Of course adding such an option would increase the
> complexity of an install and thus I would expect the community would fight
> against such an option as if its life depended on it.

Actually, I have no problem with that one. Clearly, there's been
problems with WP installs being able to send emails in the past
because of the various from headers and such, making them easily
configurable (either via the admin menus or via filters and plugins)
is a good idea. It has been demonstrated that no one setting works for
everybody, so an option is more or less a requirement at this point.

>  And as I write this it occurs to me that WordPress could benefit from
> essentially a checklist of "todo" items that could be added as notifications
> upon initial install. And it also occurs to me that many plugins could also
> benefit from the same, i.e. "You just installed me, now go set my options!"
>
> Akismet actually currently does this using the "admin_notices" hook and this
> hook could be used by any plugin to generate the types of notices I'm
> mentioning but doing so needs to be implicitly coupled to arbitrary data
> items, such as the Akismet API key in wp_options. But this approach isn't
> formalized and it's not standardized in any way to handle workflow so there
> are no obvious pattern for developers to follow in creating workflow and no
> "economies of scale" where numerous coding could be contributing to the same
> overall system.

I'm not quite understanding why any plugin can't hook in the same way
Akismet does and do more or less the same thing. If some setting is
not set, plugin hooks and displays a "hey, notice me!" thing.

> What I have in mind was a generic workflow system, something that could
> handle the Zensor use cases but also a while lot more. Something like adding
> a wp_workflow table to contain a list of in-process workflows with fields
> for id (int), name (varchar), type (varchar), state/status (varchar), meta
> (text, for serialized array) and probably a few other fields I haven't
> thought of yet.  The code would include some schedule tasks that process the
> workflow queue periodically and then call hooks to process the workflow
> queue and move each workflow items from state to state as appropriate. It
> would also include various helper functions to streamline the process of
> using the workflow system. By itself this plugin/functionality would do very
> little for end users; it would only be something that other plugins or even
> core could use to implement workflows.

I don't quite follow what you mean by "workflows", as such. I'm
opposed to adding a new table specifically for them without some kind
of better explanation as to what you're talking about. Let's try a
question and answer format:

1. What is a workflow?
2. How does it work?
3. What does a row in this table represent?
4. What can a workflow do that you cannot do already with existing
functionality?
5. How could the core benefit from workflows (leaving out what plugins
can do entirely)?

Generally speaking, I've noticed "generalized" type of things tend to
make it into core when they can specifically improve the core itself,
and then they become available for plugins. Very rarely do you see
things get in so that plugins can use them. Example: SimplePie
recently replaced MagpieRSS in the core. Why? Because the new
dashboard makes a lot more extensive use of feeds, and Magpie didn't
cut the mustard anymore. This despite that fact that many people have
been wanting SimplePie in for a couple years now, so that they would
have a decent RSS parser in there to use.


-Otto
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Mike Schinkel-5]

"Otto" <otto@...> wrote:
> Actually, I have no problem with that one.

If "the powers that be" think it makes sense to add it, I've no argument.

> I'm not quite understanding why any plugin can't hook in
> the same way Akismet does and do more or less the same
> thing. If some setting is not set, plugin hooks and displays
> a "hey, notice me!" thing.

Certainly a plugin can, the difference I was suggesting would be to have standardized infrastructure to do it much like there is standardized infrastructure for categories so that any plugins needing workflow could do in a standardized way rather than arbitrarily different ways.

BTW, scan or read my entire email before commenting to first see my closing comments.

> I don't quite follow what you mean by "workflows", as such.
> 1. What is a workflow?

A workflow is a mapping of states and transitions, some potentially automated and some potentially manual that collectively are used to manage a process.

These might help:

  http://en.wikipedia.org/wiki/Workflow
  http://drupal.org/project/workflow
  http://www.theserverside.com/tt/articles/article.tss?l=Workflow

> 2. How does it work?
> 3. What does a row in this table represent?

The table I proposed would be used to store workflow "states" such as "Post Awaiting Review by Moderator" or "Product Submitted awaiting Review."  This might help you understanding workflow states:

  http://www.odetocode.com/articles/460.aspx

Then a scheduled task would monitor workflow in the background and run plugin code that has hooked the workflow system to move workflow items from one state to the next.

> 4. What can a workflow do that you cannot do already with existing functionality?

Let me answer by asking a rhetorical question: Is there anything a plugin can do that a theme could not do? Not really, so why did we need plugins when we could just do them in themes?  Clearly the plugin concept *standardizes* an approach to extensions so that functionality need not be copied into themes.

A standardized approach to workflow would mean collaboration among developers on a common workflow system. It could create a platform whereby end users could add and/or modify workflow just like end users currently and plugins. The reason to argue for a standard workflow system is the same reason anyone argues for any standard; compatibility and ubiquity.  

> 5. How could the core benefit from workflows (leaving out
what plugins can do entirely)?

One example would be the item I already mentioned; to notify the user they need to update "wordpress@..." after installation.  Another could be to set up rules moderating posts and comments allowing people with different roles to moderate differently.  Another could be to establish a process for publishing posts for a big blog: writer writes, editor reviews, categorizer categorizes, photo editor adds photos, etc.  

All of these examples could allow the admin to control any workflow based on business needs using admin console functionality and w/o programming (assuming the only state transitions that are needed are available in core or via plugins.)

> Generally speaking, I've noticed "generalized" type of things
> tend to make it into core when they can specifically improve
> the core itself, and then they become available for plugins.

100% agreed with that. This workflow could easily be done in a plugin w/o the need to be part of core. My only reason for mentioning core is I think it could significantly benefit core as a standard component of functionality.

THAT said, given the admin email vs. the blog email isn't an urgency demanding workflow, I can easily build it as a plugin for my own needs and over time, if and only if it proves to be a useful addition to the core it can be added to core.  

-Mike Schinkel
Custom Wordpress Plugins
http://mikeschinkel.com/custom-wordpress-plugins
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers