Preparing a Drupal site for efficient support

steve harley — Sat, 11 Apr 2009 13:18:42 +0000

We can support your Drupal site, but first let’s make it right

When we first offered formal Drupal Support services we expected clients would know their site fairly well and need help with advanced administration and/or doing “new” things. In practice, we’ve quickly learned an important lesson about the diversity of Drupal site owners. Some are virtuosos, and need our help with very complex issues. Some have an existing site with major deficiencies, perhaps built by a vendor who is no longer in the picture. Some need some tutoring in Drupal basics, or even the concepts of dynamic websites.

So we have learned to sort out from the start whether clients will need a more intensive initial phase that includes a site review, an assessment of how well administrators and users understand their Drupal site, and quite possibly a detailed site tune-up. Here is how the technical side went with one client …

From the outset, we sensed all of this client’s support hours could be consumed just trying to stay ahead of the ad hoc techniques used in the construction and management of the site. We knew we had to stabilize the situation so the client could get more value from our support — and from their site. We found the site running an older version of Drupal 5 on a Windows IIS host with only FTP (not SFTP nor ssh) access for managing the site. The clients wanted to improve SEO and feel more in control. They weren’t really using Drupal as a content management system.

First steps in Drupal site evaluation

To move forward, and protect their investment in the site, we helped the client to arrange for Linux hosting and planned an upgrade to Drupal 6. In short, this would put them on a version that is easier to support, simplify setup of clean URLs and guarantee availability of security updates beyond the Drupal 7 horizon. Using a Linux host with ssh access is a strong preference for our team; it makes our work for clients more efficient.

We prepared to migrate and upgrade the site by reviewing the site’s:

32 contributed modules,
four custom themes (hacked versions of Garland applied to specific pages via Taxonomy Theme),
structure including menus, content types, views and input filters,
status of existing content, including some content not linked into site navigation at all,
non-Drupal static pages and a Wordpress installation on the same domain, all themed to appear as part of the main site.

Getting a handle on a Drupal site’s modules

Our review found that 20 of the contributed modules had no significant purpose on the site, plus two useful modules weren’t supported for Drupal 6. While the site was functional, under the hood there were overlapping and partially configured modules, as if the previous site builder had left in the middle of some hasty experiments. In some cases we had to query the variable table or the tables associated with a module to be sure whether it was in use.

With all of the unneeded modules gone, we added Token, Pathauto and Global Redirect to set the stage for SEO improvements.

Some modules were needed but not supported in Drupal 6. We replaced Taxonomy Theme with Theme Key, and Tiny MCE with Wysiwyg API configured with the TinyMCE 3 plug-in (per the client’s preference).

Untangling and upgrading Drupal themes

We upgraded the themes to Drupal 6, referring to the Converting 5.x themes to 6.x checklist as well as some tips that simplified the process on Wesley Tanaka’s blog. The themes interacted with Nice Menus via theme_menu_item_link, an API function whose definition has changed sufficiently in Drupal 6 that it no longer suited the purpose. Nice Menus in Drupal 6 has configuration options that bridged the gap. Theme_menu_item_link was still helpful, though, because the Drupal 5 site contained menu entries which linked nowhere, something Drupal 6 doesn’t allow. We addressed this in the theme layer with an approach modeled after this suggestion by tekket.

Once we had sorted through the content and knew which pages were actually live (versus published but not linked from anywhere). We realized one of the themes wasn’t in use at all. Another turned out to only be used when a certain region shouldn’t appear, but that region would suppress itself if no blocks were assigned. So it wasn’t too hard to prune the themes to one for the home page and one more for the rest of the site.

Getting bugs out of the content

Having reviewed and simplified the site configuration, the Drupal 6 upgrade itself went very much by the book. A few of the remaining modules needed a 2.x upgrade while still in Drupal 5 to make ready for Drupal 6. Since the client was making few content changes, the upgraded site could be brought up on the new host and reviewed before changing DNS, simplifying the staging process. Site content upgraded cleanly with a few exceptions. Views import worked, but much of the detail of the views had to be reconstructed anyway.

The menus and some of the content had hard-coded references to pages and images on the site without using relative links or clean URLs, and even sometimes linked by IP address. We used queries into the node_revisions and menu_links tables to find what needed fixing. There were few enough problem nodes that it made the most sense to fix them manually, but Greg made a time-saving suggestion — use a calculation in an ad hoc query to output the complete node/#/edit URL for each node to update. From there (from the mySQL command-line in a Mac OS X iTerm window), I selected the URL from the query output and usied a keyboard shortcut assigned to the Open URL entry in the service menu. Tricks like these can make even a modest manual process take half the time or less.

The result: a smoothly-running Drupal site

None of this work was glamorous, but the result is very satisfying — the site is now in much better shape. The review helped the client know their site better, and we are poised to start doing some real support, such as making the site’s themes more configurable, adding templates to replace some of the static pages and helping the client manage their own content. The site is stable and its configuration will be much more comprehensible should another Drupal pro need to work with it in the future.

Support - Drupal Theme Professionals TopNotchThemes

Greg — Fri, 03 Apr 2009 15:42:40 +0000

Not Your Typical Drupal Support Client

Many support clients are end users of Drupal - they need help with the menu system, and knowing what the heck nodes are.

As the creators of some of the best commercial Drupal themes (and some great free themes as well), TopNotchThemes needs more than basic Drupal support. We've helped them improve their development infrastructure and workflow to make the process of developing great Drupal themes more efficient, and to also enable some upcoming internal and client-facing features. This let's them focus on building great designs for their themes.

Chris Fassnacht was kind enough to say this about working with us:

"GVS has been a valuable addition to our team. It's a relief to have a team of experts we can rely on to keep our Drupal-based infrastructure running smoothly!"

At Drupalcon Steph thanked us with a hug. What more can you ask for from a client?

TopNotchThemes Supports the Drupal Theme Community

In addition to being providers of great themes and a good customer they are also a company that "gets it." Their community involvement speaks for itself (one highlight is this Ubercart theming thread). They are happy to pay for our time knowing that we are working to keep the modules used on their sites well maintained (see Alternative Price and Moneris).

Growing Venture Solutions - GVS - support