I have come to the conclusion that the Taxonomy Module is not necessary in Drupal 7 for the vast majority of situations. While there is a lot of built-in functionality and a pre-built view for Taxonomy, the module makes too many assumptions about the way content categorization should function. And overriding the pre-built view for taxonomy terms is never as straightforward as I would like. The last few Drupal 7 sites we have built I have not used Taxonomy at all.
I started this blog post to sway Firefox users to give Chrome a try as their primary development browser. I discovered there are almost no differences now. The only reason I switched to Chrome a few years ago was speed compared to Firefox at the time. Today, that is not an issue. In fact, I just did an informal test on my machine and both browsers started in less than 2 seconds. Also, I can't tell a difference in page render times now.
It is a common requirement on a marketing website to have a “Featured Content” block on the homepage that displays some random node from a subset of content that has been flagged as featured. There are a number of modules that try to address this type of functionality, but I’m always a fan of using fewer modules — or at least using modules that can be used in many places.
The day has come to stop focusing on Internet Explorer's limitations and start focusing on the other browsers that allow CSS3. It takes very little extra time, and you can add some sizzle with just a few extras in your CSS.
Yesterday my job was to migrate content from an old Drupal 4.7 site into a fresh new installation of Drupal 7. In this post I will outline the basic process for completing that task. This will not be an exhaustive walk-through, but I hope it helps someone else and serves as a reminder a few months from now when I may need to do this again for another client.
When it comes to font sizing on a website, the debate between accessibility and control rages on. The control camp prefers px font-sizes to maintain the look of the site, and the accessibility crowd prefers em to allow font scaling in the browser.
Most Drupal 7 base themes are built using ems but since the em unit is based on the parent elements font-size, dealing with the compounding of ems in nested elements can be a real pain for front-end developers. When building a list it’s likely that you’ll have an <li> nested in another <li>. If you’ve declared the <li> font-size of 1.2em then the inner <li> will be 1.2emX1.2em, and so on an so on. The math can get complicated and frustrating.
If you want your Drupal 7 site to have a easy user interface with unique effects, you will likely need to add presentational javascript/jQuery to your theme at some point. There are two situations where we might need to add some presentational javascript that each require a different approach:
Back in September, I wrote a blog post about making Mega Menus in Drupal. After publishing the post I found numerous issues with the proposed method and ended up using another method on the project that precipitated the article. After recently receiving a few comments on the original post I realized that it was time for a followup.
Overriding the output of an individual field on a node can be done by overriding the node template, but it sure does feel like overkill for just one field. Sometimes it would be great to just override the field itself without touching the field values in the database.
Overriding a template file is relatively common task for a front-end developer, but depending on the base theme used it’s not always clear how to go about doing it.
