[wp-hackers] WorkFlow in WordPress?
Mike Schinkel
mikeschinkel at newclarity.net
Wed Jul 1 23:18:55 GMT 2009
"Otto" <otto at ottodestruct.com> 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 at mydomain.com" 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
More information about the wp-hackers
mailing list