Web Design & Development Blog


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.


SourcingLine identifies top Drupal development firms and displays independent customer reviews.

We're happy to be listed as a Market Leader as of today, and supremely grateful for our customers' glowing reviews. 


WordPress is great - we love it and gladly support it. But ... at a certain point it can become difficult to customize things. We consider using Drupal when we sense a customer is likely to exceed WordPress's capabilities, or if WordPress is going to start to become a pain to customize, or if there's a fair chance of needing to customize more things as time goes on. If it's going to be just a basic static site + blog posts forever, WordPress could be just fine. It wouldn't save much in terms of development time though, because getting things set up correctly with WordPress requires more grunt-work / custom coding than we're used to with Drupal. It would be mostly a wash. Some items, like automatic URL redirects, might not even be deliverable in a reliable way if we went the WordPress route. There certainly are WordPress plugins out there such as Simple 301 Redirects that would handle that, but we'm pretty wary of those 3rd-party plugins (having been burned one too many times by some that seemed nice but ended up buggy) and have more faith in the community-tested Drupal modules. 

WordPress: Pros: great admin interface, easy to set up. Cons: not terribly granular, and extending its capabilities requires a mix of plugins, which can lead to problems. 

Drupal 7: Pros: good admin inteface (can be made great), very extensible, modules ("add-ons") are very well-tested by the Drupal community. Cons:  harder to set up and configure than WordPress, theming usually involves custom theming, more resource-intsensive.

I can write a lot about the benefits of Drupal over WordPress .... but here are some things that come to mind:

- If the concern is with the editing experience, I think Drupal 7's interface is quite nice, and compares favorably with WordPress. It has some advantages even, in that it can be customized for each client's particular needs. Frequently accessed items could be added to the shortcuts bar, for example. 
- the URLs. WordPress just has one URL pattern (automatic URLs) you can follow ... one for blog posts and then another for pages. With Drupal you can set automatic URLs for news items, regular pages, blog posts, and any other content types you might need. This lets us automate content creation to a greater degree. Pathauto is the module for this. 

- content types; WordPress just knows pages and posts. Adding custom fields is a pain. Drupal enables us to create custom content types and decide exactly which fields we need for each of these, and we can control the layout of these through an admin UI as well - no need to custom-code these except in unusual circumstances.
- Fields; we can set up custom content fields and can specify these as image fields, simple text fields, editor text fields, file fields, etc etc. WordPress doesn't come close to this level of detail, and I think it's a level of detail you are likely to need. Doing this the WordPress way would involve too many workarounds and dodgy plugins. The core fields functionality in WordPress just seems too limiting, and Advanced Custom Fields seems like overkill when all you needs is a few certain kinds of fields. You can add a field to one page, but reusing it across pages. WordPress 3.0 core builds on custom posts / fields, but Drupal builds on a more relational approach, allowing filtering, sorting, and so on. Good luck doing that with WordPress without hacks and various plugins.
- Blocks (called "widgets" in WordPress). In Drupal these can be assigned to specific pages simply by editing the block and entering the internal URLs to those pages.. so for example you could assign a block to "blog" as well as all blog sub-pages ("blog/*").  Just try assigning a widget to just one specific page in WordPress. You can't. You have to use a plugin and some shortcode. I think the WordPress shortcodes are a major pain and not the easy method they're touted as , and want top keep customers from having to deal with any code at all, even shortcodes.
- Forms. WordPress's forms (contact forms, other forms), can be a pain to set up and manage. It's all handled by 3rd party plugins, whereas Drupal has https://drupal.org/project/webform, which is well-supported and robust. It lets you configure email confirmations and it also stores submissions in the database, so you can download an Excel file of submissions for each form. It's also possible to integrate it with other parts of Drupal or with 3rd-party tools like Salesforce, can handle online payments (for example for services, event registrations etc), multilingual forms, and much more. See https://drupal.org/node/1526208 for a list of various addons for Webform. It gives an idea of how well-supported it is.
- If you might need 'private' areas of the site later on, this is much better handled by Drupal than WordPress. This could include customer login areas. There are WordPress plugins that can do this, but I've not seen them be very reliable.
- The WordPress page/post editor is alright, but Drupal's can be set up to work better than that. For example, if you wanted to link to an internal WordPress page, you'd have to paste the URL manually. With Drupal you can enter part of the page title and it will auto-fill the URL for you. 
- Drupal handles URL redirects better. If you have a page and you change its URL, Drupal will create a "301 redirect" automatically. This prevents 404 errors and the like. 
- Drupal handles some SEO matters better too, when configured correctly, including RDF (which is becoming more important to SEO), meta tags, canonical links, automated meta descriptions (which can be overridden per page), and automatic ALT tags for some images. 
- Drupal's HTML output is much more style-able as far as CSS goes. We can get much more specific with how we style certain things than we could ever get with WordPress. For example, if you have a blog post or news item with a date, WordPress might provide a CSS class for it, or it might not; it depends on the theme, and if it isn't there, adding it is a pain. Drupal provides this by default. So for example if you needed to, say, style a certain side block on a certain page to look different from the other side blocks, we could do that quite easily, but doing that with WordPress would be difficult. 
- We've never had a Drupal site hacked... Joomla and WordPress on the other hand tend to be somewhat vulnerable to that, and part of that is the quality of the code isn't quite to Drupal's level. 
- Drupal is capable of incorporating integrations with 3rd party apps to a great degree. So for example if you wanted to start a video page / video blog, we could make a video content type, a video page, and then you could just click "Add Content > Video", paste in a YouTube URL, give it a title (for internal reference), and that's it. The site would automatically generate the YouTube / Vimeo / other embed code for you, mobile-friendly. That sort of thing might take 2-4 hrs to set up and style, max, including RSS feed. With Wordpress it would be 8-12 if you're lucky. 
- Drupal can handle insertion of large megapixel images into content; it will automatically scale them down to proper web / mobile resolution. Again, there are also WordPress plugins for this but they're not as battle-tested as Drupal's in my humble opinion. 
- Want to be able to add a slideshow to a page and have loads of display options? Drupal's got WordPress beat; we could simply add an image field that lets you upload multiple images, and then we can configure it to show as a fading slideshow or many different kinds of image slideshows. WordPress just has a few basic options with clickable thumbnails, but again, there are plugins out there that can probably do similar things to what Drupal does... I just hate how fragmented the UI gets with WordPress because ultimately each plugin will often get its own UI, distinct from the WordPress UI. This is all more unified and consistent in Drupal. 
- Permissions / roles. Drupal has a detailed and extensive permissions system. You could for example create a "Customer" role and set it up so users who are assigned this role could access some private content on the site, visible only to customers, or even visible only to that particular customer. I couldn't consider using WordPress for something like that. 
Long story short, WordPress has a great admin UI, but falls short in terms of granular control over things like content types, fields, permissions, advanced SEO settings, etc. Case in point is that this time last year, we ran a WordPress blog for Plethora Design, focusing heavily on Drupal / Northern Virginia. It did OK and got us traffic, and got us visible on Google page 5 or so, but two months ago we redesigned our entire site and merged the blog into it, all using Drupal, and now we're on page 1 (#6) on Google  for "drupal virginia" .. only the second company listed. I believe the speed optimizations and extra SEO customization played a role in this.


  • Pretty, easy to use, great for blogs and basic sites that don't need too much customization.
  • Has a good built-in SEF URLs (search engine friendly URLs) system that's easy to configure and use, as long as you are coo with the same URL pattern for all blog posts / pages.
  • Many plugins that can extend its functionality. However, the best WordPress installations rely on < 10 plugins. More than that and you're likely to face some upgrade issues eventually. Choose your plugins wisely.
  • Automatic updates. This is a great feature; just make sure you also have a backup system in place in case the automatic upgrade breaks your site. We haven't seen it happen yet, but it could.
  • Mobile-friendly admin interface and tons of responsive themes
  • Again, it offers loads of plugins and themes, but many of these are commercial and require commercial support. 


  • Version 3+ is pretty, pretty easy to use
  • Can be used as a CMS (mainly) but also for blogging.
  • The URL aliasing system still leaves something to be desired. This can be partly overcome with addons like sh404SEF.
  • Mobile-friendly admin interface and a decent selection of responsive templates
  • Joomla itself is free, but many of the best add-ons are commercial, and require subscriptions in order to keep them secure and up to date. You should be using the best commercial addons because there are many shady third-party add-ons out there, and while free, they will cost you much more in the long run because they will wreak havoc on your site during your next major upgrade. Choose your Joomla extensions wisely!


  • Its name is Dutch, meaning "water drop". So that's an advantage over WordPress or Joomla right there. Admittedly, we're biased. Plethora Design's founder, Casper Voogt, was born in Amsterdam. 
  • Super extensible. At its core is a system of content "types" and fields, so you can design your own content types, whether it's for news, blog posts, products, user profiles, and so on. 
  • It has Views. Here at Plethora Design we LOVE Views. And it ships as part of Drupal 8's core! You might be wondering what this is. It's a query builder that comes with many display options. You can display a list of content as a table, responsive divs, bulleted list, slideshow, iCal feed, CSV export, and so on. This allows you to reuse content items in a myriad ways, all the while exercising full control over the code output, so that you can style specific content fields discretely. Joomla and Wordpress, by and large, do not offer this granular level of control. It can be added, but takes custom coding to accomplish in most cases. 
  • Features an awesome ACL / permissions system. It is incredibly granular, such that every add-on can add its own specific permissions as it sees fit. Joomla 2.5 and 3 offer similar ACL controls, though these have been baked into Drupal for over a decade, whereas Joomla is still absorbing these new features.
  • A critique of Drupal has long been its seeming lack of good themes when compared to WordPress and Joomla. This is partly true, because Drupal is more developer and enterprise oriented, so there is a certain expectation that the functionality and theme will be custom-built or at least heavily customized. As such, there are not many commercial ready-made Drupal themes out there, but there are some truly wonderful "base themes" such as Zen and Omega, which are the only ones we work with on Drupal sites. The beauty of using such frameworks is that the framework is free, and enables you to leverage a community of many thousands of dedicated developers, versus relying on a commercial entity to provide support. It's a great choice if you need to exercise a great deal of control over layout, but don't want to reinvent the wheel. All the bells and whistles you might see on WordPress and Joomla sites can be done with Drupal, and then some. It's just that Drupal is geared more towards those who have a need to heavily customize workflows, content types, layouts, and so on.
  • Out of the three, Drupal has the strictest coding standards. It has unit tests and processes in place that modules (add-ons) must pass before they are approved for general use. There is a spirited community that reviews modules, and as a result Drupal modules tend to be capable of more robust functionality than many (not all!) Joomla / WordPress add-ons. And if you don't like some aspect of the user interface you have the freedom to change it. As they say in Drupal-land, "there's a module for that". 
  • Debugging Drupal modules is more straightforward. This speaks to how Drupal attracts more developers than either Joomla or WordPress. Drupal has automated testing and patch testing in place to ensure code is up to snuff. This avoids much of the ridiculous forum discusssions on Joomla and WordPress forums, which often involve hard-to-reproduce issues which are subsequently no tracked as bugs. With Drupal, the default position is to track issues as bugs and resolve the in a an orderly fashion that benefits the community at large.

OK, let's be honest. We favor Drupal. But Joomla and WordPress can be very good choices for some projects, and we do recommend these for new projects all the time. When planning a project, just make sure to plan for eventual 'enhancements' and extra functionality, because more often tban not these things will happen.

Out of the three, Drupal may have the highest learning curve, but it does offer the most flexibility in terms of handling any complex requirement you may throw its way. For even greater flexibility you could build your own home-grown CMS, and in many ways that is what Django does, but that is for another post.


This post is probably not news to some readers, but could come in handy for others.

Ever used Drush? If you manage a Drupal site, you ought to. It makes installing modules, clearing the cache, and other tasks much easier. 

Say you want to install a module. You could do this:

#: drush dl somemodule

#: drush en -y somemodule

.. but that's two steps. It could be done faster like this:

#: drush en -y somemodule

This works in Drush version 5.9 but not 5.6. I have not had occasion to test with 5.7 or 5.8 and don't know in which version this was introduced.

Drush is psychic and knows that what you REALLY want is to A) download this module and B) install it. It already knows you want to sa "yes" to enabling it since the command includes "-y" in it, so it's not psychic on that count. So.... this one command will download AND enable the module. If you do a lot of module installation, this can save LOTS of typing.


We've been revamping some customer Joomla sites, moving them from Joomla 1.5 to 3.2. The migration process means a move to Joomla 2.5 and a subsequent move to 3.2. It's a bear, but it's worth it. Joomla 3.2's admin interface is far superior to even Joomla 2.5's. I personally LOVE the Isis administrative template. It's mobile-friendly, and pretty intuitive. Much of the mundane, repetitive work of managing articles, modules, etc. is now much easier. Batch processing has been made available throughout.

Now the bad: if you want to be able to add custom content fields you will still need to use something like K2 (getk2.org), Zoo, Seblod, etc... see http://extensions.joomla.org/extensions/authoring-a-content/content-construction. K2 is the only one we have used and could recommend. The lack of CCK within Joomla core is indicative of Joomla being more of an out-of-the-box CMS than a 'framework'. Drupal has had CCK built-in since its inception, and has very powerful entity handling for individual fields. Each field can be formatted and displayed differently, and this can be done via an admin interface (using default Structure > Content Type > Display, or using Display Suite), or by custom-coding the display in your template (TPL) files, or using custom display formatters (plugins). You can even combine data from several fields into one, using Computed Field.

Drupal 8 is still in the works, and promises full mobile support as well as editing-in-place, with no need for page refreshes. If you don't want to wait for eight, you can install the Edit module .. see https://drupal.org/project/edit. I'm not yet sure how this interacts with the Autosave module; it may not save auto-saves the same way as before.