Drupal 7 theming - How to do HTML5 | Valuebound

Drupal 7 theming - How to do HTML5 | Valuebound

Bangalore : India | Jul 11, 2012 at 9:20 PM PDT
Views: Pending
Super Simple PHP File Manager

Submitted by Monalisa Saha on

Wed, 2012-07-11 22:53

In this blog post we’ll be discussing about how to do HTML5 in Drupal 7. Apart from HTML5, we will also cover how to remove some of the generated markup that Drupal provides by default, and how to override default system CSS. We’ll also look at a few tips on how to get some quick-win page speed boosts.Before we probe in deeper, it’s good to mention that this post is not a comprehensive tutorial on building a Drupal 7 theme. For the sake of briefness, we won’t be able to cover the HTML5 Tools module, which helps to add features like new HTML5 form elements to Drupal. Rather than that, we will focus on reducing the superfluous XHTML that Drupal still unconsciously wants to include, as an inheritance from its earlier stages.At the time you first install Drupal, you will be able to see a top-level directory named themes. It is only apparent that you’ll be thinking that this is where you should store your own theme related files. However, in this case, this is wrong. Actually, the directory you want to play in is sites. This is all about you and your particular site, and within this is another themes directory that will be housing your themes.It is important to note that Drupal can handle multiple domains via a single codebase, and thus, the “sites” directory instead of “site,” but we would not be discussing about it in detail, as it is beyond the scope of this article. To know more on this topic, then there’s a Multisite Drupal group that is dedicated to the topic.As a first step, the initial thing to do is to create a *.info file with the name of your theme. Since our site is Valuebound.com, and our theme is aptly named “Valuebound,” our info file is valuebound.info. the following are the contents (”;” comments out a line):If you are familiar with the Drupal themes, then you’d observe that the preceding code is pretty straightforward stuff, there nothing that is too extra-ordinary. Another thing, that you might have noticed is the override directory. Within it are two other directories, kill and keep.We also learned a clever way to get rid of system CSS files that we don’t want. If you name one of your own CSS files the same as one of the defaults, Drupal will include yours rather than providing its own. Thus, everything in the kill directory is just an empty file, whereas everything in the keep directory is a CSS file that’s been only slightly or not modified from its original defaults.So, it’s natural if you are wondering ‘Why bother to have a keep directory at all, if I’m reusing the very same code as the default files it contains? Here’s where it starts to get interesting. When you go to the Performance admin page, and turn on aggregation and compression of CSS files, Drupal will gather up all its default system stylesheets into a single file, and all your stylesheets into another.It may sound silly. But with our keep directory, we force those default stylesheets along with our theme stylesheets, to be aggregated and compressed into one file.One of our old practice from the early CMS days, which we haven’t given up is using Textpattern. This is because for theming purposes we like to know what “section” of the site we are on. Basically, that just means that we’re curious what foobar is equal to, in the following scenarios:http://example.com/foobarhttp://example.com/foobar?page=1http://example.com/foobar/node/search%20termThus, at the beginning of our template.php file, we have a simple function that runs through and gets us the first path fragment in the URL, it does a simple switch/case, and returns a string that becomes the <body> ID.In our template.php file, we have a function called valuebound_process_html_tag. Obviously, if your theme is named “MyTheme” then your function would be named mytheme_process_html_tag. It simply unsets the variables for the type and media attributes on style, link, and script tags.It also clears out CDATA comments, that existed to satisfy the XHTML validator; as anyone hardly served XHTML as application/xhtml+xml. Earlier, even though we all served XHTML as text/html, we still skipped through hoops by adding CDATA comments. But this is not so with HTML5.Actually, the fact is that XHTML always worked fine without the unnecessary code. HTML5 makes this fact official. Below is the comparison between the before and after of what Drupal would normally output by default, followed by the trimmed down result:Although this doesn’t actually apply to HTML5 directly, we decided that while we were mucking about in the template.php file, we might as well add some HTML minification. Essentially, the following code just strips out unnecessary whitespace and line breaks, saving a bit of file size wherever possible. If a page contains a <pre> or <textarea> tag, it is left alone, as to not affect code blocks or text typed in a form.While it is technically possible to make use of HTML5 and RDF together, we have opted to just leave this aspect out of our templates, as you will see shortly. Here, we have simply disabled the RDF module, which is enabled by default.For the most part, Drupal only renders what’s in your templates. However, there are a few areas where it tends to wrap things in <div> tags that you might not want. Thankfully, Drupal’s theme system makes it easy to fix. The following is a list of files that we have created, which contains only the code that is necessary to generate your content, thereby overriding Drupal’s default output.We have also purposefully omitted the closing ?> tag, as it is considered a best practice (by both Drupal and Zend) to not close the <?php tag. Rather than that, the parser realizes the PHP code is finished when it has reached the end of the file. This prevents the accidental insertion of whitespace into a page. (Of course, ?> is still necessary when mixing PHP and HTML within the same file.)It is important to note that the templates that start with “views-” pertain to Views, a third party Drupal module that makes it easy to output lists of content based on various criteria.Note: we have removed $item_attributes from my field.tpl.php file. This is used by the RDF module, and can potentially be utilized by third party modules, to add things like onclick="..." to various elements. We have removed it as we are not using the RDF module, but your mileage may vary, to get further information read more.Though the above mentioned files pertaining to block, field, region, and views are all technically templates, in that they end in *.tpl.php, the crux of the templating system revolves around HTML, page, and node templates.We have listed out the bulk of our template code, below. You may observe that we did not include our page‐‐front.tpl.php file. It is mostly hard coded because it does not change that frequently, with the only dynamic part being recent journal entries.Note: In node.tpl.php, we’ve removed $attributes, $title_attributes, and $content_attributes, used for RDF. For a pristine node.tpl.phpsource.To provide more completeness to the post, we thought that we ought to finish by listing out the contents of my *.inc files, contained within an ‘includes’ directory under assets. While these files could have been simply left in the higher level *.tpl.php files, to ease in maintainability and in an effort to remain obedient to DRY principles, we put them seperately into their own files. By having the file extension *.inc, Drupal knows to disallow direct browsing, so that they can only be used via inclusion in a PHP page.It may seem to be a lot of codes when you first look at it, but keep in mind that’s almost the entire of our site’s theme (aside from CSS and light JavaScript). So, once you just get familiar with its procedure, then you’ll figure out that the Drupal theming system is really not that complicated to understand. And the added advantage is that, you are learning real PHP, not pseudo code.Like everything else that is good, Drupal also may not be perfect, but it does offer extensibility via simple overrides. Hopefully this walkthrough has helped to dismiss the myth that Drupal has a ‘steep learning curve’ or at least tried to make the process seem less intimidating.Valuebound is a leading Drupal Development Company providing Enterprise Drupal web solutions. For more information on Drupal Development, contact us at info@valuebound.com

1 of 3
home.php file
home.php file
From: harmonicagoldfish
drupal is based in India, , India, and is a Stringer on Allvoices.
Report Credibility
  • Clear
  • Share:
  • Share
  • Clear
  • Clear
  • Clear
  • Clear





More From Allvoices

Report Your News Got a similar story?
Add it to the network!

Or add related content to this report

Most Commented Reports

Use of this site is governed by our Terms of Use Agreement and Privacy Policy.

© Allvoices, Inc. 2008-2014. All rights reserved. Powered by PulsePoint.