Growing Venture Solutions - GVS - clean urls

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.

Build Your Own TinyURL With Drupal AND Everything You Need to Know About Paths in Drupal

Greg — Thu, 29 Jan 2009 01:47:11 +0000

Drupal has some pretty amazing features to handle aliases and aliasing. They are also commonly misunderstood. This article is an attempt to shed some light on how URLs and aliases and redirects work in Drupal which, with the help of some contributed modules, automatically turn a Drupal site into a TinyURL-like service.

It All Starts With the Menu System

Most modules in Drupal have a hook into the menu system which allows them to declare paths to which they will respond. For example, the node module's hook to the menu system allows it to respond to requests for "/node/".

Clean URLs vs. ... Dirty? URLs

Drupal responds to the "q" parameter from the URL. http://growingventuresolutions.com/?q=node/1 tells Drupal to serve up the page for "node/1". Ever since about 2003 Drupal has used features of the web server so that http://growingventuresolutions.com/?q=node/1 can be "rewritten" to http://growingventuresolutions.com/node/1. This is the so-called "Clean URL" which removes the main query parameter from every Drupal page request. Sure, there are still some page requests like for the second page in a list of nodes but they are much less common.

Ever since Drupal 6.x, if your web server supports clean urls then they will be enabled during installation. This is great.

Internal Path vs. Path Alias

In various administration screens and documentation Drupal uses the phrase "internal path" or "system path" or "Drupal path" to mean things like node/1 or taxonomy/term/1. This is in contrast to a path alias like those provided by the Drupal Core Path module. Let me reiterate: Drupal Core Path module. Drupal core lets you create any alias for any system path. On this site about is the alias for node/1.

You can have multiple aliases for one internal path, but it is not recommended. This is confusing, both to your users and search engines, to have the same content available at two paths. The problem is not limited to creating multiple aliases for a single internal path. Even having just the alias and the internal path creates multiple URLs for the same content. For solutions to both of these problems, see below.

Of course you don't want to build your own alias for every path so you use something like Pathauto to create your aliases for you. These are additions to the Drupal core modules, but they simply extend the features of the core Path module.

user/1 vs. members/admin - What does Drupal see?

If you have created an alias (manually or via Pathauto, no difference) so that the internal path of "user/1" is accessible via the alias "members/admin" what does Drupal actually see? The answer depends on the context of the question. For block visibility rules and a few other things, the rules are checked against both "user/1" and "members/admin" to determine which blocks to show. However, the arg function only sees the internal values so that for a user visiting "members/admin" arg(0) is "user" and arg(1) is "1".

Extending Pathauto for Other Things (like Views!)

Pathauto only creates aliases for paths based on the system paths used in Drupal core for nodes, users, and taxonomies. This leaves arbitrary URLs that accept node IDs, user ids, and term IDs without any solution (and by arbitrary URLs I'm of course thinking of Views and Panels. It would be possible to write a plugin to Pathauto that uses the Pathauto API and a little custom code to build aliases for Views or Panels. Unfortunately it is fairly difficult to write such a plugin in a generalized way. That remains a topic for a future blog post...

WWW or no-www

Do you use a www in front of your url or not? This is up to your personal preferences. My advice is that sites focused on less savvy visitors should use the "www" in the front of the domain while the wave of the future is to get rid of www. Regardless of which you choose (and you should choose one) Drupal's core .htaccess file provides an example of how to redirect from one to the other. But, if you want a tiny url, then ommitting it (or at least redirecting it) is a good idea. See this old blog post for more discussion.

Path Redirection and Global R

These two modules that provide some additional benefits for most sites.

Path Redirect allows site admins to create redirects. Unlike aliases, redirects send the visitor to a new page using an HTTP 3xx redirect code. This is a benefit when you want two paths to work for the same content without the duplication problems mentioned earlier. While Path Redirect provides all the 3xx redirects, the most common and recommended one is a 301 redirect. When Path Redirect is installed, Pathauto will present a new "Update action" for situations where a URL changes to create a new alias and redirect from the old alias. This is the recommended configuration.

Global Redirect removes the duplicate content problems created in other parts of Drupal such as the "?q=node/1" vs. "node/1" vs. "about" on this site. You may have noticed earlier that while the links I created in this article pointed to the "Dirty URL" or the "internal path" for the page the browser was redirected to the one true alias for a page. That is the work of the very useful Global Redirect module. It provides several benefits and has very little impact on performance or user interface which makes Global Redirect a "must have" on most every site.

Building a Site-Specific TinyURL Feature with Drupal

There are many sites around the internet like TinyURL or NotLong which provided shortened links to really long urls. Links provide an opportunity for branding and building trust - why outsource this function to third party services when you can build it yourself?

If you made it this far you already know the answer to the question of "how to build tinyurl with Drupal"

Start with a short domain name - maybe one that is a shortened version of your normal name.
Remove the www from the front of it.
Use the "node/nid" url instead of the alias
Celebrate!

For example, this story is also accessible at http://growvs.com/node/243.

From http://growvs.com/node/243 the DNS system forwards to http://growingventuresolutions.com/node/243
From http://growingventuresolutions.com/node/212 you get forwarded to the aliased version of the page by Global Redirect

Yay!

P.S. My thanks to merlin and ezra-g for their reviews of this post.