Note: This article is discussing Drupal version 6.11.
Drupal 6 is built to validate as XHTML but I’ve lately been leaning towards HTML standards. I also enjoy making things – Drupal in particular – do what I want them to do, so I just had to see if I could get Drupal to validate as HTML 4.01 Strict.
Since Drupal has a lot of theme override functions, I naturally presumed that it would be a simple task and it was. Well, except for the fact that Drupal core spits out a content-type meta short-tag in the <head> section of the website. But let’s start from the beginning.
The theme basic from Raincity Studios is a starting point for all my projects and I dearly recommend it. The problem I had here was mainly in the <head> section, where Drupal outputs all the tags as short-tags, ending with “/>”. These tags are being printed out with the help of the PHP variables $head and $styles.
So basically, all we need to do is put the following two lines in into the theme_preprocess_page() function of our template.php file, to remove the slash from the end of the tags.
$vars['head'] = str_replace(" />", ">", $vars['head']);
$vars['styles'] = str_replace(" />", ">", $vars['styles']);
Remaining is the content-type problem mentioned above. It turns out there are two Drupal core functions, called drupal_get_html_head() and drupal_final_markup(), in the file /includes/common.inc, which make sure a content-type meta tag is prepended to the <head> section.
The code looks like this and as far as I can tell, there’s no other way of getting rid of this than to do changes to this file.
function drupal_get_html_head() {
$output = "<meta http-equiv=\"Content-Type\" content=\"text/html; charset=utf-8\" />\n";
return $output . drupal_set_html_head();
}
function drupal_final_markup($content) {
// Make sure that the charset is always specified as the first element of the
// head region to prevent encoding-based attacks.
return preg_replace('/<head[^>]*>/i', "\$0\n<meta http-equiv=\"Content-Type\" content=\"text/html; charset=utf-8\" />", $content, 1);
}
So just removing the slash from the string in that function will solve the problem. Changing core code is a bad, bad thing but at least it’s a very minor change and we can still update the site with the only problem being that it again may not validate.
After doing this I had no other problems than contributed modules sometimes outputting XHTML, and very rightfully so since Drupal is based on it. This can often be solved with theme functions. ImageCache, for example, is used by calling a theme function so I Googled it’s API, found the original code and put the following in my template.php…
function mytheme_valid_imagecache($namespace, $path, $alt = '', $title = '', $attributes = NULL) {
if (is_null($attributes)) {
$attributes['class'] = 'imagecache imagecache-'. $namespace;
}
$attributes = drupal_attributes($attributes);
$imagecache_url = imagecache_create_url($namespace, $path);
return '<img src="'. $imagecache_url .'" alt="'. check_plain($alt) .'" title="'. check_plain($title) .'" '. $attributes .'>';
}
…which is an exact replica of the original code but without the slash in the <img> tag. Now I just call this function instead of the ImageCache theme function, and I get valid HTML 4.01 Strict.
I wouldn’t recommend this at all if you’re using more than just a few modules. If you’re using more modules, a lot of ugly changes may have to be made – changes that may also break something if you ever decide to update the site. However, it was a nice experiment for this particular project and I enjoy seeing the wonderful green color when I run the site through the validator.
Maybe time to write a HTMLify module.
Please write a module that works for straight HTML. This way I can use it :)
[…] using some CMS’s this may sometimes be difficult to achieve. While I managed to get Drupal to validate as HTML 4.01 Strict, sometimes people choose to sacrifice validation for, as the mentioned site says, […]