Some guidelines for Drupal data modeling

The freedom that Drupal gives you to easily create content types where you can choose from a wide variety of field types, and combine them in any imaginable number of ways is, to my mind, Drupal's "killer feature". The fact that it's so easy also makes it dangerous. If I had to name one trait that really excellent Drupal sites share, it's a solid data model that aligns with the nature and purpose of the data, and is naturally extendable as the site expands, without resorting to ad-hoc hackish workarounds.

Troubleshooting Drupal site migration problems

I recently moved my most complicated Drupal site (a Bulgarian dialectology project with six inter-connected content types and thousands of nodes) from Bluehost to a dedicated Ubuntu 10.04 server; some of the views were exhausting the memory provided by a shared commercial hosting setup. The process reminded me that a skilled, patient sysadmin is worth their weight in antimatter ("gold" would be a serious undervaluation), but in stumbling through it on my own I discovered a few tricks that might save someone else the same frustration.

So you've installed Drupal… now what?

When you install Wordpress, it's pretty clear how to get started: in the left menu bar of the admin interface, you can choose between posts and pages, you can manage media, links, and comments, and you can choose to edit the appearance. When you install Drupal, you find yourself staring at a welcome page that suggests you:

  1. Configure your website
  2. Enable additional functionality
  3. Customize your website design
  4. Start posting content

with some inline internal and external links that might be of some use in accomplishing those things.

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

Until late 2010, I ran quinndombrowski.com 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.

Drupal jargon explained!

Drupal has a reputation for having a steep learning curve, but I remain convinced that it's largely overstated. Nonetheless, it's true that right from the start the new Drupal user has to contend with documentation that uses unfamiliar, arguably non-intuitive jargon. That said, "What's a node in Drupal?" is a harder question to answer than one might think. Because the pieces of Drupal are usually inter-connected, an easier term to define, like "CCK", depends on the reader understanding what a "node" is.

If an institution could support just one tool for teaching and research, it should be Drupal

"In these tough economic times"-- as the contemporary cliche begins-- IT organizations at academic institutions have to make particularly difficult choices about how to support teaching and research. As far as I know, there is no institution in such dire straits that it can literally support only one tool, particularly if "tool" is defined so broadly as to include everything from learning management systems to OPACs, wikis to VREs, to course catalogs, to public-facing content management systems that drive the institution's websites.


Subscribe to RSS - Drupal