Drupal

In the Drupal content management system, a "node teaser" is small bit of content used to encourage you to "read more" of the post. Drupal can set the teaser to the entire length of the post (typically used for blogs where you don't need extra click-through), or can automatically generate the teaser to a specific character length. In the past, you could also manually generate teasers by including <--break--> in the node's body. In Drupal 6, manual teaser definition has been improved with JavaScript wizardry, along with a new checkbox: "Show summary in full view".

But there's a small problem with the use of the word "summary". Generally, when a Drupal teaser is included in the node's full view, it's because it's the introduction of the node itself, not necessarily a teaser or summary of the entire body. Over at gamegrene.com, a node's teaser is, in fact, a summary of the node, and is also displayed on the full view itself. It's not the first paragraph of the article but, rather, is styled differently to provide an overview of what you'll be reading. IBM uses the same model at their developerWorks.

If you placed a "summary" at the beginning of the node's body, unstyled, readability would tend to suffer - you'd have the summary (node teaser), and then, theoretically, the introduction (node body), with no clear indication that two different types of content, with two different purposes, are being served.

As I've been working on moving Gamegrene to Drupal 6 (in time for Dungeon and Dragons 4th Edition, coming June 7th), I had to solve the problem of: how do I theme the teaser differently than the body inside node.tpl.php? By the time the template gets the node data, only $body and $content exist; $content only contains the teaser (for list views) or body (for full views). The teaser never exists in a node's full view as its own variable.

To solve this and get the same view as seen on IBM's developerWorks, I used themename_preprocess_node() to detect if a teaser has been manually set and that the "Show summary in full view" checkbox has NOT been enabled. When that checkbox is checked, Drupal automatically adds the teaser to the node's $body (or $content) - it treats the teaser as the introduction to the post, not an actual summary of what you're reading:

function phptemplate_preprocess_node(&$variables) {
  // we like to display teasers on the node view pages in a different style,
  // but only if they were NOT set to "show summary on full view" (which seems
  // backward, but the implication with that checkbox is that the teaser is
  // PART of the node's body, instead of an actual summary of the entire
  // node's body). if a node's unbuilt body starts with <!--break-->, then
  // a teaser has been manually set, and "show summary" is not checked.
  if ($variables['page'] == TRUE) { // only do this on full page views.
    $node = node_load($variables['nid']); // we reload the node because
    // by the time it gets here <!--break--> has already been filtered out.
    // this if logic stolen from node.module's node_teaser_include_verify().
    if (strpos($node->body, '<!--break-->') === 0) {
      $variables['style_teaser_differently'] = TRUE;
      $variables['teaser'] = check_markup($node->teaser, $node->format, FALSE);
    }
  }
}

Note that the extra node_load() is nothing to worry about - since the node has already been loaded earlier in this execution, node_load() will happily return a cached version, saving us any performance concerns.

Now, it's just a matter of displaying it in node.tpl.php:

  <div class="node-summary"></div>

Comments and concerns? Note that, for my particular needs, I wanted this entirely in a theme - I'm not changing data or its structure, merely its display, so doing this sort of stuff in hook_nodeapi() with a module's overhead would be a little much.

All in all, the response to Drupal Tough Love, the new code reviewing blog from chx and I, has been quite favorable, and we've already got a queue of at least a dozen submitted modules to look over. I had a grande chuckle at Amy Stephen's post on it over at OpenSourceCommunity.org:

I lift this service up because it's a perfect example of a functioning community ... What I am trying to say to those of you who are considering this service, but are not quite in touch with the inner geek inside, is this --> don't ask these guys if they think you are fat if you have your box of big clothes out and your skinny clothes are pushed in the back of the closet. It would be just like asking Simon Cowell if you can sing ... Károly and Morbus are not only acknowledged for who they are, and they are not only accepted for who they are, but who they are is celebrated. So, rock on, Drupal community!

We all make mistakes; that's how we learn. Sometimes, though, we need someone to point out our mistakes, to sift through the chaos that is Drupal's contributions repository. Inspired by jpoesen's comment on my code quality entry, chx and I have taken up the task of giving some tough love to Drupal's greatest strength: the army of developers using its APIs. Want your own code publicly reviewed at DrupalToughLove.com? Let us know!

I'm pretty critical about code quality, be it for my own projects or those of others, and have become known as giving harsh code reviews for the Drupal community. Hearing "ask Morbus, but be prepared to cry" pleases me, and I have little impetus to stop doing things I enjoy, regardless of what people think. Recently, someone suggested the reason my reviews seem "assholish" is because I state "you" a lot. I agree with this, I think, and have made an attempt to lessen my usage, though not my anality.

I define code quality via a number of different hard-to-describe metrics. In the case of Drupal, following the code style guidelines is certainly key, but also following Drupal core patterns as well - doing things "like core" is pretty high up there. This could be as simple as using the same documentation string for Drupal hooks, using the same pattern for the null option of a select box, et cetera. Using coder.module (a Drupal lint) to correct 90% of your mistakes should be required and, sometime in the future, tests from something like SimpleTest should be too.

I also think that, if you're going to "take over" a module, or otherwise release one, it should make an attempt at meeting the highest level of code quality. One could argue that "release early, release often" dissuades us from this, but I disagree: there's a difference between "doing it right" and "continuing to suck". I have no problem with weekly releases if you make an attempt to maintain or improve code quality. Hearing "A lot of strings have been lingering in incorrect forms ... as I try to prevent translations from breaking" isn't a legitimate excuse: Drupal core doesn't care about backwards compatibility, and it highlights your own inability to spell-, grammar-, or read-aloud check your strings (while also calling into question the quality of translators who have converted your broken documentation without complaint). I didn't release "my" version of Case Tracker until I considered it of high quality, and I made sure to provide explanation for what I was doing.

Since I've stopped working on Case Tracker, the CHANGELOG.txt hasn't been updated but, more importantly, it hasn't been removed either. This is just the first of a dozen "heading back to crap" problems that Case Tracker is suffering under, as I watch the new maintainer commit style error after style error. I don't give two shits if you're a certain type of programmer, or if you've coded this way "for years": if you're committing a Drupal contribution, you should follow the goals and styles of the parent project. Anything else is utter failure. If you don't want to, get the hell out of contrib, because it's already a sodding mess and you'll only make it worse. Requiring developers to read even the most basic of code practice books should be a guideline for access into any repository. "What is the name of the checklist on page 579 of Code Complete First Edition?", and other "you must have the book" tests, would be awesome.

This lack of quality control is the same reason Steven Wittens (UnConeD) left. He and I have gotten into a number of arguments, certainly, and he coined "The Morbus Effect" but, ideally, we're after the same thing: the best the code can offer, and an attention to research, detail, and testing that is, at times, incredibly boring.

Which all leads us into the blanket response to any criticism of code: "Where's the patch?". The overuse of the "code is golden, talk is not" ideology is as frustrating as anything else. I have no problem with contributing patches to Drupal modules which have made an attempt at code quality. There's a difference in "your code is good, but this needs fixing" vs. "holy crap, everything about this module is wrong". If you make an attempt to write good code, I'll put forth the effort to make it even better. If you don't, then I'm not going to waste my time improving your code: it just needs to start over. Make a new file and port things carefully, rewriting and organizing them properly. Or, do it in the same file and separate the good stuff from the bad by gigantic swathes of whitespace. Until you make the effort to show you care about your code and the parent project it belongs to, I'm not going to either.

Quality is one of the prime reasons I wrote an (unreleased) Achievements module as opposed to installing User Points. Ignoring the different approaches of "achievements" vs. "accumulate[d] points" (which I'll probably touch on in a later post), the 2.0 version of User Points failed at nearly everything. Besides showing, to me, a lack of quality, it actually didn't work properly, further exasperated because it shipped with a number of modules that were never maintained. I sent an email or two stating my dislike, and marveled privately about how so much crap could make it into a "2.0" release, especially one that was proudly presented and ballyhooed at various Drupal conventions. This is why I don't mind complaining about it publicly - it positions itself as something great, but I've yet to see any indication of that. I don't think I'd be as aggressive if it were a new module or developer innocently asking for help - there's no marketing, ego, or pride to provoke my ire.

Inevitably, I got into a chat about it on IRC, and that ever-nefarious "patch?" lament appeared. To me, User Points 2.0 was an example of wrong from the ground up, with duplicate data in the database, a UI that didn't work (functionally or architecturally), shipped modules that no developer cared about anymore, and crazy code patterns that drove me up a wall. The same conversation promised a new developer had taken up the reins of 3.0 with lots of rewrites, and I should check it out. Hating duplicate functionality and the whole "Not Invented Here" problem that often plagues plugin-driven development, I told myself that I would.

I'm embarking on such a journey now, as I find a need for my Achievements module once again. And, still, as I look at the very first lines of User Points 3.0, I find myself clucking disapprovingly. I don't see much improvement but, certainly, it requires more effort to truly make the decision (to their credit, they did remove all the unmaintained contributed modules). For what it's worth, my first 15 minutes of discontent equate to:

• Abuse of constants: User Points defines its permissions and other strings inside constants. This isn't only wrong (Drupal core doesn't do such a thing) but serves no discernible purpose besides being an additional layer of abstraction - perhaps the developer's IDE supports constant completion? If you're not manually and anally testing every line of code (which would root out misspellings or typos, one of a few rationales for code completion in an IDE), then your module isn't up to par. Gladly, SimpleTest integration in the future will indicate more obvious dedication to testing and non-laziness but, of course, that presumes properly written and maintained tests, which is probably too much to ask and could lull one into a false sense of complacency.
• String retardation: Administration permissions in Drupal core are always in the form of "administer something", but User Points happily uses "admin userpoints". It also doesn't know what the hell it's called: the module's page has "User Points", but usage within the code indicate it could be "Userpoints" or "userpoints" and that it could integrate with "e-commerce" or "ecommerce". These are all things I consider easy and obvious indications of quality control - most module interaction is only ever to an end-user, and if you can't perfect the most visible output of your effort, then the actual code isn't getting any love either.

At a 15 minute glance, if someone yelled out "patch?", I'd decline. This is a module that is showing the same problems I lamented privately about for 2.0, and just needs to spend an entire release cycle worrying about quality not functionality. With that said, note that this is, literally, 15 minutes of glancing at the source. I've yet to actually install the new 3.0 and there's still a good chance I'll find it usable enough to merge with my achievements code. "Not Invented Here" syndrome is a sign of laziness too but, as jsled remarked after reading an early draft of this entry, "at some point, learning how to use a tool is more costly than just writing a special-purpose tool".

One suggestion for improving module visibility in Drupal is to offer module ratings. I wouldn't support this idea unless there were two distinct metrics: the end-user metric (does this module do what I want it to do?) and the developer metric (does this module's code live up to the code we ship in Drupal core?). To me, a module's quality equates to a combination of both, and any rating system that attempts to merge the two, or leaves one out, isn't adequately asserting overall health.

Teaser 3 is up, previewing the 60BWC achievement system:

An achievement whore is the moniker taken by those who strive to earn every Xbox 360 achievement possible. For those unaware, every Xbox 360 retail game ships with 1000 points that can be earned by mundane, impossible, odd, or merely random gameplay. These points accumulate into a total gamer score that represents all the games you've played. To "ace" a game means you've earned all the points possible: ace your first five games and you'll have a total of 5000 points. Achievement whores obsess for days and weeks over the smallest point value or most useless task, in an ever-deepening delirium to see their scores climb ever higher. Some receive the scorn of fellow whores as they cheat their way forward with game saves and other nefarious activity.

There's new teaser content over at my newest project 60 Blank White Cards, including ruminations about one (of four) inspirations for the game, as well as some very early sketches from our resident artist. Check it out!

Perplex City was an alternate reality game (ARG) with purchasable, but optional, puzzle cards, as well as a cash prize for the first player to find the stolen Cube. While other ARGs have toyed with physical items earned or found by players, as well as "prizes" (like playing Halo 2 before anyone else), none have yet replicated Perplex City's particular approach. I tend to think this is for two reasons: the mystery and the money.

A new game entitled 60 Blank White Cards, coded in Drupal and by the well-known Morbus Iff, has just launched its teaser site which alludes to "cash prizes", "prize-winning points", and offers up the requisite word puzzle for those ready to learn more. Take a look-see, sign up for an account, solve the puzzle, and wait for the next update!

As I promised weeks ago, here's how I converted my Flexinode node types to CCK. For my needs, I used a local development box that started out as Drupal 4.7 and was upgraded normally to Drupal 5.x. I did not have Flexinode installed for 5.x - I knew I was migrating so I didn't bother downloading it. I wrote and tested my converter on the dev box, then did the same upgrade steps on the production server, running my converter last. The script assumes knowledge of how Flexinode and CCK database tables were designed, and keeping the URLs exactly the same from node type to node type. I've done similar processes on two sites so far, and am planning a third. This is not an example of the standard "Drupal upgrade process" and it certainly isn't end-user friendly - this will never be any sort of official process, nor would I want it to.

There are a few things you need to know first:

• Do you plan to use the body field of a node? This is a good time to redesign your data if necessary - CCK node types allow you to define (or not) whether a node's body field is used. This becomes particularly nice if you want to CCK a blogapi-enabled node type. If body is not used, we'll be deleting it and teaser during the conversion (Flexinode would pre-create the teaser and body fields on node_save() which is not necessary for CCK).
• Do you have any odd field types that don't correlate to CCK? You'll need to do some grunt work to see if complicated Flexinode field types are available in CCK. For one of my sites, I used Flexinode's field_table.inc to create a 2x3 table that users would enter up to three URLs in along with their titles. This maps nicely to CCK's link.module, though these types of things require special attention in the conversion process. If all you've got are boring textfields and textareas, you're golden.
• You'll need to precreate your CCK node type. My conversion process only works on data, NOT the data structure and design. Make your CCK node type, perfect it, test out that it works, then examine the created database tables and rows. Look at the column names, how things correlate to the node_revisions table (if at all), and pay close attention to whether a CCK field allows a specific input format. If it's plain text, we won't have to convert that data from Flexinode. If an input format is allowed, we'll have to.
• You'll need to know the field IDs of your Flexinode field types. Easiest way to find these out is to head to the Flexinode content type screen, mouse over each of the fields you've added, and jot down the IDs. You can, of course, find these out via the database if you've already upgraded to 5.x and don't have Flexinode installed anymore. I'll leave that up to you.

This example code was created in a custom module for one of my conversions; I'm not showing the entire module framework because I assume you know what you're doing. You can also stick this stuff in a convert.php with index.php-like bootstraps. Whatever works. The code contains the rest of the documentation.

Those who have ever read my emails may know, love, or harbor resentment to, my random signatures. Now 81 entries long, I'm always on the lookout for phrases or words that titillate me in as few words as possible: 58 characters is the largest signature length I've saved. Shrinking an idea or emotion down to that many characters or less is a bit like Perl Golf, another game I enjoy.

<dopry> hey Morbus, how's it going... rough evening/morning?
<Morbus> nah, not at all.
<dopry> Ok.. You just seemed to have a chip on the old shoulder...
<Morbus> dopry: nah. not at all.
<Morbus> well, it's quite possible i've had a chip on my shoulder for so long that it's part of the shoulder now.
<eaton> that's an excellent motto.
<Morbus> "my chip has been there so long, it's part of my shoulder now"
<Morbus> no wait.
<Morbus> that's not poetic enough'
<Morbus> my chip has been there so long, it's no longer on, but is.
<Morbus> hrm. needs the word shoulder to associate though.
<eaton> "It's quite possible I've had a chip on my shoulder so long that it's part of the shoulder."
<Morbus> mottos are short and lyrical.
<Morbus> my chip's been there so long, it's no longer on, but is, my shoulder.
<Morbus> hrm.
<Morbus> no, that's not good either.
<Morbus> ooh! i goti t!
<Morbus> "i've no more shoulders, only chips"
<Morbus> now *that's* a good one.

82! 82 signatures! Ah ah ah!

As you'll notice, I've finished converting my original Drupal 4.7 theme to 5.x. This is normally trivial but I also took the time to restructure the CSS with a basis on Garland, the new default theme in core. In addition, I also finished something I started long ago: the "network-ization" of the Disobey theme.

What I call "network sites" are many sites that fall under one tent but comprise many different domains or subtopics. These are not portals or collections of services like Yahoo! and Google, but rather content-based; GameSpy's planets are a good example. Disobey has always been, since its beginning in 1997, one of these sites, but I always did an entirely new design for each topic. This scaled badly: as I moved to new technologies or ran out of time, sites languished unconverted or unloved. Nowadays, I'd much rather do something else besides design.

The first iteration of the Disobey theme for Drupal 4.7 shared many characteristics of other network sites: a top navigation item that covered "about us" and other sites within the network, a short header that loudly proclaimed what this was, a highlight area for the most important shoutouts, and a standard two column layout with the sidebar repeating the related sites mentioned in the top navigation. Until now, I never finished making it generic enough for use elsewhere.

This is my base network_wireframe theme:

I made it blue to mimick the "blue pencil" of desktop publishing: they were used much like the "red ink" of a teacher: for corrections, edits, or revisions of your document. Blue pencils (and pens) didn't photograph and were invisible in the finished item: take the same "you don't see it" as a green (once blue) screen in movies and apply it to paper. The goal of this wireframe is simply to be functional while still representing the structure and model of the finished product.

This is where Drupal's subthemes come in: the Disobey look and feel is the exact same document object model as the wireframe only with a different style.css (which, in turn, references different images and color). For me to make a new theme, it comes down solely to product identity: all the walls are up, but what color paint?

Drupal subthemes are nothing new: Chameleon had Marvin in Drupal 4.7 and 5.x has Garland with Minnelli. Subthemes are born when a theme directory has a subdirectory that contains, at least, a style.css file. There are, however, a number of more general design issues you'll want to keep in mind when creating a subtheme:

• The master theme should be completed first and have most of the CSS. The subtheme style.css should be simple overrides of what you've already defined.
• The subtheme's style.css needs to @import the master's style.css. Note, however, that you can't use Drupal 5.x's CSS preprocessor without running into an inheritance bug.
• The subtheme does NOT get its own template.php. If you need to add code to your subtheme (my use cases are subthemes for taxonomy terms where I'd want to change the site name displayed in the header, or random logos), you'll need to rig the master's template.php to include subtheme PHP files that change $vars and other elements. Not too difficult.
• While subthemes do support .tpl.php overrides, it is ill-advised. The master theme should really be the master theme: if you start one-shotting subtheme tweaks, you'll just make the master less and less powerful and all your themes more difficult to maintain. Enforce a generic and workable design in the master. If you're working with nodes, use Contemplate to do your specific style changes in the database, not in the filesystem.
• Put new features in the master and make them optional. If a subtheme needs random logos, make the master theme support it first then add the extra images to your subtheme. Now, all your subthemes support random logos and it's merely a matter of turning it on or off (in my implementation, a master/subtheme/logos directory with more than one file automatically enables the feature).
• Stick your theme in sites/all/themes so that it's available for all configurations.