Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Jan 18 2018
Jan 18

During the redesign process of a website, there are many small changes that can ultimately affect the traffic of the new site. The key is to identify any changes that might break SEO, or changes that might affect the way the site looks to search engine spiders ahead of time to avoid traffic drops. In the end, we want the site to look fresh and new while still getting the same traffic, or more, as the old design. 

At Zivtech, we look at many factors in the planning phase of a website redesign project and try to identify those that could cause drops in traffic after the new design is launched. Once these have been identified, we ensure all of these tasks have been completed before launch. Let’s take a look at some of these factors and how to avoid traffic drops on your next website redesign project.

Meta Tags

We typically build sites with Drupal, so the Metatag module handles much of the meta tag configuration and display on the site. If you aren’t using Drupal though, there could be some changes to your front-end design that could affect your meta tags and confuse search engine spiders. You’ll need to make sure that all of your pages have meta tags and that there aren’t any duplicates. 

Broken Links

Broken links are a huge problem during website redesigns. This could be a result of changes in the menu structure or in path structures for content types. Broken links mean that users and search engines can’t find the pages they’re looking for, which can really wreak havoc on your site traffic statistics. 

To avoid broken links in Drupal, we can use the Link checker module, but there are also third party tools that can be used for non-Drupal sites. Google Search Console provides some additional tools to identify broken links and 404 pages too.

404 page

URL Redirects

Broken redirects or missing redirects to new URLs are also a big problem on site redesigns. These typically happen due to changes in URL patterns or menu structures. The Redirect module in Drupal provides an interface to add redirects for your pages without any coding experience. Non-Drupal sites can use .htaccess files or redirect statements in their web server configuration to ensure that all URLs that are changing have proper 301 redirects.

XML Sitemap

As URLs are changed on your site during a redesign, you’ll want to ensure that the XML sitemap has updated URLs that match the new ones. The XML sitemap module handles this for us on a Drupal site. 

If you aren’t running Drupal, a plugin for your CMS may handle this, or you’ll need to generate a new sitemap using third party tools. Once this has been completed, you can log in to Google Search Console and resubmit your sitemap for indexing.

Google Analytics

If you forget to place your Google Analytics tracking code in your new site’s markup before launch, you can end up in the dark when it comes to traffic fluctuations. The Google Analytics module handles the placement of this tracking code on a Drupal website, and even provides a status warning on the Drupal status page if the tracking ID has not been configured yet. 

Those who aren’t using Drupal should follow the instructions provided by Google Analytics to place the code snippet in their site’s markup, or use a plugin provided by their CMS of choice. With the Google Analytics tracking code in place, your organization can get a much better overview of how your site performs after the redesign launches. It’s much easier to track your successes or failures in your redesign if you were already running Google Analytics, but a relaunch is a great time to start using it too. 

While the factors in this post are some of the most important that we look at during a site redesign project at Zivtech, each project is unique and could require additional changes to your site to ensure you avoid traffic drops after launching your new design. 

Overall, you want to identify any changes that could affect URLs, meta data, and even content structure that search engine spiders or your visitors might be confused about. Even small changes or a missing meta tag can affect your search engine rankings, which can lead to traffic drops. Do your future self a favor and make a list of the individual factors that could affect your site. Then ensure that list is completed before calling your next website redesign a success.

Apr 08 2016
Apr 08

Those of you who still have a Drupal 6 site are by now aware that you need to do something with it since this version is no longer supported.  Your options in short are:

  • Upgrade to Drupal 7
  • Upgrade to Drupal 8
  • Choose one of several options to limit your vulnerability (e.g. convert the site into a static HTML website, or close logins to all but a handful of trusted people and harden the security of the login form)

But that’s a big decision.  What do you do until you’ve decided which path to choose?  Now that Drupal 6 is past its sunset date, is your site suddenly vulnerable to having its data stolen and being turned into a spam factory?

The short answer

As long as you have someone keeping an eye on the security of your site, you’re just fine.  Take some time to make your decision — just don’t wait too long.

Interested in our Drupal security services?  Contact us to find out more.

The long answer

The long answer is a bit more nuanced.  When the Drupal 6 end-of-life was approaching, the Drupal Security Team asked for vendors to apply to become recognized as official Drupal 6 Long Term Service Vendors.  These LTS vendors have clients running Drupal 6 websites.  As security vulnerabilities are found and fixed in Drupal 7 (and Drupal 7 modules) the vendors are committing to make those same fixes to the Drupal 6 versions, but only for the modules that their clients are using.  

That exception has significance for other Drupal 6 sites and it all boils down to the question of:

How much security is enough?  

Low risk websites

Many (most?) websites only need to be worried about automated security attacks: Villains and mischief makers will try to attack every website on the Internet using every known vulnerability.  A tiny fraction  of the time they’ll be successful and turn a website into a spam factory, or virus spreader.  If they do their work well the site owner won’t even notice.  There’s a very low success rate, but there’s a billion websites out there.  You do the math.

High risk websites

Other websites have to worry about someone trying to actively hack their website.  There’s usually three possible reasons for this:

  • Your website has information worth stealing — Maybe your site has an e-commerce component, or a database of hundreds of thousands of membership records (with full names and e-mail addresses).
  • Your website has a lot of visitors — This is really just a subset of the first point.  If someone could infect all those visitors with a virus they could make a lot of money.
  • Someone wants to shut your website down — Maybe your organization has a political bent that some people strongly disagree with.

So what does this mean for my Drupal 6 site?

If your site is in the low risk category, then nefarious individuals will be using the vulnerabilities fixed by the LTS vendors in their automated attacks.  As long as your site continues to be updated with these fixes you are probably fine.  

There is still some risk if:

  • your site runs a module that the LTS vendors do not support,
  • and a vulnerability is found in the Drupal 7 version of that module,
  • and that vulnerability exists identically on the Drupal 6 version.

That’s possibly enough “ifs” to keep the risk at an acceptable level.

Also be aware that this support won’t last forever.  As more sites get off of Drupal 6, the LTS Vendors will have fewer clients paying for those services, and the number of supported modules will diminish.  Eventually your Drupal 6 site could be the last one standing with no one looking out for it.  How long this support is “good enough” is impossible to say.

If your site is in the high risk category, then you need to take a more active role in preventing successful attacks.  You could:

  • Move the information worth stealing somewhere else.
  • Move your site off of Drupal 6 faster.
  • Become a client of a Drupal 6 LTS Vendor to ensure that all of your modules are supported (not just the ones that other LTS Vendor clients happen to be using).

If you need help figuring out what you need, just contact us.

Photo by Billie Grace Ward

Nov 06 2015
Nov 06

The Northwest Atlantic Marine Alliance (NAMA) advocates for healthy marine ecosystems. Through their site, namanet.org, they organize and promote a movement toward a thriving ocean and a just seafood system.

Having helped create the original Drupal 6 site for NAMA in 2008, it’s been a rewarding experience re-architecting it in Drupal 8 (beta). The main purpose of the project, at least initially, was to help NAMA plan for how to deal with their soon-to-be-end-of-lifed D6 site by upgrading it to D7. As a fully matured platform, this upgrade (or migration) path has long been the recommended approach, even since talk of a release candidate began in the summer of ’15, when the number of critical issues neared zero.

Choosing an upgrade path – Drupal 7 vs Drupal 8

NAMA was the perfect client to test out a Drupal 8 upgrade. They were flexible about their design and functional requirements, and the original site was straightforward in its architecture. As the betas ticked up in number, it became feasible to consider skipping over D7 to go straight to D8 instead. Once the D6->D8 migration path appeared ready to use, we discussed the pros and cons with NAMA and, together, decided to go for it.

By structuring the project to partially include “internal” and “personal development” time, we were able to deliver the new site on a tight budget while allowing the entire team to gain crucial experience with the upcoming version of our CMS/framework of choice.

The Drupal 8 advantage

While NAMA will enjoy many secondary benefits to having a D8 site, like a responsive front-end and in-place WYSIWYG editing, the most meaningful advantage of NAMA skipping D7 for D8 is the significantly extended lifespan of their redeveloped site. For Advomatic, apart from getting to work with a shiny new Drupal toy, we’re now prepared to hit the ground running when the full release of D8 is ready, and to support the sea of Drupal 6 sites that will soon be in need of migration help.

NAMA's coordinating director, Niaz Dorry.

NAMA’s coordinating director, Niaz Dorry.

As we wrapped up our final tickets and NAMA began working with their new site, I asked Coordinating Director Niaz Dorry to chat with me about their experience with Drupal 8 so far.

When asked about her favorite features of the new site, Niaz noted that it was, “clean, open, uncluttered, more modern, and (so far) appears to be easier to edit.” She also detailed some of the new configurable components we added to the homepage, which leverage the fieldability of D8’s upgraded Block module.

Niaz added that the move to the new site has been fairly seamless from an administrator’s perspective. The ease of this process is largely due to content creation and usability improvements that have been incorporated into D8 core: 

“The transition seems smooth so far. Generally speaking, the two sites feel similar. What is different is not THAT different, and we seem to be learning it pretty quickly.”

And what about the tradeoffs of working with not-quite-ready software, when a robust ecosystem has been developing around its predecessor for years? At the outset of the project, we’d discussed – in theory – what sacrifices might need to be made. But in practice, what diminished functionality did they end up having to live with?

“Not much, really. Some of the things that are not ready yet – like a better date module – don’t appear to be showstoppers. We knew what we were going into, and that there would be some adjustments to things as Drupal 8 goes from Beta to fully operational. So nothing has been a surprise.”

Niaz eloquently summarizes how this project has been a big win for everyone involved:

“We’re glad to have had this opportunity to work with Advomatic. The results – an updated website for us, experience with Drupal 8 for Advomatic, and contributing to the broader cyber community as we learn – are truly a win-win-win, and that’s the kind of effort we like to engage with, whether it’s our program work, our policy work, the way we run our organization, and now even the way we build our website.”

Have you had a chance to work with a client on a D8 project yet? What do they think so far?

Oct 27 2015
Oct 27

I will be writing a series of article on Drupal-8 Headless. This article will focus on simple headless hello world. We will first learn how to create a Hello World Module in Drupal-8. Oh! but this hello world page will return JSON Data :-) Then we will be creating a NodeJS+Express project which consume the JSON data from Drupal and display it.

Node JS

It’s like Apache server for PHP. Just like Drupal Application needs Apache or Nginx. For running a Javascript Application on Server we require Node JS to be installed. Read more about installing and using Node JS.

Express JS

Express JS is a server side Javascript framework that provides features including server side routing, MVC, etc.

  1. Install a standard drupal-8 profile

    Hello Drupal

  2. Create hello world module
    Create a helloworld folder in modules directory.
    Create a file name helloworld.info.yml with content
    Create a file name helloworld.routing.yml with content
    name: helloworld
    type: module
    description: Hello World JSON Return
    core: 8.x
    package: Other
    Create new directories src and src/Controller. Create file src/Controller/DefaultController.php with below code
    headers->set('Content-Type', 'application/json');
        return $response;
  3. Enable the Hello World Module in Drupal
  4. Create a new Node Project (say meand8)
    From your terminal type:
    $ mkdir meand8
    $ cd meand8
    $ npm init # initiate the node project. Choose all default options. 
    $ npm install express —save # add dependency on express js.
    It will create a file named package.json with content similar to:
    "name": "meand8",
    "version": "1.0.0",
    "description": "",
    "main": "index.js",
    "scripts": {
    "test": "echo \"Error: no test specified\"&& exit 1"
    "author": "",
    "license": "ISC",
    "dependencies": {
    "express": "^4.13.3",

    Create new file index.js with following content

    var express = require('express');
    var http = require('http');
    var app = express();
    var http = require('http');
    /* Assuming that you can access your drupal via http://localhost/d8 
    Make a http get request to drupal hello world page, that returns a JSON */
    http.get("http://localhost/d8/helloworld", function(res) {
      console.log("Got response: " + res.statusCode);
      res.on("data", function(chunk) {
        http_req = "" + chunk;
    }).on('error', function(e) {
      console.log("Got error: " + e.message);
    /*Create the landing page of Express JS App and return the Content from Drupal Hello World Page
    app.get('/', function(req, res) {
    console.log('Listening on port 3000...');
  5. Start your node server
    In terminal type
    $ node index.js
    Listening on port 3000...
    Got response: 200
  6. Check in browser http://localhost:3000

    Hello World Angular JS getting data from Drupal


Ankit Babbar's picture

Ankit has been a Drupal developer for more than 4 years and also has extensive experience with cloud services from Digital Ocean, AWS, Rackspace, Google Compute Engine.
Oct 15 2015
Oct 15

Drupal’s power lies in its flexibility, and the fact that developers can create complex content models. An admin interface helps developers manipulate the backend content repository, to reflect changes in the front-end framework, and vice-versa. This tight coupling between the frontend and backend have been used to develop some of the best websites, e-commerce applications and web-apps. Over the years, Drupal has emerged as a very powerful framework.

However, this approach was more relevant a decade ago when mobile applications were still in their infancy, and when enterprise applications worked in silos without too much interaction between them. But a lot has changed since then. Today, the mobile web is changing the way business is done. Simply replicating a part of the desktop application on a mobile app is not only costly, but also robs the app of its power. A more efficient and cost-effective approach is to have the backend content repository deliver content to a variety of powerful applications working on various devices. This means, a single backend Drupal CMS should be able to push content to a mobile app, and any other enterprise application at the same time. Using Drupal in this way is what we call “Headless Drupal”.

The necessity of such ‘cross-platform publishing’ is what is driving the popularity of Headless Drupal or decoupling of the backend CMS from the front-end framework. But this is not the only reason Headless Drupal is relevant but equally important is the fact that creating unique user-experience is differentiation strategy for business organizations.

A whole new set of front-end technologies have emerged using which we can create faster, responsive and interactive apps that offer a rich experience to the end-user. Front-end developers need not know the intricacies of backend drupal programming and still they can harness the power of Drupal’s powerful content-modeling capabilities, and its equally effective editing interface.

So how is Headless Drupal different from regular coupled CMS systems?

A traditional CMS has three components to it:

  1. The database which stores and maintains the content
  2. An admin interface that editors can be use to manage the content models in the database
  3. The templating layer: basically front-end that is use to implement unique look and feel for the website

In a Headless Drupal website or web-app, the content for the site/app is accessed using an API through formats such as JSON or REST. And front end specific application framework like Angular, Backbone, Ember or Knockout delivers the API output onto the front-end template layer. We do not use default Drupal templating layer to display the data or content.

So when should we go for Headless Drupal?

  • If you are building your website where content can be consumed by different applications and repurposed based on context. Headless Drupal will allows you to have different architecture for editorial system and the publishing system. You can event have one common editorial system for multiple publishing system.
  • You want to rely more on front-end architecture for scalability. And it makes more sense as having no heavy CMS in the delivery architecture means less of server processing. Static HTML files are easier to handle anyway from scaling perspective.
  • You are building an application where managing content is just one part. CMS is secondary function of the larger application.
  • Or sometimes you want to create two different application where one is used to create content like we do in staging environment. And after final approval, content is published to another publishing system. You do not require front-end for staging environment where content is created and reviewed only.

Headless Drupal is not without its share of adversaries or criticism. However in certain scenarios, its benefits far outweigh its drawbacks. In a world where user experience is critical for long-term success, decoupling CMS and front-end, which is what Headless Drupal achieves, is no longer an option, but a necessity.


Neeraj's picture

Neeraj is a senior consultant with a proven track record as project manager / Drupal Architect with a result-oriented drive. He also is a proud new father.
Oct 15 2015
Oct 15

With the evolution of Headless Drupal, Drupal is moving towards on being a preferable content storage to serve the data. But how is Drupal when being used as a Front end consuming remote data instead of proving it?

In one our recent project we have to achieve the same. Drupal is being used to display the remote data which is being provided by RESTful APIs. The catch was the data that was being consumed should not be saved in the Drupal database. So it was purely used just to display the data. Not only that we need to use the consumed data in views, and panels.

There are a few ways of doing this. One being using drupal_http_request function to consume the data and use it. But that would require a lot of customizations and in the long run would be very difficult to maintain.

In comes Web Service Data module

According to its documentation:
“Web Service Data is a collection of modules allowing you to interact with web services using entities and fields in Drupal.”

It was a perfect match for our requirement. The module will consume the data from Web Services and display it without saving any of it in the database. Plus it have fields, views and panels integration. So it was a win win situation all together.

So I am going to discuss how to use the Web Service Data module to consume Web Services and use them just as normal fields.

Enable the following modules:

  1. Web Service Data – Parent module to handle all the web services.
  2. Web Service Data Configuration – It enables to add the web service configuration from where we will fetch the data.
  3. Web Service Data Fields – Attach the power WSData module to fields.
  4. Web Service Data Fields Views Handlers – View handler for fields which are powered by WSData module.
  5. Web Service Fields Storage – Storage controller for fields to load the data.
  6. WS Data Demo – A demonstration on how to the module in action.

Once enabled if you go to “admin/structure/wsconfig/type” you will see a configuration type being added by the demo module.

In the Web Service Configuration section we define the endpoint of the service.

Next we go to “admin/structure/wsconfig”. The demo module has added a configuration for the type prescribed above. The configuration defines what CRUD operations for the service along with the method for it.

The demo module have also added a content type “Linked Data” with a title field and body field. The body field is provided by Web Service Data Fields module. In “admin/config/services/wsfields_storage” you can see the field being declared and configured to fetch data from the web service configuration.

So, we create a content for Linked Data. In the form we just need to enter the title. Lets say we enter “Drupal”. Once the content is saved you will be taken to the node page where the body of the content will be filled up by the Drupal wikipedia page.

Now let's use this module to fetch some remote data and publish it on our Drupal site. For this lets say we have an endpoint called http://examplesite.com/api/article/{article_id} which gives us details about an article.

  1. Go to “admin/structure/wsconfig_types” and add a Configuration type.
  2. Next we add a web service configuration for the type. We select the EventCampus Articles configuration as our endpoint.
  3. Add the required fields you want to fetch from the web services in “admin/config/services/wsfields_storage”. You can select what type of data you want to fetch and to which entity you want to attach the data. In the Web Service Remote Data Key you need to specify which field will hold the argument to the web service call. Like in our case title was the holder for the remote article_id argument.
  4. Now when we create a content of type article we can see the data pulled from the remote web service and being displayed in the node page.

This data can be used like default node fields in Views or Panels without any problem.

Currently once a few types of fields can be handled using the WsData module. But you can easily create handler for other fields which are not there like email, links, etc...

Conclusion, it’s a great module when we want to display data fetched from web services with saving in Drupal database. It comes packed with a good API system which we can extend to use it even in custom entities.


Malabya.Tewari's picture

Drupaler, quick learner, day dreamer, 24X7 online, loves watching movies. Enthusiatic about my plans and dreams. Likes to play cricket & Badminton!!.. Loves listening to songs while working..
May 03 2015
May 03

As we’ve said before, enabling organizations to transform digitally is at the heart of Phase2’s focus on content, collaboration, and experience. A key element of effective transformation is the combination of adaptability and foresight – in other words, the ability to see what new technologies are coming, understand their potential, and harness their power for your benefit.

In the world of open source CMS solutions, that imminent technology is Drupal 8. Although a long time coming, Drupal 8 is still an unknown quantity for many organizations. The way we see it, companies’ willingness to pick it up and run with it (strategically!) will play a major role in their success in the coming years.

MSK & Drupal 8, A Commitment to Innovation

Last year, Phase2 teamed up with Memorial Sloan Kettering Cancer Center to act as the organization’s Drupal technology partner after they had made the innovative decision to be Drupal 8 pioneers. The MSK team had more than a simple migration in mind: they endeavored to build one of the very first enterprise-scale Drupal 8 sites, despite the fact that D8 only existed in a beta form at the time. This decision reflected the center’s ability to see the big picture and boldly pursue innovation. In everything from patient care to biomedical research, MSK constantly seeks new ways to advance beyond what was previously thought possible, and their attitude towards digital transformation was no different.


Major Perks of D8

In addition to the power in core, which allowed the team to use less than ten total modules, there were vast improvements in extensibility, testing, templating, and configuration management.


The ability to extend plugins and services is more available in Drupal 8, with the result that instead of struggling to use yet-to-be-ported contrib modules, our team was free to create custom code specifically fitted to MSK’s needs. The idea of inheritance also made custom code easier to manage.

Object-Oriented Programming

One of the trickiest learning curves of Drupal 8 was also the catalyst for a lot of saved time. Object-oriented programming forced us to take a highly structured approach, isolating our business logic into objects. This results in separated pieces which can move forward despite one another. You can run your migration without knowing how things are going to be themed, and you can theme things without knowing how all content will be structured, etc.

d8 and symfony


The level of testing integrated directly in Drupal 8 core makes it significantly easier to confidently maintain MSK’s site functionality as Drupal 8 continues to evolve. The existence of self-documenting tests, which weren’t available in Drupal 6, was a great positive change for the MSK team.

External Libraries

Drupal 8’s incorporation of Twig accelerated the theming process. In addition to Twig, the inclusion of external libraries (JavaScript, Backbone, PhpUnit, Guzzle, and Symfony’s YAML, Routing, and Dependency Injection libraries just to name a few) created a great framework for our developers to work in.

Don’t Miss the D8 Train

We fully believe Drupal 8 (even as a beta) is a valuable alternative to Drupal 6 and 7, especially for enterprise organizations that can combine the core with extended custom code. What’s more, the community needs more organizations to take the leap to Drupal 8 to facilitate improvements and provide influential feedback to the community. Phase2 and MSK were able to contribute a significant amount of code back to the project. To move Drupal 8 closer to an official release, more organizations need to invest in its creation through projects of this kind – and Drupal vendors need to be ready to support them.


Drupal 8 is a win-win for enterprises and the Drupal community alike. Are you and your organization ready to transform with Drupal 8? Take the first step by attending our DrupalCon session with Memorial Sloan Kettering (or our session on Drupal 8 for enterprise organizations!). You can learn from the challenges we faced and come away with a list of hints, tricks, and best practices for beginning your own Drupal 8 project. In the meantime, stay tuned to our blog for more on our adventures in Drupal 8.

May 22 2013
May 22

We just launched Zact, one of our largest design projects to date at Chapter Three. We designed nearly 200 comps, including an e-commerce workflow, a customer dashboard that mirrors the functionality of the phone’s software, a Support section built on ZenDesk, and a consumer-facing website.

A disruptive new cell phone provider, Zact is a new company looking to redefine how customers purchase mobile services by making your plan 100% customizable right from your phone with no overage fees or contracts. They even give you a refund every month for any unused minutes, texts or data.

Helping Zact overcome business hurdles
As a new company in a major market, Zact turned to Chapter Three to help them solve some of their immediate business hurdles online.

  • Establishing brand trust
    To overcome lack of brand recognition and to educate new customers about the key advantages of the service, we created the “Why we're different” and “How it works” sections as a way for new customers to get to know us.
  • Paying full price for the phone
    To educate customers about the long term savings of buying the phone at full price, we created an interactive Savings Calculator. The calculator allows customers to compare various plan and phone options to their current bill to show their dollar amount saved over a two year period.
  • Buying a phone online
    Without the ability to physically touch the phone customers are buying, we needed to build in extra guarantees to make customers feel comfortable purchasing a device online. We featured a “satisfaction guarantee” statement prominently throughout the site, promising a refund within 30 days if the customer did not like the phone.

Herculean feats of UX strength
The complexity of interactions across the site gave us an opportunity to flex our UX chops. We collaborated with Zact’s usability specialist, incorporating feedback from weekly usability tests to iteratively improve our designs.

  • Customer dashboard
    To provide the functionality of the phone’s software on the website, we designed a web-specific interpretation of the phone software that empowers customers to access and control the full breadth of Zact’s service offerings. Because the software was being developed in parallel with our web design, we adopted an agile design approach to iterate in sync with the development team.
  • E-commerce
    Our team worked with Zact’s usability specialist to implement a checkout flow pulling from best practices across the web. We delivered a solution that pushes the capabilities of Drupal Commerce and its ability to integrate with third-party systems.

Agile design
An agile design process was critical in the success of this project. We needed to be flexible as requirements and scope were changing daily. We met with the client daily via WebEx with new design deliverables for review, which allowed us to gather feedback often and respond quickly. For any given page, we were able to explore a number of options on a high level before focusing on a more final solution.

In fact, some of the best ideas on the project came directly from the client, as a result of organic discussion during those meetings. The Savings Calculator, which allows users to more visually understand how they will save money over time with Zact, grew out of a conversation we facilitated.

Our first iterations of the Savings Calculator were pretty skeletal and didn’t quite feel right; the user had to fill out the form and click a button before seeing results. After further discussion, the client suggested that we make the actual dollar savings visible and dynamic throughout the page, so that as you interact with the form you can directly see how your savings are affected. This minor design change immediately made the page more engaging and an effective tool in communicating why Zact is a viable alternative to a traditional phone contract.

Starting up in Silicon Valley with Drupal
One of the most exciting and challenging parts of the project was the rapid pace of startup culture. The level of expertise and web savvy amongst Zact’s staff allowed for a flourishing partnership where we were able to push boundaries and do great work together. So far, the site has been covered by some major press outlets, including Gizmodo, Engadget, Forbes and TechCrunch.

The site is finally live, but our work isn’t over yet. We’re continuing to evaluate and optimize the usability of the site and will continue to roll out design updates over the coming weeks. We look forward to working further with Zact and seeing how users will react to the new site.

Aug 22 2012
Aug 22

What is OpenPublic?

Maybe the first question should be “What is Drupal?”.  Drupal is a free open source content management system (CMS) that allows you to easily organize, manage and publish online content. It is secure, scalable, compliant, flexible and capable of more customisation than any one web site will ever need.

OpenPublic is a CMS based on Drupal. It is a pre-packaged product containing modules particularly valuable for government websites. It is created for, and by, industry professionals working with top level government agencies and organisations. As a global, community driven project OpenPublic takes the open source Drupal CMS to its next instinctive level: tailoring it to government within a shared learning environment. Growing this open source CMS with genuine community input ensures its enduring relevance.

An active community

OpenPublic is a community project being spearheaded by US based content management and open data integration specialists Phase2 Technology. Contributors are generally administrators, site builders and developers. A number of web application and data visualisation tools have already been added to the mix and enthusiastic advocates continue to contribute code, tutorials, screencasts, and other documentation for OpenPublic.

But isn’t all open source software at odds with government security needs?

Not at all. OpenPublic is founded on US government security requirements and is also applicable to Australian government requirements as prescribed by the Defence Signals Directorate’s Australian Government Information Security Manual, particularly in regard to: standard operating environments; web and email applications; web application development; and databases.

Additionally Link’s partnership with Acquia goes a long way to removing historical and assumed risks around the use of open source software and means our clients can have 24/7 access to expert Drupal support for break-fixing and advice

How does Link Digital fit in with the whole OpenPublic CMS and community ethos?

For over ten years Link has been working with government clients to help them meet the demand for greater transparency, participation and collaboration, while satisfying their unique needs, not only in terms of security compliancy but also across accessibility and usability. OpenPublic provides the ideal model for us.

We are aligned with a strategic approach to the establishment of Drupal and OpenPublic sites for a growing number of clients, and closely linked with the activities of global leaders in the community, such as Phase2 Technology and Acquia. We have opened up dialogue with both companies to seek their support in the establishment of best practice deployment for our clients and will, in the coming months be acting on their recommendations and service options in this regard.

What does OpenPublic mean for Australian enterprise and government clients?

The Drupal 7 environment already offers a very budget friendly solution with great flexibility, a highly intuitive interface, and the ideal platform for information sharing and knowledge exchange. By aligning our development approach for enterprise and government clients with the OpenPublic community our clients get access to best-of-breed and emerging website management tools. This provides our clients a more long term CMS solution that is both effective now and has a roadmap aligned with the needs of government and public oriented organisations into the future.

OpenPublic is a direct response to the US Government’s Open Government Initiative and there are direct parallels between this and similar mandates placed on Australian government agencies, particularly in regard to the central recommendation of the Government 2.0 Taskforce’s report. Indeed the Australian Government’s 16 July 2010 Declaration of Open Government made by the Hon. Lindsay Tanner, MP, then Minister for Finance and Deregulation, opens with:

“The Australian Government now declares that, in order to promote greater participation in Australia’s democracy, it is committed to open government based on a culture of engagement, built on better access to and use of government held information, and sustained by the innovative use of technology.”

Link Digital is currently developing the new website for the Department of Prime Minister and Cabinet using OpenPublic. Like us, they are encouraged by, and committed to, the ongoing development roadmap it provides.

What are the key features of Drupal with Open Public?

Responsive Design

The number of environments and platforms available today (and tomorrow) means for a site to be relevant it must also be responsive design ready.  OpenPublic allows customisation of the look and feel of a site with base themes, while implementing the best practices in responsive design. The implementation uses ‘contexts’, whereby the device a visitor is using – mobile phone, iPad etc – is noted as a particular context, such as a smaller screen size. An OpenPublic site can present site content within specific layout regions that are optimised for each context. Entirely different content can also be presented if desired.


OpenPublic is pre-configured to better meet the needs of Government-level security. Passwords comply with Level 2 of the US’s National Institute of Standards and Technology (NIST) Electronic Authentication Guidelines, https is setup from the start, and CAPTCHA comes standard on forms.

Accessibility and WCAG Compliance

Australian government accessibility guidelines and regulations and WCAG compliance are key, if not mandated, foundations to usable government websites. In meeting US Government requirements OpenPublic’s default themes meet ADA guidelines for Section 508 Compliance, which goes a long way to giving site implementers a head start on testing for their own compliance. Link Digital is further mapping the compliance of OpenPublic’s default themes against those adopted within Australia. Localisation is a requirement for our www.dpmc.gov.au work and the benefits will roll into the work provided for other clients.


OpenPublic allows for the tailoring of permissions and a customisable workflow that meets organisational needs. This kind of functionality is fairly standard in modern CMS platforms but the implementation provided by OpenPublic is extremely relevant to establishing self-managed facilities for Australian government and enterprise clients. Link is able to implement content which is aggregated from nominated RSS, twitter or user contributed sources and queue these for promotion within the site via automated, yet moderated, workflow rules.

Customisable Look and Feel

OpenPublic, similar to WordPress, offers a selection of standard designed themes, or you can apply custom design. For Link clients we apply uniquely designed themes, but the functionality allows us to consider design variations to accommodate seasonal or temporary opportunities to refresh the site design. For example, a design to celebrate a major event hosted by a government department could be adapted and applied during celebrations.

Intuitive Dashboard

You can have all the greatest modules in the world but, at the end of the day, if you don’t have a user-friendly dashboard that makes administering your site easy, you will have a suboptimal outcome. Thankfully OpenPublic does not fall short here and offers an intuitive dashboard for easy content adding and updating. The vast improvement in usability will be particularly apparent to anyone with previous experience in administering a Drupal site. For a number of content types, improved rich-media management means the addition of graphics and data visualisation elements is as simple as clicking “upload.”

Media Room

OpenPublic provides tools for the quick release of breaking news and information that’s important to your website visitors. You can also invite media to access images, video, press releases, and other valuable content in a single, centrally accessible location.

Directory Management

With directory management features OpenPublic sites can publish via profiles – for example via a Ministerial profile for an agency or via program ambassador for a major initiative. This is an effective method for site visitors to develop a deeper and more personal association with an organisation and its objectives. Tools provide the ability to easily and quickly maintain a directory of contact information for hundreds of profiled people and/or organisations.

Pluggable Features

Out-of-the-box, OpenPublic comes with pertinent features – from integrating a Twitter feed to posting blog entries – that you can enable or disable, depending upon your needs. These pluggable options make customisation a process that is less technical and more focussed on meeting your objectives.

Feb 22 2012
Feb 22
Schema.org module

Back in June of last year when Google, Bing and Yahoo! introduced Schema.org I wrote about how it would be a game changer for the semantic web. The problem was that it was difficult at best to implement semantic vocabulary on a website, even in Drupal 7. But that has all changed now.

Last week I attended Acquia’s webinar, Profiting from Drupal-Powered Semantics, and learned about a new module called the Schema.org module. The webinar was basically a demonstration of the module by its developer, Stéphane Corlosquet.


What struck me initially was the simplicity of this module. The mapping of content types and fields to the schema.org types and properties is all done in the content type settings and the fields UI. If you set up your schema at the same time you create your content types, the additional effort is marginal. Additionally the module automagically populates the list of schema types from Schema.org which makes the choosing the semantic properties really easy.

While the module is currently at the Beta2 release I would still feel confident considering it on a large production site based on the webinar demonstration. It seems well implemented.


The benefits of adding semantic properties are numerous; search engines are already starting to look for this data to identify the elements of your website. If you implement semantic tagging to your site you will be light years ahead of most other sites.

In the webinar the example given was that of a website selling a book and how the semantic vocabulary could be assigned to the author profiles. Stéphane showed how the semantic elements influenced actual search results on Google.

The Semantic Web is still mostly a niche concept due to the complexity of implementing it up to this point; but there is no doubt in my mind that the it is here to stay. As more content management systems develop user friendly ways to implement semantic structure it will eventually become as necessary as meta tags on a website.

If you are interested in implementing the Schema.org module, check out the recording of the Acquia webinar. You may also be interested in one of the the Schema.org recipes on drupal.org; they can help you set up your schema for common vocabularies such as Person, Recipe, or Event. Then you can be on the cutting edge of search engine site optimization.

Has anyone tried out the Schema.org module? Let us know in the comments what you like and don't like.

Jul 01 2009
Jul 01
We’ve talked through the ‘strategy’ behind the proposed D7UX Information Architecture (IA), now let’s take a look at it in detail. What goes where. Let’s go through each major section in turn: Content The ‘Find Content’ page, showing a searchable, sortable, filterable list of all the content on your site is the ‘landing page’ for … Continue reading D7UX Information Architecture – A detailed view
Jul 01 2009
Jul 01
Designing an Information Architecture (IA) for Drupal is an incredibly challenging project – essentially you are trying to design an IA that allows just about anyone to do just about anything. Flexibility is very often the enemy of good design – people make good and fast decisions with fewer options not more – but how … Continue reading Information Architecture Strategies
Jul 01 2009
Jul 01
This is the first in a series of posts discussing the proposed information architecture (IA) for D7UX. Before we get into too much detail, be sure to check out this great video that Roy Scholten (Yoroy) posted recently that helps explain some of the key features and rationale of the IA and how it relates … Continue reading Understanding the D7UX Information Architecture Approach

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web