Drupal/Joomla Site Owners


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.


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. 


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. 


All too frequently we hear from customers who have handed over the login details for their domain registrar (GoDaddy, NameCheap etc) only to have their web designer transfer the domain to another registrar that is outside the customer's control. The end result is of course that the customer then becomes dependent on that web designer and must beg and plead (and sometimes even pay fees reaching into the hundreds of dollars) just to get control of their own domain again. In a similar vein, many web design companies that also offer (or insist) on hosting your site for you will not provide hosting control panel access. This is a red flag, because it makes it impossible to save a backup of your site, again making you dependent on that web designer / webmaster. Please, at all times make sure you maintain control of your domain name(s)!

If you must provide someone with access to your domain name management area, make sure you have a clear idea of what it is they intend to do with that access. If you're using GoDaddy, you can assign someone as an AccountExec, so that they cannot change the account password on you. However, even with AccountExec access they'd be able to transfer the domain to another registrar if you're not careful.

It's your site: make sure you retain full control over it, even if you don't want to manage it on a daily basis!


A Community Builder plugin that can be displayed as a tab on a user’s personal profile, so each user can have a separate calendar. The user just needs to enter the unique ID of the calendar in the plugin parameters in their profile. You can set a default calendar and time zone, and individual users can set their own time zones and calendars as well. This plugin comes with English and Dutch language files. Tested on Joomla 1.5.14 with Community Builder 1.2.1. It should work with or without legacy mode on. Should function in Joomla 1.0 too, though multilingual functionality probably will not work.

Download it here »