header photo

via positiva

Further WordPress experimentation

Internet-centuries ago I said that I would be migrating my blog to Wordpress. Coincidentally (cough cough) I wrote the post on April 1st; the result was a great deal of laughter and elbowing about the good joke.

I actually was serious at the time, though -- time being the operative word. For better or worse, personal blogging isn't really the best match for Drupal's flexibility. And the streamlined administration UI that Wordpress brings to the table is tweaked and polished specifically for blogging. Drupal's, in contrast, is a one-size-fits-all CMS backend that often requires customization when it's deployed for clients.

I, of course, am just me -- not a client. And taking the time to refine and tweak the administrative tools that Drupal brings to the table, just so posting on my blog feels a bit smoother, is a tough thing to justify when I'm already swimming in hobbies and side projects. I've worked with Wordpress in the past and -- from an end user's perspective -- I'm impressed. One of my short-lived sideblogs, The Process Liberation Front, took 15 minutes to set up and works (worked?) nicely.

I've continued tinkering with Wordpress since then, porting my wife's blog Restless Violet to it, customizing a nice theme, installing extensions, and so on. I'm simultaneously pleasantly surprised by the smooth experience and absolutely horrified at the quality of the code and architecture. Wordpress is big on 'throw some PHP scripts at the problem and hope for the best,' and in areas where Drupal has evolved more robust (albeit more complex) solutions, it's like going from a BMW to a scooter. The number of popular, highly-rated plugins I installed that instructed me to go in and hack core Wordpress files frightened me, and themes do the bulk of the real work on the site.

Inspecting the source for one of the admin pages, I found PHP and HTML jumbled together and hundreds of lines of switch statements wrapped around raw $_POST data. Standard practice for oldschool PHP scripts, sure. But coming from a Drupal background it was like asking your doctor for a prescription and getting a bottle full of leeches. Later, I was horrified to find a page where I could edit the raw PHP code of arbitrary theme files. I'd locked permissions on my server down, though, so it didn't work -- the admin page helpfully suggested that I make the directory world-writable. In Drupal, that kind of trick is considered slightly less safe than juggling chainsaws while shooting heroin into your eyes.

That said, I was able to roll out a tweaked, customized theme and a new blog in a couple of evenings. The experience reminded me a lot of the old days of throwing together scripts and tinkering with a hand-rolled site or a message board. It's terrifying from a process and long term maintenance standpoint, but, you know... does every site I throw together really need its own source control repository, deploy scripts, and a rigorous separation between logic and presentation?

More recently I've been working with Wordpress MU, the multi-user version of Wordpress that allows a single, central site to spin off smaller blogs for each user who registers. It's an interesting model, and in theory it could be used to build something like Wordpress.com, where users arrive at the site, create their account, and start blogging in their own private workspace. In Drupal terms, it's a bit like Adrian's Ægir project: from a central site you can create new sites. It falls down in a lot of other areas, though: all sites are jammed into a single central database, there's no way to allow only a few sites access to certain themes or plugins, and many plugins encounter oddball problems in the 'MU' environment even though they work fine on a single-user copy of Wordpress. In addition, the hack-some-PHP-to-customize-your-site ethic that rules in the WP community breaks down on a multi-user installation: if you hack the PHP code, you're hacking it for all of the sites, not just one.

Those complaints aside, I'm liking it. It lets me spin up a new blog, invite a couple of co-contributors, and let the thing run with minimal fuss. For some of my quick one-off sites, that's all I need -- maybe even more than I need.

So where does that leave this blog? That's complicated. Over time, I've realized that what exists here is not really blogging so much as aggregation. Between Twitter, Delicious, old archives of past sites, and so on, this site is more "Jeff Portal" than "Jeff Blog," and my ideas for it take it even further. I'd like to stop writing book reviews here and post them on GoodReads, where many of my bookish buddies hang out. I'd like to pull in my Last.FM tracks as a playlist, turn the "Links Sideblog" into something more permanent, and pull in posts I write in other places around the net, like the Lullabot.com site.

While I like Wordpress for the blogging, doing that kind of stuff in it is about as complicated as setting up all the necessary custom modules in Drupal. over the long term, I think I may be migrating my actual writing to Wordpress, but continuing to work with Drupal as a way to pull together lots of disparate content feeds. The quest for a perfect nerd-site continues, I suppose...

last.fm tracks aggregation

I ended up wanting something similar, thus my site-of-randomness, aka solecist.net, where I aggregate lots of random things I'm doing on other sites.

One you might like; Joe Lazarus created a yahoo pipe that does one thing -- creates a weekly top-artists chart for a single user on last.fm. Directions for it are here: http://joelaz.com/post/23488847/last-fm-tumblr-weekly-top-artists

How else would my friends know I gave Jeff Buckley's "Grace" an obsessive listen last week? :)

hey there

I have some thoughts about your reflections of the WP system. I too deal with WP and Drupal on a regular basis and find them both to have great similarities and differences that make one more useful than the other depending on the project requirements.

I have one comment and one thought to share with you regarding your comment about plug-ins that ask you to hack core;

1. You should never hack the core, I would like to know what plug-ins you used that asked you to do so. I have yet to come across one that requires me to do little more than activate and configure. You make it sound as though this were a common practice in WP and I really disagree with that thought. Of course everyones experience may be different.

2. The one strength that I can safely point out that comes with the WP framework is Theme domination. There is a tendency for modules in Drupal to ignore styles in your theme. There is also a great amount of unnecessary html being injected into the output in Drupal that can create little headaches through the theming process. I found that the theme layer of WP to have greater control over output and to be cleaner in terms of mark up.

Outside of these observation, I love your article.

Cheers!

Zach, thanks for your

Zach, thanks for your reply!

I'll have to go back to the list of extensions I ended up deploying for my wife's blog -- the one that stands out in my memory was one that allowed her to re-order the links in her linkroll. It was rated 4.5-5, was pretty polished, and had lots of downloads. When I copied it over and activated it, it altered the WP tables that stored links by adding an extra column, and altered one of the core files by adding an extra 'elseif' statement to the widget display code.

A number of other plugins came with PHP snippets and instructed me to copy and paste them into the themes I was using -- in one case, breaking the layout of the theme. None of that is show-stopper stuff (well, aside from the auto-hacking of the core file), but it's absolutely positively beyond the pale in Drupal-terms.

In the interest of fairness, there are many many Wordpress plugins I've used that don't do that stuff. It just stood out to me that those things would be unacceptable in the Drupal module community.

Regarding themes, yeah -- there really are some fundamental differences between the two systems that take adjusting to. Drupal's model is push -- modules and core build data and 'push' it through the theming system. There's no way to make a single 'page template' that just controls every bit of HTML on the page, since so much is built in smaller pieces across different parts of the system -- Themes can override default HTML templates for every little bit of HTML, but it requires explicitly overriding each template. Wordpress' model is pull -- a theme 'pulls' data out of the database (or from functions exposed by installed plugins) and wraps it.

You mention Drupal modules 'ignoring' theme styles -- that's mostly because modules have no way to discover what styles a theme provides. Instead, their job is to provide 'default' HTML markup and CSS that can work with any theme, then provide templates that theme designers can use to customize the aforementioned CSS and HTML if it doesn't work for them.

In the Wordpress world, I'm not sure how a plugin would 'take advantage' of styles a theme provides. Wouldn't it instead be a case of a theme developer writing custom PHP code in the theme to pull data from the plugin, then wrap it in the HTML they want?

Pingback

[...] wait anymore and start promoting some of our t&#104&#101&#109es on your blogs. Further WordPress experimentat&#105&#111&#110 – jeff.viapositiva.net 07/30/2009 Internet-centuries ago I said&#32&#116&#104at I would be [...]

Pingback

[...] wait anymore and start promoting some of our t&#104&#101&#109es on your blogs. Further WordPress experimentat&#105&#111&#110 – jeff.viapositiva.net 07/30/2009 Internet-centuries ago I said&#32&#116&#104at I would be [...]

Simple Content Management

As a WordPress contributor I found distracting a couple of the statements you made from your otherwise excellent essay.

Like Zach, I'd be very interested in the names of the plugins that required modifying core. If the number is one, that would read quite different than "the number of popular, highly-rated plugins I installed that instructed me to go in and hack core ". Though, one is too many as well.

I think I know what you mean by "all sites are jammed into a single central database, there's no way to allow only a few sites access to certain themes or plugins", but an individual blog is stored in it's own database, with shared login, and site wide settings. Which generally is a good mix of trade offs, I think. The problem you raise should be easy to come up with an elegant solution for, and enabling individually is already there.

In terms of maintenance, the simplicity of the code and data structures makes for easy maintenance of simple content and relationships.

It is accessible to pick up coding or theming WordPress and I've always found "jumbled" to be easier to debug than OO without the aid of an IDE.

Really enjoyed your article! Great food for thought. I think we're mostly on the same page that WordPress is great for simple content management (sCMS) , which seems to match 80-90% of use cases.

Themes vs. 'Core'

Lloyd, thanks for the post. I thin that part of my confusion/concern comes from the WP community's heavy reliance on editing the PHP of themes to add functionality. It's a concept that is really foreign to a seasoned Drupal dev, and reminds me of my old days with Movable Type. In the case of my wife's blog, I started off with the default theme and was planning on tweaking plugins before selecting a theme. To get a large number of them working, though, I had to insert function calls and other snippets of PHP into the default theme's code -- which, unless I misunderstand, is hacking Wordpress? I gave up on that approach and downloaded a custom theme, then hacked it, but it really cemented the idea that there is no such thing as a 'stock' theme in Wordpress -- it's almost always going to be hacked up...

The plugin in question that altered Wordpress's default tables and attempted to rewrite one of the core .php files was My Link Order. At the time, it was listed as one of the top plugins on wordpress.org/extend and had a 5 out of 5 rating.

Agreed about the 80% case -- Wordpress nails single-user blogging, and has recently improved quite a bit for multi-user blogging as well. (Most of the available themes are optimized for the single-user presentation, but that's to be expected.)

It is accessible to pick up coding or theming WordPress and I've always found "jumbled" to be easier to debug than OO without the aid of an IDE.

Yeah, definitely -- I think that's what I was getting at when I was talking about the 'olden days' of mucking with PHP scripts and so on. I've said many times that the learning curve for Drupal theming doesn't have anything to do with 'knowing PHP' -- the average Drupal theme requires quite a bit less PHP than a Wordpress theme. The difference is in the complexity of the mental models that Drupal and Wordpress bring to the table.

Drupal can do some things to improve that, but ultimately I think it's just a consequence of a more modular architecture and a 'generalist' approach to content. Throwing together galleries/blogs/forums/membership groups is possible without so much as pasting a single snippet of PHP anywhere, and all the modules interact with each other and account for each others' presence, but the actual code model operating under the surface is a lot trickier. It's possible for a theme to completely reshuffle the look and feel of a data entry form provided by a plugin, but themers have to learn relatively complex mechanisms and data structures to get there.

Next on my list is Django, totally on the other side of the spectrum... heh.

Theme Framework

Good points about the default theme.

I think in the next couple of years we'll will see the emergence of a dominant WordPress theme framework which will eventually be bundled. There are a number of them currently emerging and competing with each other.

"Next on my list is Django, totally on the other side of the spectrum"

Would love to be notified when you write that one up.

Pingback

[...] the rest here:  Further WordPress experimentation | via positiva Share and [...]

Pingback

[...] the original: Further WordPress experimentation | via positiva internet [...]

Pingback

[...] more here:  Further WordPress experimentation | via positiva SHARETHIS.addEntry({ title: "Further WordPress experimentation | via positiva", url: [...]

Pingback

[...] posted here: Further WordPress experimentation | via positiva SHARETHIS.addEntry({ title: "Further WordPress experimentation | via positiva", url: [...]

Pingback

[...] from: Further WordPress experimentation | via positiva Share and [...]

Pingback

[...] here to read the rest: Further WordPress experimentation | via positiva Comments0 Leave a Reply Click here to cancel [...]

Pingback

[...] Some views on WP from a Drupal developer: http://jeff.viapositiva.net/archives...xperimentation [...]

Core code hacking

I've installed hundreds of different WordPress plugins. I don't recall any of them ever requiring any code files to be hacked.

Are you sure you aren't confusing WordPress with another CMS? By it's very nature WordPress is designed not to require core code hacking, that's one of the reasons it so popular.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote> <img> <i> <b> <strike> <h3> <h4>
  • Lines and paragraphs break automatically.
  • You may use [inline:xx] tags to display uploaded files or images inline.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Twitter-style @usersnames are linked to their Twitter account pages.
  • Twitter-style #hashtags are linked to search.twitter.com.

More information about formatting options

Miniblog

  • Totally got the third item in that list from @blakehall btw. He's the clever one! 43 min ago
  • There are two hard problems in CompSci: optimal cache invalidation, naming things, and off-by-one errors. 1 hour ago
  • OH: "Well, the Title title can just be the title, but reign_title can't be the reign title, or the title title." 4 hours ago
  • Know Drupal? Dig wrestling? Looks like the WWE is hiring... http://j.mp/bSu4pB 2 days ago
  • I want to be the Malcolm Gladwell of Drupal APIs. My breakout book will be named 'Clear Cache.' 4 days ago

SXSW Interactive 2011!