From Wordpress to Drupal, or, how I made this site

Until late 2010, I ran as a Wordpress site on Dreamhost, before switching to Drupal. I like Wordpress, and still run a number of sites using it (my husband's site, for one, and Crescat Graffiti, for another.) But when I needed to expand the site from just a blog and some static pages, differentiate different kinds of content and lay them out differently, I felt it was time to switch to Drupal. (Wordpress devotees would beg to differ; there seems to be a degree of self-consciousness among the Wordpress crowd about being "a real CMS, useful for more than just a blog".)

I didn't have enough content on the old site that doing an automatic batch import seemed worth the debugging-- I spent an hour instead copying and pasting over the content, and making sure everything showed up all right. That said, there are Drupal modules out there for converting larger sites, like Wordpress Import, or using a more generic solution like table wizard and migrate.


  • Administration Menu: makes the administrative functions of Drupal available on every page, via a drop-down menu at the top. I never build a site without it.
  • CCK: Content Construction Kit, lets you make content types with custom fields
    • Node Reference, Option Widget, Text: built into CCK, allow you to create those kinds of fields
    • Link: a CCK add-on that lets you add link fields
    • CCK blocks: Makes selected CCK fields available as blocks, which can then appear in any block region.
  • Views: essential for listing, grouping ,and organizing content
  • Panels: lets you create more complex layouts on individual pages (if you go to the Digital Humanities or Drupal pages, you can see examples of panels.) Also enable the Views content panes module. Ctools is a prerequisite.
  • In Drupal core, I enabled: Comment, Database logging, Help, Menu, Path, Ping, Search, Taxonomy, Update status, and Upload
  • Custom Breadcrumbs: so that all blog content has "blog" in the breadcrumb, and Drupal content has "drupal" in the breadcrumb, etc.
  • Glossary: to enable pop-up definitions for some of the abbreviations and jargon on the Digital Humanities pages
  • Pathauto: to automatically set page aliases; Pathauto requires Token
  • Trackback: to enable trackback support, like Wordpress had
  • AntiSpam: to deal with comment spam, used with the Akismet key I used on Wordpress
  • Google Analytics: for Google Analytics integration
  • Taxonomy Block: displays a taxonomy, along with node counts, as a block that you can put in any region a block can go. I use this for the "Categories" vocabulary associated with the Blog content type.
  • Boost: the way Dreamhost has configured their MySQL, Drupal tends to run painfully slowly. By doing static page caching-- and most of the pages on this site are more-or-less static-- Boost speeds things up, at least for anonymous users, which amounts to everyone but me.

Types of content and their display


One of the built-in Drupal content types, there are only two actual "pages" on the whole site: the home page and my CV. All the other content belongs to a more specialized content type, though the content types don't differ much in terms of fields. Pathauto and Custom Breadcrumbs motivated those choices. Setting up different automatic paths for different kinds of contents (and paths are important for determining where blocks do or don't show up), and setting up custom breadcrumbs for those kinds of content, are a lot easier if you create different content types, instead of creating a single Content Type in Drupal, with a field where you select which kind of content it is. (I do use this technique to differentiate sub-types of content, see the "Drupal" content type below.)

The CV has its own menu item, and the home page is what I've set the default front page to be (in /admin/settings/site-information). There's nothing fancy going on with the display of either-- it's just a normal, full-node display, no blocks or anything.


Content type

I could've just used the built-in "Story" content type to serve this function, but for no particular reason I created a new one called "Blog". There are no special CCK fields, though there are two Taxonomy vocabularies associated with it: Categories (which appears in the "Project" content type as well-- you can see the categories on the blog page, in the block on the right side), and Tags (which also appears in "Drupal" and "Writings".)


The blog page is a page display from a View, which I've set up as follows (things not mentioned have been left with the default settings):
Basic Settings
Title: Blog
Use Pager: Paged, 5 items

All fields are configured to have no label.
Node: Title (Style settings - HTML element: H2; Link this field to node)
Node: Post date (Style settings - HTML element: H4)
Node: Body
Node: Add comment link

Sort Criteria
Node: Post date, descending

Node: Type = Blog
Node: Published = Yes (I often write a post over a few days, and set the post to "unpublished" until it's done. But unless you set up a filter, even unpublished drafts will show up.)

For the displays, I've created a Page display and given it the path /blog. Nothing on the page display overrides the default settings. I've also created two RSS feeds, one at /feed (to match the path on my old site) and one at /blog/feed, to go better with the current site. For the feeds, in Style Settings, the Style is "RSS Feed", and Row Style is "None". If I didn't want to provide a full-content feed, I could've hit the cog to the right of "None" for Row Style, and selected "Title only" or "Title plus teaser".

Other design elements

I've configured the taxonomy block (for "Categories") to appear only on pages whose path matches:

Concretely, this amounts to the page that lists blog posts, and the individual page for each blog post.


Content type

In my old Wordpress site, I had pages for my projects, and my "template" was a standard set of HTML headers I'd put on each project page. When rebuilding the site in Drupal, I created a "Project" content type that had a separate (link) field for the project website, if available, and another separate field (also link) for the RSS feed with project updates. The "RSS feed" URL I'm using isn't actually an RSS feed proper (though you could create one using Views), but rather, the page you get when you click on the taxonomy term corresponding to that project, from the "Categories" vocabulary. Google Reader can ingest it without a problem, though.

As I've written the content, I've been deliberate with where I cut off the teaser (the first few sentences or paragraph that appear in the search results, and are available to Views. I need the teaser to be intelligible when it stands alone, because it's going to serve as the quick project summary on the Projects page, where the reader can click on a given project for more information.


The projects page is a very simple view that uses mostly just default settings. (It's not that I want a 10-item paged view, I just don't have 10 projects at the moment, and when I made the site I didn't think it was worth planning ahead for the day that I do.)

Again, no labels on either of these.
Node: Title (Style settings - HTML element: H3; Link this field to node)
Node: Teaser

Node: Type = Project

There's one display for this view, a page display with the path /projects. The projects page, then, shows the name of each project (with a link to a page with more information), and the one or two sentence teaser. Some of those individual project teasers include an image, and those images appear on the Projects page.


Content type

I wanted to provide links to a few of the longer bits of prose I've written, along with an abstract or excerpt, or (where the material wasn't published elsewhere) even the full text. Again, I was deliberate about how I constructed the Teaser.


This has the exact same setup as the Projects view, except the filter is for Writings instead of Project, and I have an added filter to prevent unpublished nodes from displaying, like with blog posts.

Digital Humanities Analysis and Digital Humanities Data

Content types

My project to publish organized data from the Project Bamboo workshops, as well as summaries of that data, motivated my switch from Wordpress. The Digital Humanities Data content type is unremarkable, except in the Body field I always use a specific input format configured in conjunction with the Glossary module. With the Glossary module, you create a vocabulary where you enter terms and definitions, and associate it with an input format, and when that input format is used for a text area, every time the terms in that vocabulary appear in the text, the reader can hover over the term to see a pop-up definition. This was particularly useful for the Digital Humanities Data-- while there were precise citations for all the quotes, they might not be comprehensible for most readers. Using the Glossary allowed me to explain, in a non-obtrusive way, what question was discussed during Exercise 1, or what the "Atlas" was referring to.

Digital Humanities Analysis contains an additional node reference field, "See also", that lets me select one or more Digital Humanities Data or Digital Humanities Analysis pages. I've enabled this CCK field to be available as a block (thanks to the CCK Block module), and placed it in the right column. There are two kinds of analyses: summary and "so you wanna...". Since these need to be differentiated when the analysis posts are listed, but not in any other way (e.g. there's no blocks that only appear on one kind of analysis post), I've created a taxonomy vocabulary with those two terms, and associated it with Digital Humanities Analysis. I also could've done this just as easily with a CCK field on the content type that offered those two options.


There's a view for Digital Humanities Data and Digital Humanities Analysis, and they're very similar:

Basic settings
Title: Analysis / Data
Use pager: All items (Data); All items, skip 1 (Analysis; the post that's being skipped isn't actually an analysis, but an introduction to the project as a whole. Conveniently, the first content post is "Access control", and the introduction is called "About the digital humanities analysis project", so by lucky coincidence it works out to be the first post, which can be easily skipped).

Style settings
Style: HTML List (for Analysis, it groups by "Taxonomy: Term", one of the fields I'm using that provides the data about whether it's a summary or a "so you wanna...")

Node: Title (both)
Taxonomy: Term (Analysis only; this would show all taxonomy terms associated with the node, but there's only one, which differentiates the two kinds of Analysis post)

Node: Title - Ascending (both)

Node: Type = Digital humanities analysis / Digital humanities data
Node: Published = Yes

Both data and analysis have a page display, largely for the sake of having something to put in the custom breadcrumb for each data or analysis post. They also have an RSS feed display (dh/analysis/feed, dh/data/feed) that I use in a custom block that appears on all Digital Humanities pages.


To present both kinds of data together, in two columns, underneath an introductory paragraph, I set up a Panel page for Digital Humanities. I created a node of the Panel content type, chose "Two column bricks" for the layout, wrote a paragraph of custom content (that linked to the full "About the digital humanities analysis project" introduction node) to put in the "Top" area, chose "View: dh_data - defaults" to put on the bottom left and "View: dh_analysis - defaults" to put on the bottom right, then saved it. Every time I add a new analysis or data post, it will automatically appear in the list on the appropriate page (/dh/data or /dh/analysis) and in the Panel, thanks to the miracle of auto-updating Views.


Content type

The newest section of this site is focused around Drupal. Instead of letting Drupal take over my blog in a haphazard way, I'm collecting the Drupal how-to's, site breakdowns, pedagogical materials, and musings in a single place. The new "Drupal" content type has one custom CCK field, for Drupal post type (Musings, Site breakdowns, Thinking in Drupal, Tutorials.) This field is part of the automatic path setting-- based on the idea that, perhaps in the future, I might want a block to only appear on "Thinking in Drupal" pages-- so only one choice is allowed.


I've created one base view, and added blocks that limit the data further by adding more filters.

Basic settings
Use pager: All items (For this one, I'm planning ahead-- I can see more than 10 Drupal posts happening faster than 10 projects)

Style settings
Style: HTML List; Grouping field - Content: Drupal post type

Still no labels.
Node: Title (linked to node)
Content: Drupal post type - exclude from display. I don't want the post type to show up under the title for every entry, I just want to be able to use it for grouping. To be able to use it for grouping (in the "Style settings"), it has to be present in the fields list, but be sure to exclude it if you don't want it showing up.

Node: Title - ascending

Node: Type = Drupal
Node: Published = Yes

From this view, I've created three blocks to use in the Panel: Site breakdowns, Tutorials, and Musings. Each of these has an additional filter: Content: Drupal post type - allowed values, where the appropriate value is chosen. The one thing to remember: when you're adding or changing things in displays, be sure to choose "Update and override" instead of "Update default display". (Later versions of Views 3.x-dev make it easier to remember by having those two buttons; I've made mistakes time and again in older versions of Views.)


The page that appears in the menu bar is a three-column panel (using the layout 33/34/33 stacked), much like the Digital Humanities panel.

Each View-created block goes in one of the columns. I've checked "Override title", otherwise it'll give me the title of the view-- "Drupal"-- at the top. With the way I've configured the View, a HTML list with a grouping field, the grouping field works well as a "title", and I don't need an additional one. I put in an another block here as well, based on a view that shows the titles of all blog posts that have the taxonomy term "Do it with Drupal" (the same settings as the other Views here, except with no grouping, and using the filter Taxonomy: Term.)

I've also created some custom content to put in the "Top" section of the Panel, introducing the rest of the content.


I discovered the Nitobe theme when I was obsessively building the TAPAS Project website in a day and a half. It has a reasonable number of appropriately-placed regions for blocks, it isn't corporate-looking, over-complicated, or downright ugly, and it can randomly display one of a series of header images I've uploaded. It's everything I want, and nothing more. TAPAS ended up going with a different, custom theme, so I took Nitobe and ran with it.


I don't do much with blocks on the site at this point, besides what I've described above. The search block also appears on the same pages as the custom Digital Humanities block (that has links for the RSS feeds for Data and Analysis).

Pathauto and Custom Breadcrumbs

I've configured the Pathauto (/admin/build/path/pathauto) node paths as follows:
Default: [title-raw]
Blog: blog/[yyyy]/[mm]/[dd]/[title-raw]
Digital Humanities analysis: dh/analysis/[title-raw]
Digital Humanities data: dh/data/[title-raw]
Drupal: drupal/[field_drupal_post_type-raw]/[title-raw] - note that this incorporates that CCK field where I have to choose the type of Drupal post (Musings, Site breakdown, etc.)
Projects / Writings: projects/[title-raw] / writings/[title-raw]

As for custom breadcrumbs, all I've done is that-- for each content type-- I've added a title and path for the "parent page". So, for the custom breadcrumb setting for blog posts, the only thing I've put in is the title "Blog" and the path "blog". Digital Humanities Analysis has two entries, the first for "Digital Humanities" / "dh" and the second for "Analysis" / "dh/analysis"; the same applies for Digital Humanities Data.

Other things that needed configuring

To make performance tolerable despite Dreamhost's server setup, I've enabled and configured (/admin/settings/performance/boost) the Boost module. It took a bit of doing, getting the .htaccess rules correct, but the module documentation is among the best I've seen. The Trackback, Google Analytics, and AntiSpam modules weren't terribly difficult to configure either. Glossary wasn't as easy to configure the first time, but I go into depth about how to do it in my VRE site breakdown.

See any other aspect of the site that I didn't explain in enough detail? Let me know in the comments-- I'm happy to dig into any of it further.



Add new comment

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.