Web Design / Development


One of the things that makes Drupal a great CMS is the quality and robustness of its modules. Today I wanted to shine a spotlight on the Pathauto module. From Pathauto's project page;

"The Pathauto module automatically generates URL/path aliases for various kinds of content (nodes, taxonomy terms, users) without requiring the user to manually specify the path alias. This allows you to have URL aliases like /category/my-node-title instead of /node/123. The aliases are based upon a "pattern" system that uses tokens which the administrator can change."

Tokens require the Token module, which you'll likely need anyway, because it's required by many modules. You also should really install Redirect, so that whenever an item's URL alias is changed, the system will automatically created a redirect (so you don't start racking up 404 errors). After installing Drupal core, we ALWAYS install Pathauto, Token, and Redirect at a minimum; they are that essential.

Now let's stop and think for a moment why we might want to be able to set URL patterns. Imagine you have a blog and you want to control the URL pattern.

Custom URL patterns in WordPress and Joomla

In WordPress you can adjust the Permalinks, and it does offer an option called Custom Structure with token-like placeholders. This is rather limited though in terms of the available placeholders. You can of course change the slug (a.k.a. alias) for each individidual post/page/category manually, but that's silly to even contemplate on large sites. Long story short, there's no WordPress equivalent for defining across-the-board URL patterns with ease the way that you can with Drupal's Pathauto module.

We have had to deal with URL patterns in Joomla before as well. That can be a frustrating experience on larger sites, because Joomla relies so heavily on its menu system, meaning a page must be in a menu for its URL alias to be set to what you want. You can set up categories and subcategories, which Joomla will use for the generated URLs. There have been attempts at making Joomla's URL structure more customizable (sh404sef comes to mind here), but these are complex and they take over some core functionality, making it incredibly difficult to uninstall should you decide to uninstall it later on. And they never quite offer the same level of control and ease of use that Pathauto does.

Pathauto Example

Let's start with the Pathauto admin screen:

Drupal PathautoThe above screenshot is from Drupal 8, but it's pretty much the same in Drupal 7. It shows a few URL patterns tied to specific content types, followed by a default of [node:title]. This means that if I add a node such as News that has no pattern defined, it will still get an SEO-friendly URL based on its title, so if its title is "My Great News Item", its URL would be "/my-great-news-item". But if it's a picture with title of "Our New Gallery", it would be "/pictures/our-new-gallery". 

Pathauto is really great in combination with Views, specifically Views page displays. In the screenshot above you see we have a content type called Person, with a URL pattern of "bios/[node:title]". We also have a view page display with URL of "/bios". So visitors go to "/bios" and then they click on a bio, and that bio will follow the above URL pattern. Using Pathauto and Views together in this manner we can enforce consistent URL patterns across the site, without forcing editors to think about URLs as they're editing. It just works.

If you want to show 'breadcrumbs' e.g. "Home > Bios > Some Person", the Pathauto/Views combination is particularly useful when combined with Easy Breadcrumb. It relies on your URL patterns for generating its breadcrumbs. 

While we use Pathauto primarily for nodes (content / pages), it can also be used for users, taxonomy, and other Drupal entities. I highly recommend it and consider it essential to any Drupal site.


Engaged learning microsite selected among nearly 13,000 entries

A Rider University microsite has been selected as an Official Honoree for the 20th Annual Webby Awards. The distinction puts Rider in the top 20 percent of nearly 13,000 entries from 66 countries around the world. 

The microsite focuses on engaged learning at Rider, showcasing the multiple ways in which the University creates opportunities for profound learning experiences. The site highlights the opportunities and results of students participating in internships, study abroad, service learning, student/faculty collaboration, the arts and leadership development.

“The engaged learning microsite takes users through a series of high-impact visuals, which include video and interactive storytelling, that portray how our students take part in a vibrant learning community and cultivate the foundation needed for future career and personal success,” says Rider’s director of enrollment digital strategy, Tara Laposa, who oversees every aspect of the website, including design, strategic planning and execution. 

Plethora built this microsite from the ground up and designed its UI with jQuery, CSS, and a responsive layout.


That's right, Drupal 6 is at 'end of life' (EOL). 

Drupal 8 and 7 have both had security patches. Drupal 6 got a final security patch as well.

If your Drupal installation has not been updated in a while, make sure to get it taken care of soon, or drop us a line. 


Our design for EIT Avionics was recently featured on Drupal.org's Featured Showcase. It is currently displayed on the drupal.org home page and as the first item on https://www.drupal.org/case-studies . In our case study we go into detail about the process of building a Drupal 8 site before the full release was out, which certainly posed some challenges. View case study »


Drupal just celebrated a major milestone - its fifteenth birthday!

The Drupal project has grown tremendously over the years and with Drupal 8 it is now 'off the island'. Since its early days, Drupal has held on to its own internal ways of coding and using PHP, but with Drupal 8 this change changed dramatically. Now Drupal uses Composer, OOP, Twig, YAML, and Services to name a few. This new policy of openness will help Drupal grow and improve. It will allow themers to do their thing and coders to do theirs - better than before.

Drupal founder Dries Buytaert's post about Drupal's 15th birthday


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. 


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 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.


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.