Web Design & Development Blog


Drupal 8.4.0-rc1 is available for testing now. Drupal 8.4 is expected to be released October 4.

8.4.x includes new stable modules for storing date and time ranges, displaying form errors inline and managing workflows. It also includes new stable API modules for discovering layout definitions as well as media management. The media API module is new in core, all other new stable modules were previously experimental. This release also includes several important fixes for content revision data integrity, orphan file management and configuration data ordering among other things. 

We have done some initial testing, and have noticed some contributed modules don't play well yet with this release. We had problems with the Superfish module in particular; this module is used on some sites that have dropdown menus. There is an issue in the queue here.


Let's clear up some misconceptions about when to and when NOT to migrate to Drupal 8

I'm writing this post to clear up some misconceptions that we've noticed some website owners have.

We were recently approached by a customer who loved their new responsive Drupal 7 site, but the firm that built it was not being so responsive when it came to ongoing support. The client needed help figuring out everyday tasks like adding photos, video, etc. They also wanted to make some cosmetic improvements, and add a blog. They went shopping around for Drupal support firms, and called us.

During the call, the client let slip that some of the firms they talked to had informed them they would need to move to Drupal 8. I told this customer this is a load of nonsense and a few days later she called back, relieved they would not need to spend a heap of money on migrating to Drupal 8 any time soon. It was surprising and disheartening to hear such bad advice being given to customers. 

Why migrating from Drupal 7 to 8 makes no sense in this case

If you only need some cosmetic changes and maybe a new content type or two, stick with Drupal 7. There's simply no need to switch to 8 for that. Drupal 7 is in LTS (long term support) and won't get new features, but will continue to get bug fixes security support. Drupal 7 will get bug fixes and security support until Drupal 8 becomes the Long Term Support version, and that won't happen until Drupal 9 is in Long Term Support, which won't happen until 2019 or 2020 at the earliest. I would be pretty surprised if it happens as soon as 2019, though.

When would migrating from Drupal 7 to 8 make sense, then?

  • When your site needs major new functionality and not just cosmetic changes.
  • If Drupal 9 LTS is around the corner (2019 or later).
  • If you want to take advantage of Drupal 8's superior offering of functionality, e.g. web services, "features" (a.k.a. Configuration Synchronization), accessibility improvements, improved performance, and more.
  • If you're ready for a major site overhaul. 

Long story short, moving from Drupal 7 to 8 is not a small task, and should only really be considered with sufficient justification. Of course, it would be a good idea to move to Drupal 8 before you become forced to do so due to an impending Drupal 9 release. The good news is that you have a few years to get ready for this, and there is no reason to hastily switch to 8 immediately if your current site is working well for you. 


US Capitol

On January 5th the US Access Board announced that the OMB (Office of Management and Budget) had cleared the Final Rule for ICT (Information and Communication Technology) Standards and Guidelines, a.k.a. the "Section 508 Refresh". The new standards and guidelines were published in the U.S. Federal Register on January 18th and will become effective and enforceable starting January 18th, 2018.

You may be thinking: "What does this mean for our site?"

1. Not all content/code will have to be updated right away, because there is a safe-harbor provision, specifically:

"legacy ICT that complies with the existing 508 Standards and has not been altered after the compliance date (i.e., one year after publication of the final rule) need not be modified or upgraded to conform to the Revised 508 Standards. However, when existing ICT is altered after the compliance date, such alterations must comply with the Revised 508 Standards."  

This means that if only some elements on the page are changed after January 18th, 2018, then only those changed elements need to comply. Any newly added elements will need to fully comply.

2. WCAG AA 2.0 is to be the new standard to follow. Previously WCAG A 2.0 was sufficient, but now you must comply with AA. This applies to all new or altered web, software and electronic documents, and includes digital content delivered to personal computers and mobile devices.

3. The Final Rule includes a provision for situations where some content might technically pass, but in reality be unusable by non-sighted / low-vision web site visitors, web visitors with cognitive disabilities, limited strength or limited manipulation. In such cases alternate content must be provided. This is in line with previous regulations, but is now more explicit as to which situations warrant this, and for what types of users. The Final Rule states that the:

"revised requirements include functional performance criteria, which are outcome-based provisions that apply in two limited instances: when the technical requirements do not address one or more features of ICT or when evaluation of an alternative design or technology is needed under equivalent facilitation"

In other words, in cases where the guidelines don't touch on whatever technology you may be implementing, the situation must be evaluated on a case-by-case basis to ensure the outcome is one that provides ALL web visitors with comparable, if not identical content. For example, if you have a video with narration, it must include closed-captioning or an alternate way for the deaf to to follow along. 

If your company or team is running into Section 508 issues, feel free to get in touch or check out or Section 508 services.


Lately, you may have noticed some sites getting labelled as "Not secure" in Google Chrome:

Google Chrome: Not Secure (SSL)

Or in Firefox:

Firefox not secure - SSL

As of January 2017, Chrome and Mozilla (the makers of Firefox) have implemented this policy to inform people that they should be careful when filling in forms containing sensitive data such as passwords or credit card details. 

In the coming years, the Chrome Security team plans on marking all HTTP (non-SSL) pages (not just login pages or credit card forms) with a red icon indicating the connection is not secure.

You should strongly consider adding SSL to your entire site, and enforcing it site-wide so that any HTTP requests are redirected to HTTPS URLs.

Since 2014 Google has been giving a rankings boost to sites with SSL.

This means that aside from the obvious benefits of increasing security on your site, you can also improve your ranking in the SERPs (search engine results pages) on Google. Other key factors for ranking are mobile-friendliness and speed. Beyond that "content is king" - meaning your site should be an authority on its subject, be updated regularly, and ideally have some other sites with decent PageRank linking to it.  You don't need a zillion inbound links, especially if they're low-quality / low PageRank. Focus on quality content, speed, security, and mobile-friendliness / responsiveness.  

What it takes to add SSL on your site:

1. An SSL Certificate

You will need an SSL certificate. You can buy one from any number of vendors. We like RapidSSL but you can buy these from loads of vendors. Our favorite option, letsencrypt.org, is entirely free, but does require setting up a cron job. That can prove difficult in some hosting environments (e.g. shared hosting). You can buy single, multi-domain, or wildcard certificates. A single certificate will generally work for both yourdomain.com and www.yourdomain.com, but not any other subdomains (such as xyz.yourdomain.com). This option is the most common, and the cheapest.

2. Use 2048-bit key certificates

This refers to the RSA key pair using 2048-bit encryption. A typical SSL certificate would be 2048-bit with 256-bit encryption. Double-check Google recommendation before purchasing a certificate, since these parameters change over time and get continuously more secure.

3. Use TLS 1.2+

Older SSL protocols are considered insecure and will trigger browser security warnings.

4. Use relative URLs for resources that reside on the same secure domain

For example, if you have an image, you'd want to use a path of "/images/some-image.jpg" and not "http://www.mysite.com/images/some-image.jpg". This way you can change to https:// without having to change all those absolute paths to https://. If you're using a CMS such as Drupal, this will often be root-relative already  by default, or it can be configured to be that way. 

You should double-check that your site has no pages with embedded internal resources (images, JavaScript files provided by your domain) that use http://. Change those to root-relative before enabling SSL, or you will get "mixed content" browser warnings.

4. Use https:// URLs for all other domains 

Before switching to SSL, check your site for any embedded JavaScript files, iframes, or other external resources that use http. Change those to https. You could also just use protocol-relative URLs (e.g. "//google.com" rather than "http://google.com"), but then you'd better double-check that the domain being referenced actually has SSL in place. Some third party script providers don't have SSL, and it pays to make sure before switching to SSL.

5. Check out Google's advice on moving your site, since switching from HTTP to HTTPS will be considered a site move by Google. 

If you don't use Google Search Console, check it out. With Search Console you can get a sense of how Google sees your site. Google expects you to set up separate properties for each domain/protocol variation, even though it does consider them to be the same site. For example if your domain is "mysite.com" and you initially built it without SSL, you'd have two properties: mysite.com and www.mysite.com. If you then add SSL, you will need to also add properties for https://www.mysite.com and https://mysite.com. There are options you can set to instruct Google to prefer www over non-www URLs. Google will automatically prefer https, if it finds https. 

6. Make sure your SSL site's robots.txt does not block search engine crawlers

This advice only applies to sites that have different docroots (file paths) for HTTP vs HTTPS versions of the site. For example, you might have the HTTP site at /var/www/html, but the SSL/HTTPS version at /var/www/html_secure. In that case, you will need to check that /var/www/html_secure/robots.txt does not include "Disallow: /" or similar lines.

If you just have a single site (e.g. at /var/www/html), then you should already have a properly formatted robots.txt file in place which does not block search engine crawlers. It should not contain "Disallow: /" or similar lines.

7. Avoid the noindex robots meta tag, and allow indexing of your pages by search engines whenever possible

You can put noindex rules in robots.txt, which is preferable, but not always feasible. 

8. Redirect any HTTP requests to HTTPS

You can and should enforce SSL site-wide so that any HTTP requests are redirected to HTTPS URLs. This can be done using rules in your Apache or Nginx virtual host, or (if using Apache) with .htaccess.


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.


Developing any kind of enterprise site typically involves multiple environments, for example Development, Staging, and Production. A very common scenario developers run into is that a site is developed locally (on the developer's own machine) and then the code changes get pushed to a repository (version control using Git, Subversion, Mercurial, etc). But what about database changes? Those aren't code ... but they can be.

What is considered configuration?

Module configuration (set via Drupal's UI), content types, fields, Site Information settings, basically any kind of settings that you can control from Drupal's UI. Content (nodes, terms, users or any sort of entities) is not part of this and does not get exported.

How to copy configuration from one site to another:

Keep in mind this will only work for the same site, existing in two different environments. The typical way this would go is you create a site in one place (some cloud server e.g. Amazon Ec2, RackSpace CloudServer, Linode, Acquia Cloud, Pantheon, etc), do some initial commits after getting Drupal set up there, and then clone that locally in your computer. There you can go to town and add all the modules and code you want, configure everything, then export it and import it back into the remote dev site.

Before attempting to export your configuration, make sure to commit all your code changes, push them to the repo, and make sure the remote dev environment has pulled those changes. You don't want to try and change settings for modules that don't yet exist in code - that can lead to all kinds of nasty things!

In Drupal 7 this was accomplished using the Features module, which is a pretty complex beast to work with, but very powerful too. The Features module has been made part of Drupal 8 core and is now known as Configuration Synchronization. This can be accessed from the Configuration > Development > Configuration Synchronization menu (/admin/config/development/configuration):

​(Drupal core's admin menu does not have dropdowns by default. Install the Admin Toolbar module for that awesomeness.)

Next, click Export (/admin/config/development/configuration/full/export) you can export:

This gathers up all your settings and downloads a gzipped tarball for you. Now go to your remote dev environment, log into Drupal, and go to Import (/admin/config/development/configuration/full/import):

As you can see, it provides you an overview of the new/changed items it will import. In this case I had added a single text field called "Sample text field" to the Basic Page content type. Click "Import all":

This does not always complete without error. Sometimes it will fail with obscure-looking fatal errors (500 - Internal Server Error), but so far I've found if you re-run the import it will usually complete without further issue. Such errors can be useful for ironing out configuration issues though, so pay attention and see if you can fix whatever is triggering those.

And that's it! My field was created. Here's a screenshot of the Basic Page content type's fields on the remote dev site:

Multiple the above by a zillion for the number of other settings a complex Drupal site can have, and you can see how incredibly useful the Configuration Synchronization in Drupal 8 is. It has made great strides in becoming easy to use. The UI is admittedly very simple, and for a full-site export that's a good thing. If you want more fine-grained control in order to export only certain things, this too is possible. Have a look at /admin/config/development/configuration/single/export:

This allows you to export specific settings, for example for a content type, a field, text format, menu, etc. This does not yet allow you to select multiple such settings and export them together, so you have to either export EVERYTHING or export just one thing at a time. When you do export one item, you'll need to copy the resulting code, then go to the destination site and import a single item... there you can paste this. Make sure you select the same "Configuration type" option from the pulldown menu as when you exported it:

This aspect of Drupal 8 is a real time-saver, and takes a lot of human error out of the equation. We're excited to take advantage of this in our current and upcoming work!


We had added a new term reference field to one of our content types, but it already had an term reference field in place, and had data in it. We needed to populate the new term reference field with the data from the old field, so that we could then delete the old field. 

Had this been a text field, it would have been easy to achieve this using Views, Admin Views (optional), Views Bulk Operations, and Token. Using VBO with "Modify Entity Values" you could then paste a token in the desired text field, and run this on whichever nodes you want - in bulk. Admin Views is a handy way of improving the /admin/content overview, enhancing it with content type and keyword filters with Ajaxy goodness.

Term reference fields don't accept text or tokens that way. In that case we can use VBO's "Execute Arbitrary PHP Script" option, using the following code. 

[This is for Drupal 7]


$node = node_load($entity->nid); 
foreach($node->taxonomy_vocabulary_7[LANGUAGE_NONE] as $tid){ 
  $node->field_campus[LANGUAGE_NONE][0]['tid'] = $tid; 


Since VBO runs this on one node at a time, in bulk, node_load is still decently performant. If you were to do something like this in custom code - without VBO - it would be better to use entity_load() along with entity_save() for some performance gains. Using the above code I was able to get the new field populated with VBO in a matter of minutes, as opposed to manually editing 150 nodes, or doing this some other way (custom SQL query, custom module, etc).


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 »