Web Design & Development Blog


It's official: Drupal 6 will be going the way of the dinosaurs on February 24th, 2016.

Have a look at the official announcement

Sites still running Drupal 6 could continue to do so, but without Drupal community support. This means you'd be on your own when it comes to security issues, patches, and the like. If you're running a dedicated or virtual dedicated server, you can of course continue running PHP 5 but eventually that too will become untenable, because if you have PCI scans the scanner may force you to upgrade PHP, for example.

Updating Drupal 6 to 7 (or 8! is not easy but we have tools in our arsenal to get it done. 


We receive our fair share of RFPs and often have mixed feelings about how to respond to these. All too often such RFPs are just companies or organizations going through the motions, when they may already have an agency selected. Other times the client has done a lot of internal work and stakeholder discussion to get to this stage, but have not yet involve an agency. We feel it's important for clients to know that early involvement of a web agency can be the difference between project failure and success.

Clients often start a project with pre-conceived notions.

By the time clients contact web development agencies, they often will already have formed ideas about problem definition as well as the correct solution. Many times, these are based on incorrect assumptions about the nature of the problem, subsequently exacerbated by deciding on a solution without first asking some important questions. This often takes the form of an RFP (Request for Proposal), which may mean the project is already fairly far along. This is a shame, because it would benefit clients to work with a web development agency earlier on, to define the problems, goals, and scope. Such planning can save a lot of grief later in the process.

Asking the right questions to understand the client's needs:

Following are a few examples of typical issues that come up, and how we might ask questions about these:

Client: “We need this site built with XYZ.” (insert Drupal, WordPress, or Joomla here!)
Us: “Why XYZ rather than {insert other CMS name here}? How did you come to that conclusion?”
(The point of this question is to understand WHY the client selected WordPress. Ideally this decision-making process would involve input from the eventual web developer, who could advise on the merits of one CMS over another.)

Client: “Here is a list of 10 pages we must have in the new menu.”
Us: “Why so many items? Users won’t know what to focus on. We need to cull this list.”
(Often older sites will contain a slew of menu items, which make visitors’ eyes glaze over as they hit their browser’s Back button, or they continue to search your site in frustration. The short answer here is that less is more, and giving visitors fewer choices initially is much better than throwing a dozen of different things on the screen at once.)

Client: “Please make our site SEO-friendly, too.”
Us: “What are your goals, in terms of SEO? Which keywords matter most, and which pages are top priority? Who on your end will be editing content?”
(SEO is not just a one-time technical implementation, but a process. It requires ongoing content addition and editing, so it is as much a workflow training issue as it is a technical implementation issue.)

A project is never just about one goal or one thing.

There is always more than meets the eye, and it is our job as information architects, web developers and project managers to uncover all of those aspects of a project.  

First, we find out what the client believes the problems, needs, and goals to be. Then we set out to uncover items the client may not have considered, or may have overlooked. This can lead to some very different project scopes by the time this discussion is over.

Asking the right questions early on can make the difference between a bloated scope, a lean and mean scope, and a "staged happiness" approach. This helps the client know what their options are, and know that they have considered their options carefully and with sufficient technical input. 


Drupal 8 will be released November 19th. It is currently at rc2 (release candidate two) and there may be one or more additional release candidates before then. 

We have already built a number of sites with Drupal 8, and love it. The code is leaner and meaner, and the administrative interface is much more intuitive and streamlined, and (we think) gives WordPress's UI a run for its money. On top of that, you get the full power of Drupal's content types, fields, and views at your disposal, something WordPress cannot match, though there are some plugins that do similar things.

More details here.


Clients often ask us to set up CSV feeds / exports of views (lists of data). Now that Drupal 8 rc1 is out and we're starting to use Drupal 8 more and more, we're running into more and more requests for CSV export on Drupal 8. 

For example, let's say the site has a page that lists a company's staff directory, and HR wants to be able to download CSV containing all the staff member details for use elsewhere. This is a perfect use case for the Views Data Export module, together with Views. Views is built into Drupal 8 core. 

We can just add that CSV export onto an existing view

As of about one month ago there is now a Drupal 8 port of Views Data Export - have a look here and here. We have used it to put together a basic CSV export display in a Drupal 8 view, and it works as expected. This module is still very much under development, but it is looking quite solid and promising so far.


Coming right on the heels of DrupalCon Barcelona, Drupal 8 release candidate 1 is here!

Drupal 8 comes with many improvements and features, including:

  • Object-oriented backend leveraging Symfony components
  • Built-in configuration management (the Features module)
  • The Views module is now part of Drupal core
  • Theming is much improved now with Twig and MVC separation of logic from design.
  • Multilingual support was given much more attention in this release.

We are already running Drupal 8 on several small client sites and are excited to start adopting it more widely in the near future.

Full details here


We're headed to DrupalCon 2015 in Barcelona - 21-25 September. These are exciting times in Drupal-land, with Drupal 8 at beta 15 and moving steadily towards release. We're excited and hope to see some of you there!


We're happy to announce that we just re-launched dfusetech.com using Drupal. Check it out at http://www.dfusetech.com.


Often multilingual sites will use URLs contructed with non-compliant country region codes. When using Drupal and i18n / Internationalization, this can be a problem since i18n_hreflang relies on the language codes as set (manually) within Drupal by the webmaster. In such situations it could be preferable to resolve this with code rather than changing the URL pattern. 

I just stumbled across this handy tool for generating IANA-compliant hreflang attribute tags;

hreflang Tags Generator Tool

This is useful on multilingual sites that maintain hreflang tags for associating translations with each other. For example, a page might have the following translations:

<link href="/pe/productos/cereales" hreflang="es-pe" rel="alternate" />
<link href="/bo/productos/cereales" hreflang="es-bo" rel="alternate" />

Also handy:

Language Subtag Lookup

IANA Language Subtag Registry

There may be cases where a site has regional sub-sections or country-specific sub-sections using a non-IANA-compliant code, for example http://www.somesite.com/cz. Well, IANA wants this to be cs-cz, but you probably wouldn't want your URL to be http://www.somesite.com/cs-cz. And if you're using a CMS like Drupal (perhaps with the Internationalization module's i18n_hreflang submodule), it would automatically spit out the tag as:

<link href="/cz/somepath/etc/etc" hreflang="cz" rel="alternate" />

.. and that would make IANA sad, and would cause the HTML to not validate in W3C's Validator.

Using the i18n_hreflang submodule (in the i18n_contrib module, actually), you could override this on a case-by-case basis within the "18n_hreflang_init() " function in i18n_hreflang.module. Right after:

foreach($translations as $lang => $translation) {


switch ($lang){
case "pe":
$lang = 'es-pe';
case 'bo':
$lang = 'es-bo';
  case 'cz
$lang = 'cs-cz';
  //etc etc

That overrides the <link> and its hreflang attribute for just a few languages. I did try using a hook in a custom module but could not get it working, so this ended up being a patch of i18n_hreflang.module instead. 

There is another module worth mentioning: Alternate hreflang. We have not used this, but it could achieve similar ends, but may also require some similar custom patching to fully validate. 

I'm not going to provide a patch file for this since the particular code will need to be customized per site on a case-by-case basis anyway.


We're headed to DrupalCon Amsterdam! Excited to see what everyone's working on. 


We are very proud to mention that nnpn.org (National New Play Network) is now in Drupal.org's 'Featured Showcase":

See https://www.drupal.org/node/1708254

To quote Drupal, "Drupal Case Studies are detailed overviews of well-crafted, innovative websites or applications built using Drupal.