[wp-hackers] Drupal's "Butler" (was: Loading JS & CSS from inside a plugin)

[Dave Ross]

On Tue, Mar 22, 2011 at 4:15 PM, Mike Schinkel
<mikeschinkel at newclarity.net>wrote:

>
> Sounds interesting.  Could you elaborate?
>
> -Mike


"Butler" is something the Drupal core team is sketching out for Drupal 8.
So, details are pretty thin.

They're trying to consolidate core APIs, modernize the blocks system (their
equivalent of WP's widgets), replace the current plugin system, and
integrate functionality from popular plugins into core. Like a real-life
butler may coordinate the work of the cooks, maids, and other staff in a
home, the Drupal Butler will decide what functionality is invoked and when.

To do this, the Butler needs to be the central source of information on
configuration and context. Configuration is straightforward -- Butler acts
as a repository for config data, like the Windows registry but not broken.
Context is more interesting. Based on the URL, user agent, connection speed,
time of day, lunar cycle, and what the President of the USA had for
breakfast, Butler will figure out the appropriate content, plugins, and
theme it needs to render the output. Notice I said "output" and not "page",
because the Drupal 8 team intends to decouple HTML generation from the rest
of the system. The only thing that should output HTML is the theme, and only
if Butler decides an HTML-generating theme is appropriate.

Drupal 6's architecture was very loosely-coupled. While this is great for
code maintenance, it's led to some inefficiencies. For example, my
understanding is that every block in the system is rendered every time a
page loads, and the theme causes the correct ones to actually be output when
it calls the code to render a block region ("sidebar"). This keeps the
blocks and theme separate, sure, but then they have to use caching at
multiple levels in the system (such as the "block cache") to keep
performance manageable.

Back to WordPress. Before I went the parse_request route for loading
scripts, I was checking for a WP_SUBDOMAINS symbol and trying to make a the
right URL for that case, then doing something different if wp-content was
moved, and so forth. Otto, thanks for the heads-up on plugin_dir_url(). That
might be exactly what I'm looking for, or I see it calls plugins_url() which
is actually documented in the Codex and I somehow missed up 'til now.

When I ask for a WordPress equivalent to Butler, I'm not saying we should
steal their idea outright, but I can definitely see an advantage to
centralizing & standardizing how common plugin tasks are handled. I don't
want to have to think about all the different configurations and plugin
combinations out there. Have my plugin call a method to get the absolute URL
for a file in the plugin's dir at the current site URL (like plugin_dir_url
I guess). If something fails, let it be because WP Subdomains or WPMU didn't
implement Butler's version of the plugins_url filter, not because I didn't
create a special case. It could also standardize the options API, like
they're doing in Drupal, so it's less of a crapshoot whether a plugin uses
separate entries for each setting or one big serialized array. Widget Logic
would be a good candidate for inclusion in a WordPress "Butler", too, so
widgets can be included on a page based on "context".