[wp-hackers] WorkFlow in WordPress?

[Otto]

On Thu, Jun 25, 2009 at 2:15 PM, Mike
Schinkel<mikeschinkel at newclarity.net> 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