Of Drupal, Movable Type, templates and themes.

Background

Drupal is available at drupal.org. It is a modular PHP-based CMS.

I have been evaluating Drupal as a viable alternative for the site-specific custom CMS curently
running on Cambridge University's Amateur Dramatic Club web site. The
purpose of this document is to try to assess what Drupal does badly, especially when compared to Movable
Type. This document will not praise parts of Drupal that are excellent (and much of it is), it will only
concern itself with areas for improvement. If a feature it not mentioned, that doesn't mean it's perfect,
it simply means that it doesn't stand out.

This document may be updated at a later date to include PHP-nuke or similar CMS systems.

I have several years' experience writing PHP, but will be attempting to look at Drupal from various
perspectives, not just that of a programmer.

---

Key differences between Drupal and MT

To understand the differences in usability, it is helpful to contrast the two systems' architecture. MT uses Perl to generate
static pages. Drupal uses PHP and a SQL database to dynamically generate them. This makes MT very fast for serving content as
most client hits are for static pages (except comment view/submit, search, TrackBack).

Drupal and MT have utterly different templating/theme engines. This will be explored later.

Look and feel of the admin interface

When you log in to Movable Type, a very pretty and coherent admin interface is presented. All manipulation of entries is done from
here. This makes sense to the user. The admin interface isn't very well layed out. For example, it's not obvious what the "menu" button
does until you've used it once (it takes to you the top-level site admin page).

Simply adding some graphics and styles to the Drupal admin interface would go a long way towards improving the feeling of quality
for the average user. Although the architecture underneath is nice, the current admin interface doesn't look very polished
graphically. A Drupal logo and suchlike would be good.

Drupal in many ways has superior editing capabilities to MT. It's closer to providing an edit-in-place type system, which is
good, especially for beginners. Being able to simply click the "edit" link at the bottom of a post is a big plus.

Adding non-text content - uploading files/images

MT has a very simple file-upload dialog, where you can upload files to either the archives directory or the root MT site directory.
If you upload an image, it then asks you if you want to create a new entry using the uploaded image, with it being either a popup
or embedded. It then inserts the appropriate HTML into the textbox on a New Entry form.

Drupal lacks out-of-the-box file upload capability. This is a major stumbling block.

Theming

I'm a serious CSS advocate when it comes to basic changes in layout markup. CSS support is currrently rather ropey (Mozilla being
one of few shining examples of Doing It Nearly Right). Internet Explorer 6 isn't too bad, but 4 & 5 are so ropey they're worse
than hopeless, with 5.5 somewhere in the middle. Netscape 4 is also very very poor.

Having said all that, CSS is the way of the future - I can't see many sites still using tables in a year or two's time, so there's no
point trying to build a system now that when perfected will be out of date. If the Drupal developers are careful, they'll be ideally
placed to take advantage of the CSS revolution...

At the end of the day, MT and Drupal both spit out HTML, and can therefore both be themed with CSS. Of course, it's not quite that
simple, as for it to work properly, all the plugins, etc. must also talk CSS. For it to be easy to work out what is going on for the
theme developer, some degree of hierarchy and structure in the CSS is also required. Both MT and Drupal are currently lacking this -
it's not very well thought out in either. Drupal would benefit from more structured and consistent CSS output. I shall be working
on this soon.

Once you've changed the CSS, you run into a wall with both systems - you need to learn how to template/theme them. This is a
non-trivial step to take in both.

Before you do anything else, read this article:
[http://phppatterns.com/index.php/article/view/4/1/1].
It gives a very useful perspective on template engines. I pretty much agree with everything it says.

MT has a set of strictly defined and well-documented tags for template markup. It's very extensive, but this also means that it
has quite a steep learning curve. Now, this is fine if you don't already know PHP or Perl. But if you do, you find yourself wanting to
write PHP code in your templates. This is difficult for me to assess without bias as a long-term PHP developer, but MT's template system
isn't used anywhere else, and I'm not convinced that it's more powerful or easier to learn than simply writing PHP code. Hmmmm.

Drupal takes the "if you want to really customise your themes, you must learn PHP" route. IMHO, this isn't a bad thing. This also
allows you to subset themes - you can make a theme that provides output to your favorite templating engine and then use that for
markup. If you have much complicated HTML in your theme, you're probably not using CSS and should consider it. OTOH, there are some
sites that have complex HTML, and that could do with coming out of Drupal's .theme files. The XTemplate theme by Axel is a good example
of a way of doing this. However, you can achieve similar results with PHP's include() and eval() functions, although no one seems to have
produced a theme that does this yet. This (to a certain extent) allows you to edit pages in DreamWeaver, should you so wish. Not that
I'd countenance such a thing.

There's an excellent rant halfway down this article
[http://www.sitepointforums.com/showthread.php?s=&threadid=67849]
about templating and how to use PHP to do this properly, rather than using Smarty or similar. Read it an learn.

My key point here is that if you actually separate the HTML from the PHP by using PHP's include statements, and get your web designers to edit files that look like this...

<html>
<head>
<title><?= $title ?></title>
</head>
<body>
<h1><?= $title ?></h1>
</body>
</html>

...it's no more difficult to write templates in native PHP that it is in Smarty or whatever. It's a good deal easier for people
who know PHP, too, which is quite a large part of Drupal's audience. Yes, we want people who have professional web designers working
for them to be able to edit things, but we also want it to be easy and accessible for people who write, design and run the whole
of a web site by themselves (small company, personal sites, etc.). It's also quicker. People praise Smarty for "compiling" its templates
to PHP code. Why not just write it in PHP to start with?

So, the basic problem is two-fold.

1. Drupal hides some of the logic from you. It provides default output, and you have to override it with the theme()/theme_invoke()
   function. With MT, some of this can be accomplished in tags (things like sort order for lists of entries).
2. Drupal doesn't enforce a templated architecture to the same degree that MT does. Guidelines could be written, which would
   help. Certainly an example theme which had not just one PHP file, but several that were include()ed (foo.theme, foo.theme.box,
   foo.theme.header, foo.theme.node, etc.) would go a long way towards making this nicer. Some good docs for that theme explaining
   how to customise it/the include files would also be great.

Note that Drupal has plugin modules that provide abstract data types. MT only has the concept of an entry. Drupal has nodes, which can
have different types (book page, blog, image, etc.) which result in very different display. There is a tradeoff between providing
sensible default formatting in the module code which passes a chunk of HTML to the theme, and providing the theme with the raw data and
requiring it to do the formatting. This makes themes more flexible, but also makes them more complicated. One also wants to reduce the
duplication of code between themes.

For example, Michael Angeles pointed out to me/Dries that MT less you sort things in a template. Drupal doesn't let you do this - it
displays entries in reverse chronological order. Now, the main reason for the difference here is in implementation - Drupal has a push
model for themes - you generate content for a box and then push it at the theme for rendering. MT has a pull model - the theme asks for
five items sorted alphanumerically. I'm not sure how to resolve this. It would seem sensible to insert sorting code in the node module, so
that you could request stuff sorted alphanumerically. Drupal has a concept of display "weight" for various items (blocks, taxonomies,
taxonomy terms, etc.). However, I don't think it's appropriate to provide weights for nodes, as you don't want to have to go through
and assign them all individually just to get alphanumerical ordering. Perhaps you could associate the node with a particular taxonomy that
specified sort order? It would be difficult then to go "sort by alpha DESC, then by date ASC", though. Hmmmm...

Pull vs. Push, implications, Drupal design suggestions.

I think most of the things that MT users find difficult in Drupal result from two things:

1. Pull vs. Push
2. MT users come to Drupal with a pull-mindset - they would like to see Drupal's themes as analogous to MT's templates,
   when in reality they're completely different.
   Although both allow you to specify what the site should look like (colour, position, layout, etc.) MT's templates don't
   just define the *style*, they actually define which *content* is displayed.

Part of this is down to the different way in which Drupal themes and MT templates are used. MT uses CSS to change the visual layout
of a template. This is now the official MT way, according to their web site. We can, of course, do similar things with Drupal (especially
once the CSS stuff in the modules has been sorted out a bit more). Standard Drupal themes should be seen as an extension of this, rather
than as an MT-template equivalent. Most web sites only have one MT template, which pretty much defines how the site works, what
content is displayed, and how that content is rendered (with HTML markup, probably linked to CSS styles).

But what does all this mean? What is Drupal lacking?

Basically, Drupal is lacking many of the Movable Type extra parameter tags that define how the output is pulled out of the database. For
full details, you'll need to trawl the MT tag docs. For your enlightenment, I've pulled out the main ones people will miss here:

• Specify the sort order for nodes (ascend|descend).
• Specift the sort type for nodes (author, subject, date, etc.)
• Displaying nodes by category on the front page. E.g. a section for personal, another for development projects.
• Display nodes that are younger than n days.
• Display nodes that have been recently commented on. Do we have a block for this? I think so...
• Display a perma-link (page + #id).
• Display web site URL of the author of this entry.
• Display number of trackback pings.

Observations: it'd be useful to make the process of creating pages devoted to a particular taxonomy category easier.
Pretty much the first thing that a web site author will want to do is create some static pages, probably grouped under a few
different subject headings, with those headings linked to from the main navigation header links.

As a Drupal/PHP developer, if I had to create a product catalogue, I'd be tempted to write a proper Drupal module for it, so that
I could include fields for product codes, manufacturer, e.t.a for shipping, etc., etc. However, as a normal site admin with no real
PHP skills, I can't help feeling that they'll just want to copy and paste some HTML into a box for each one. We need to make this
process easier. It'd be *really* good if we could make a Typo-3-like system, where Drupal runs a wizard that effectively constructs
its own module code, complete with database entries. Then you'd be able to add a product catalogue with proper fields very very easily.
This is way beyond anything MT can do with its current architecture. Note that you'd be able to specify default sorting with this
sort of system very easily.

Consider search results, however. They probably come in columns (type, date, subject, author, etc.). It would be nice, as a user, to
be able to click on a column heading like in Windows explorer to sort things by column. This needs to straddle all the layers, all the
way up and down the chain:

UI (user clicks column header) ==> data abstraction layer (works out which query to run) ==> database (runs query)
database (data returned) ==> data abstraction layer (munges db resultset into PHP variables) ==> UI (view sorted results)

Drupal is currently lacking some of the features required to go all the way up the chain. It could also do with a few to go down
it properly (what if I want to highlight the currently sorted column with a grey background?). A lot of this can be fixed by using
the theme()/theme_invoke() function to override modules' rendering of content. However, this requires you to know lots about how the
module works, and isn't as nice as MT's tag system. It's fine for simple nodes, but for things like search results it gets a whole lot
more complicated. Of course, MT can't handle things like this either... but then, Drupal's much more powerful and that's part of the
problem - you want to do more powerful things with it.

I'm not sure what else to say, really. You have to use both systems to get a feel for the different pull/push approach.

Ideally, we need to develop a middle layer that pulls stuff from the database in a configurable way (ordering, etc.) and then pushes
that data to the theme layer for structuring before CSS styles it. I think we're some way towards that goal already, but it still
needs some work.

Features MT users have requested that MT doesn't have

Features in bold, neither system has. Features not in bold, we have, they don't. Where applicable, vocabulary and terminology has
been 'Drupalized'.

• Ability to restrict a user to posting about particular taxonomy categories. This could backfire and they'd end up posting things
  to the wrong category. I'm not sure how useful this would really be.
• Better author profiles/archive features (Drupal already does fairly well here).
• E-mail to blog, and write entry on PDA then synch to blog can already achieve this using mailhandler, surely? There's a piece
  on using AvantGo to synch MT from a PDA here. We might be
  able to do the same thing with Drupal.
• Password protect an individual entry for private viewing (without Drupal authentication).
• Custom entry fields. We do this with modules already.
• Autolink list. I.e. type "Drupal" and it automagically becomes <a href="http://drupal.org">Drupal</a>. We could
  fairly easily write a module to do this using taxonomy and filters, much like glossary currently does.
• Clickable smileys. Need to hack some javascipt into the smileys block to make this happen.
• Spellchecker. This was also requested the other day in the forums at Drupal.org. We might be able to use
  spellchecker.net for this. There are other alternatives, too.
• Threaded comments.
• Moderation of comments. This is being worked on. Isn't it?
• Multiple file/image uploads. (pref. also with zip/tgz handling)
• File browser. For selecting files/images you've already uploaded.
• File management. For deletion/rename of files you've uploaded.
• Scheduled content. Expiry/future posting.
• Subscribe to comments. For a particular entry.
• Subcategories (hierarchy). Three cheers for our taxonomy.
• Add new taxonomy term from entry screen.
• Set default taxonomy term for posts.
• Next/Previous within category. Do we have this?
• Tags to automate breadcrumbs. This is only really applicable to our collaborative book. Hmmm... not sure there's a direct parallel.
• Specify the day the week starts for calendars. Drupal could do with a unified calendar for archives/events, etc.
• Pagination of search results. I think we already do this. I need to add some more pages to my site to check.
• Searchable MT Manual. The Drupal one's online and already is. The joys of writing your manual within your CMS.
• Links management. Hierarchy of bookmarks for a links page. We could do with a module for doing this.