This is a follow-up to my earlier blog post on newbie-mind-blowing features of Drupal. The good news continue: Drupal is the most awesome thing to ever happen for purposes of building the Avarthrel website.
One commenter in Reddit thought the site doesn’t yet exhibit any of the great strengths of Drupal - which is an unfortunate side effect of the fact that the site has only been in operation for a few months, I’ve been kind of busy fiddling with Drupal instead of producing more interesting content, and that I am a newcomer to Drupal.
But now, I’ve managed to import most of the old site’s content to Drupal, and I’m actually producing new stuff.
And I even managed to do awesome dynamic things with Drupal, something that really shows how Drupal’s way of doing things is so incredible. Allow me to elaborate.
The list of stories
Like I said in the previous post, one of the greatest annoyances I have had with other content management systems is that other content management systems don’t focus too much on the actual content. They let you manage pages, but they don’t really let you manage content as such. They’re often geared toward a specific paradigm.
For example, Movable Type, which powers this blog, is geared toward blogs. It only creates indexes of blog posts because it was designed to run blogs, and when people come to blogs, they expect to see indexes of posts - a nice orderly front page, and monthly archives. What the blogger wants to concern their little heads with are the blog entries, which are just individual pages that get put somewhere. The bloggers don’t want to maintain those indexes themselves - that’s the whole point of using blogware.
But if you’re not making a blog, most content management systems say “well, you’re out of luck, you just have to build it yourself, whip out your favourite PHP editor and write a bloody extension”.
Drupal, on the other hand, has this worked out, because it’s a content management system. There’s this notion that if you design your content well, make sure you put all of the relevant bits of information in the same place, it is inherently easier to manage it all.
Hence we come to a story on how the story page came to be.
[“<p”, “ class="asset-centered-big"”, “>”, “<img src="/assets/blog/a/av/avarthrel_storylist.png" alt=""/>”, “</p>”]
The story index used to be a normal page in my webgen-based website, which was maintained by hand. I just put some random bits of blurb there and organised the stories around headings.
It looked roughly like this:
A group of stories
Bit of rambling where I tell something about this group of stories.
The Slaying of Webgen (22-11-1234) (link to deviantART) — In which our intrepid heroes get rid of a perfectly functional system.
Here I ramble incoherently about how much fun I had writing this piece of junk. The reading audience yawns.
The Nefarious Return of Webgen and Eventual Triumph of Drupal …
Quite rational so far - except that I never really liked that. I’ve been rambling a bit, and I don’t really like the blurbs I put there. When importing the site back, I just noticed I put a lot of utter rubbish there and I need to write better blurbs. Oh, it’d be so much easier if all of the story-related information was stored in one place. Like, oh, the story nodes in Drupal.
So now, short story nodes have fields for “short blurbs”. This is an one-sentence summary of the story. The stories also have author’s introductions - it’s a summary-and-long-text field, so I can put in summaries for the index page. These are the two bits of story-related information that appeared only in the index page, and putting them to the story nodes simplifies things.
Using Views module, it’s quite easy to use the Field display mechanism to print out these bits of information from each story.
I tackled Views briefly in Mini-Tales page. That simply used a view to form a list of Mini-Tale nodes in alphabetical order, and each of the results is shown using the “Teaser” view mode. The view modes are a neat bit of Drupal’s (and Display Suite’s) foresight: information needs to be shown differently in different situations. But Views offers a more flexible way of showing relevant bits of information, in form of Fields - essentially, you can make ad-hoc “view modes” that only make sense in that particular View.
Views module in turn doesn’t have to expose its results as a Page with an URL, as is the case with the Mini-Tales page; it can just as easily show its contents in a Block, included through a Panel (of which more in the next section) or through another View.
For now, I omitted the deviantART link from the original design. Using the Fields display mode, the view prints out publication date, the one-sentence summary, and “summary or trimmed” version of author blurb. I wrap the one-sentence summary in italics using field display options, and designate that the date and one-sentence summary should be printed inline, with a dash between them.
But this is only adequate for listing the stories. How can they be organised in groups? There’s a Drupal core mechanism for that — Taxonomies. I created a vocabulary called “story groups”. A story may belong to one or more story groups, which is just a field in the short story content type. Each of these taxonomy terms has a description, which serves as the intro in the page.
The story page is just a View that lists each root-level story group taxonomy term in the order they’re manually arranged to - in technical terms, the weight order. It lists each term’s name as a heading, and description as the description above each story.
Below them is another field - a list of stories in that particular story group. This is the tricky part. It requires one further module: Views Field View.
The story listing sub-view, which uses the fields I mentioned above, simply lists stories sorted by order of publication. It takes one contextual parameter, which is used to filter the search: story group taxonomy ID.
In the story page view, the last field to show is simply a views field which passes the current story group as a contextual parameter to the sub-view.
Finally, I applied some caching, as Views Field View recommends doing so. It’s not like I publish a lot of stories. g
To put it all toghether: The story page takes a list of taxonomy terms, prints out headers and blurbs for them, then for each entry queries a list of stories, which are shown using a specific format.
It’s not that difficult, really. Didn’t need to know a single bit of PHP to pull that off, and I certainly didn’t have to write a single SQL query. How’s that for Drupal power?
Making the front page neater
In my old Avarthrel site, I had a list of blog posts that was just based on the Atom feed of this blog. It was relatively easy to pull off. In Drupal, putting that thing to the front page was really easy too, because Drupal comes with a feed aggregator module.
Of course, Drupal doesn’t come with a sane way to display the feed entries. But the beauty of Drupal is that that can be easily fixed, once and for all.
The new front page is organised using another module - Panels. Panels allows for creation of sequential containers for any Drupal content - including Views and other Panels (technically, Minipanels for smaller units).
Using Panels allowed me to just split the content into other nodes: The introduction, the table of contents and the babble about Avarthrel elsewhere are just static nodes whose content is pulled to the front page via a Panel.
[“<p”, “ class="asset-centered-big"”, “>”, “<img src="/assets/blog/a/av/avarthrel_frontpage_stuff.png" alt=""/>”, “</p>”]
I thought it would be neat if the front page had a box for the most recent story. So the mini-panel has a View in it that just pulls the most recently published story (in other words, “sort by publication date, limit 1 result”) from among the content.
As said, Drupal has the aggregator module that can manage feeds easily. Of course, when the entries are displayed, they look so very incredibly boring. How to remedy that? Views to the rescue, again. Each View entry can be formatted using the display fields.
When I put the boxes side by side, however, I noticed that there’s usually just too much free space under the blog heading list. How to make it cooler? How about adding a sub-view as the heading of the blog feed box: pull the most recent blog entry, show the blurb of it, link to more. Then tell the actual blog list view to skip 1 entry. And put a link to the actual blog in the footer. Looks really nice!
Other random crap I learnt
Another random module I stumbled on is Exclude Node Title, which is very handy. Some of my pages (like Kara the Assassin and Conman’s Dictionary) have title graphics, so I don’t really need the Drupal-supplied title - I just insert my own <h1> element. Without this module, you’d basically need to mess up templates by hand.
Media module also patches up one of Drupal’s strange omissions - Drupal has a notion of files and images, but no real way of managing them. Media that is uploaded through fields are just invisibly associated with pages, and you can’t really do anything with the files apart of the usual formatting rules. This module apparently exists to extend the media to further sphere and lets you actually see what files you’ve uploaded, unrelated to the pages where they appear. This certainly looks interesting.