Drupal Configuration

Posted on by JVS

Drupal icon courtesy of https://association.drupal.org/press/imagesIt’s time to install Drupal on the site. Actually we’re past that point. My last post was about Site Construction Planning and, while I didn’t elaborate on it, I installed Drupal on the site twice. I did this to ensure that my web hosting site configuration was actually compatible with the Drupal software and how Drupal wanted to interact with the hosting environment. That consisted of two, bare-bones, minimal installations. One to test Drupal operating as the primary content for the architectedfutures.NET site, the second as my development and testing environment, operating as a sub domain on the same web hosting account. My chief concern was that multiple Drupal sites could work from the one account, with each Drupal install using all the critical Drupal features, such as clean URLs, and not interfere with each other. Now it’s time to actually configure the Drupal installs into useful, operational websites.

Drupal Installation

I’m not going to spend much time talking about either the detail install process for Drupal, or the physical module installation. There is a quite extensive installation guide provided on the Drupal.org site. There are, however, probably a few points worth mentioning here.

Module Initialization

The first point has to do with the overall method for initializing the site. A lot of discussions I have seen talk about building the site first on a development machine and then uploading the completed configuration and database to the hosting environment. Essentially building the site offline, and then moving it to the online hosting system. This makes a lot of sense for a lot of sites, but is not the path I followed.

I did build a complete site offline on my desktop computer at home. But that site was not what I wanted to start with as my public website. My home development site was created as a prototype to demonstrate Drupal as a group web site. I experimented with and loaded modules like Organic Groups and others to see how those features would work. And I experimented with other modules whereby I built a group interaction ability using features supplied by other modules, piece by piece. These group features are the types of facilities I think I may want on the web site if a community were to form around some of my concepts. And my development site gave me an understanding and assurance that I would be able to do what I wanted with respect to those features. However, I am not sure I want to carry out the community features with the current modules I am using on the development machine. Also, I do not need those features for getting started. So I don’t want to simply copy that environment.

Instead, I have the ability to build multiple environments on my shared hosting account, so I’m going to build a fresh install using that environment, and then replicate that new, scaled-down configuration into the public production web site. In addition, I’m going to be evolving my site in-place over time, growing function as I add content. I want to start that mode of site management, and discover its problems, from the start.

Installation Profile

The second point has to do with the choice of installation profile. I am not using any of the special Drupal installation distributions which are available to initialize things like group sites, news sites, conference organizing sites, etc. However, there is still a basic installation profile choice to be made: minimal versus standard. While I wanted a minimal installation to use as a base, I did what most books recommend and I selected standard. This is a point of confusion which I had that I thought could trip up others, which is why I mention it. Standard really is minimal, and minimal is really bare bones. This Drupal.org documentation node details the difference between the two profiles in terms of what gets configured when selecting each profile.

It’s Never Completely Done

An additional point is that while Drupal was installed as part of my site configuration, by the time I actually completed my development machine testing, for how I wanted to theme the site, a Drupal security release and a bug-fix release were issued. So a Drupal core upgrade was in order as part of the Drupal configuration process. First on my desktop development machine, then on the A2Hosting shared hosting web sites. Since the shared hosting installs had not yet been customized with add-on modules and themes, the updates were a little less cumbersome than normal. But an interesting part of the development machine update included a problem that appeared in the Backup and Migrate module. I used the module to backup my database prior to the Drupal upgrade. When I tried to backup again, after the upgrade, I was unable to do so because of an error in the Backup and Migrate module that only appeared with the new version of Drupal. Updating that module with a new version fixed the error, but running though the process was another reminder of the work effort that I can look forward to associated with maintaining the site. 😉

Strategy

My general Drupal configuration strategy is to try to be conservative in terms of engineering and security issues and to be evolutionary in terms of functionality and capability.

What this means to me is that unless there is a very special need, I want to only use modules on my public web site that are full production release versions. Alpha, beta and release candidate modules are not considered fully ready for use on production web sites; so I want to avoid using those features until a final module version is released. Since I am using Drupal 7, this limits some of my choices. Some functions that are fully released for Drupal 6 do not yet have final release D7 versions, so I need to find alternatives or hold back on those functions. It also means that I want to stay current on security releases, and I want to install a few extra modules that will help me manage security related issues on the site.

What it also means is that in terms of the public site I want to use an evolutionary approach. If you’ve followed my blog posts you might remember that part of my objective is to be able to support a community of practice web site. But that involves a lot of function and is well beyond where I am now. I wanted to choose a web platform that could grow to that ability, but I don’t need it all now. I just need to initialize something a little more advanced than a simple blogging platform, and then slowly grow the additional functions, as the need develops, over time.

Modules

Core Modules

As I mentioned above the standard Drupal installation profile activates a number of core modules when the system is installed. I used that option because I want most of these modules and it saves time to use the standard profile to activate them. Two exceptions in my case are the core Toolbar and Shortcut modules. Instead I want to use the Administration Menu module. However, at the time I configured my site the Administration Menu module had not yet released a finished version for Drupal 7. Only a Release Candidate version was available. So I left both of these modules activated. Later, when a final Administration Menu module is available, I’ll implement that and disable the Toolbar and Shortcut modules.

In addition to the modules activated as part of the standard profile, I activated the following core modules:

  • Aggregator — This module can gather, read, and display news, text, images, and other content from external news sites and blogs around the internet. Especially as I am getting started, this provides a mechanism for me to establish some community between my content and purpose and others on the internet who are publishing and involved in similar interests and concerns.
  • Blog — Blogging doesn’t really need a special module, but I want to lay a base to support multiple blogs down-stream, if the need develops; and I don’t want to go through the hassle of conversion or style changes at that point. So, I’m going to implement the blog function on my site with the Drupal core Blog module, which supports both single and multi-user blogs.
  • Book — This module provides a mechanism for adding a navigable content type which is more suitable for some of the documentation I want to publish on the site. The standard profile implemented a basic page content type and an article content type, but neither of those includes the automatic navigation functions associated with this feature.
  • Contact — This provides a simple way to build a Contact Page for the site, and provides a feature where registered users will also be able to interact with one another through personal contact pages.
  • Statistics — For a busy, high performance site I have read that this module is not recommended. However, that is a problem I only hope to have at some later date. In the mean time, this will offer an easy, integrated method for me to check statistics about how the site is being used.

Community Modules

The following add-on (community supported) modules were also implemented as part of my initial installation:

  • Backup and Migrate — Simplifies database backup and migration from within the Drupal framework.
  • Chaos Tools — General utility required by a lot of other modules.
  • Comment Notify — Lightweight tool to send notification e-mails to visitors about new, published comments on pages where they have commented. Promotes social aspect of the site.
  • Diff — Allows pretty viewing of all added/changed/deleted words between revisions of node contents.
  • Display Suite — Allows full control over how my content is displayed using a drag and drop interface.
  • Footnotes — Used to create numbered footnote references into book pages, articles or posts.
  • Freelinking — Implements a text filter for the easier creation and management of HTML links to other pages in the site or external sites.
  • Global Redirect — Works with Pathauto to force single clean URLs for each node. (Probably to be replaced by Redirect, which is currently in a beta state for D7.)
  • IMCE — IMCE is an image/file up-loader and browser that supports personal directories and quota. This allows images for use in content to be maintained integral to Drupal content management functionality.
  • IMCE WYSIWYG API Bridge — Allows the IMCE module to be used with the WYSIWYG module.
  • Mollom — Provides spam protection to the Drupal site using an external anti-spam service. I’ve been using the Akismet service to handle comment spam on this (WordPress-based) site and am pleased with how it operates. Mollom is a similar service by the creator of Drupal. I hate spam and a spam filter seems like a hard requirement for me.
  • Nice Menus — Enables drop-down expandable menus.
  • Panels — Drag and drop content manager that lets me visually design a layout and place content within that layout. The focus and purpose are a little different from Display Suite. See a discussion of this in Display Suite vs Panels.
  • Pathauto — Generates URL/path aliases for various kinds of content (nodes, taxonomy terms, users) without requiring the user to manually specify the path alias. This allows me to have URL aliases like /category/my-node-title instead of /node/123.
  • Revisioning — supports management of content under a revision control system, where new and revised content may be viewed and managed between authors and editors and not allowed to be accessed by general users. Once content is approved and published, it then becomes generally available for users. This is very helpful in a group collaboration environment. I’ve also found this useful in a single author environment where I want to have a more professional, controlled management process over what I am publishing.
  • Security Review — A helper module for review of security issues on the site.
  • Taxonomy Access Control — Provides access control (permissions) for user roles based on taxonomy categories (vocabulary, terms). There are multiple schemes available. This is my preferred method after reviewing the alternatives.
  • Token — Tokens are small bits of text that can be placed into larger documents via simple placeholders, like %site-name or [user] and then globally replaced with other values when and wherever they occur. The Token module provides a central API for modules to use these tokens, and expose their own token values.
  • Views — The Views module provides a flexible method for Drupal site designers to control how lists and tables of content, users, taxonomy terms and other data are presented. This tool is essentially a smart query builder that, given enough information, can build the proper query, execute it, and display the results.
  • WYSIWYG — Allows and simplifies the use and management of client-side editors to edit content.

Theme

I’ve played a bit with a few themes in the course of my experimentation with Drupal versus WordPress. Mainly I’ve been looking for something uncomplicated and clean. (Which was also my choice here for this blog.) When I first tried Drupal, and was using D6, I liked the Nitobe theme. However, when I came back to do a more intense WordPress versus Drupal comparison using D7, there was no D7 version available. Even now, as I write this, it is only available as a beta version.

This set me off on a different path. I started looking for something following a theme/sub-theme arrangement. This was something I liked in the WordPress environment. Which led me to Zen and then to the Contented5 sub-theme which I liked, and which I used for a while. I read reviews and discussions,  and more experimentation finally brought me to Omega and a responsive grid layout. I really like the idea of responsive themes which self-adapt to the viewing platform. In the old days it was (just) browsers that were of paramount concern, and maybe looking for fluid versus fixed width capability. How will the content look using IE? Firefox? Chrome? 15″ screens versus 20″ screens versus notebooks. But now we have the platform format issues too, for tablets and phones and who knows what, so the responsive themes make a lot of sense to me.

In terms of responsive themes I was impressed by a review on friendly-machine.com and an interview with Jurriaan Roelofs, the author of the Arctica base-theme and the Respondr premium theme discussed in the review. This is also a responsive framework. I like the overall logic Jurriaan expresses in terms of his design choices and the idea of not just adapting to the size but also the features of the new formats. However, I found some of the components a little confusing and there is a lack of documentation on this theme at this point, so I decided to back away from the bleeding edge in this regard and stick with Omega as the theme for architectedfutures.net, at least for the time being.

Resources

The following links name some of the other resources which I found useful in this stage of implementing the website.

Books

  • Front End Drupal — a great introduction to Drupal theming, but watch for the new D7 edition

Web Links

1 thought on “Drupal Configuration”

Record a reflection ...

This site uses Akismet to reduce spam. Learn how your comment data is processed.