Skip to Content


OpenConcept: An overview of software testing

Planet Drupal - 3 August 2015 - 6:31am

"Software testing" is a term used to refer to a variety of methods, tools, and practices for verifying that a software application works, at many different levels.

All of us in the web development industry do some sort of software testing (even if the testing we do is manual and ad hoc, e.g.: refreshing a webpage after making a change to ensure the code you just wrote works). In this blog post, I will attempt to discuss why you might want to move away from ad hoc testing to more-formal testing, try to dispel some myths about formal testing, and give a high-level overview of the different ways that software can be tested, and the different levels of software testing that exist.

First: a disclaimer — I am not a software testing expert, and to a large extent, I wrote this to help wrap my head around software testing. Also, trying to fit complex, multi-faceted things into neat boxes is difficult (and/or controversial), so be aware that others might classify testing differently. If you find out mistakes or agree/disagree with my categorizations, please let me know in the comments below.

This blog post assumes that:

  • you work in the software development industry, and,
  • you've done manual, ad hoc tests at some point (and have an idea of why they are important).
What do you mean by formal tests?

This blog article considers "formal" tests to be tests which are recorded in some way so that other people (i.e.: not the original developer) or software can run them at any time.

Why test formally?

Software testing is an important tool with benefits such as:

  • a "safety net" to ensure each subsequent change to a program doesn't cause a regression or loss-of-functionality,
  • a "sanity check" to ensure that the code written meets the expectations / requirements of the client and your peers,
  • a way to ensure that your code is not too tightly coupled to a particular set of assumptions or use-case (this evolves naturally as you learn to write testable code),
  • a collaboration tool to ensure that someone else's work doesn't inadvertently break your work and vice-versa,
  • a portability check to ensure that code works outside of your specific environment's assumptions, and even,
  • a way to ensure that time is not wasted over-engineering solutions to problems.

Depending on the nature of your work and clients, manual ad hoc testing might be sufficient for a while.

However, as projects, development time, product lifecycles, and/or consequences-of-failure grow in size, complexity, and budget, the benefits listed above become increasingly important to limit the risk of client dissatisfaction, going overbudget, getting stuck in development/bug-fixing hell, and/or the risk of producing software that requires a high level of skilled maintenance to continue functioning.

Formalizing these tests (even manual tests) by recording them in some way allows you to run them the same way every time you run them, ensuring you don't forget something important. It also allows your co-workers to run them if you're busy, or computers to run them if they're automated. And, formal manual test cases can usually be converted to automated tests with little effort.

Myths of formal testing
Myth: Writing formal software tests isn't worth the cost.
While it certainly takes a while for new testers to get used to how testing works, and it is possible to write too many tests, even a little bit of testing can greatly reduce development time later in the development cycle, both before the product is launched, and during maintenance later on. Acceptance and refinement tests specifically (see below) can also help to give all involved parties a sense of what needs to be focused on, reducing project management time, wasted development time, and the risk of producing a product that clients (or in the case of a website, the general public) doesn't want or cannot use.
Myth: Formal software tests must be written only by software developers.
While developers must write certain tests, and are typically capable of writing most (if not all) types of tests, there are certain types of software tests which are better written by product owners, clients, testers, developers, and designers.
Myth: Most tests should be written after the system is (mostly) functionally-complete.
While the Waterfall software development model states this, the reality is that the earlier you start testing, the earlier you find and correct bugs, missing functionality, architecture problems, and usability issues.
A brief note about test-driven development (TDD)

A powerful way to write software is using Test-Driven Development (TDD). Simply put, TDD is the practice of writing tests first (so your intents are clearly stated), then writing the code to meet the requirements of the test. Test-driven development is applicable to all areas of software testing, except, perhaps, certain types of refinement tests.

Test-driven development has two distinct advantages:

  1. it ensures that everything you write from the point when you start using TDD is well-tested ("has good test coverage"), and,
  2. if you follow the TDD principle to stop developing when the tests pass, you can ensure that you don't waste time over-engineering solutions to problems.

I highly recommend reading Test-Driven Development By Example by Kent Beck (Addison-Wesley, 2003).

Classifying tests

All types of software tests can be classified as white-box, black-box, or grey-box:

White-box tests
Clear-box tests
Tests written to test the internal structure of something, as opposed to it's functionality. Named because you typically look at the code you're testing, and write your tests to target it.
Black-box tests
Tests written to test the functionality of something, as opposed to it's internal structure. Named because you typically (pretend that) you know nothing about the implementation of something, and write your tests to do what you'd expect it to do.
Grey-box tests
A combination of white- and black-box testing, used to test for improper structure or usage defects.
Levels of software testing

I group software testing into five main levels,

  1. Unit tests,
  2. Integration tests,
  3. Acceptance tests,
  4. Refinement tests, and,
  5. System tests.

Generally, the number of tests decrease; but the coverage scope, run-time, effort and cost of the tests increase as you go down the list (i.e.: in a well tested system, there are many unit-tests, each covering a small scope (e.g.: a single function), but few system tests, each covering a wide scope (e.g.: many objects, functions, and subsystems working together as-intended)).

To help you keep track of all these things, I've put together a software testing cheat sheet for you to download. The cheatsheet's source code is on Github, so feel free to improve it!

Unit tests

Unit tests are typically white-box tests to cover edge-cases and code branches (code paths) in a limited scope, typically on a per-function level. Each function typically has one or more unit tests that focus on ensuring each code path functions in the expected manner. Small changes to the code under test typically require changes to the unit tests to incorporate the new changes and ensure new code paths are covered.

Unit tests are typically short and quickly-written by the software developer who is writing the code under test, using carefully-chosen test parameters (typically edge-cases); by checking pre- and post-conditions, state-changes, and output; and by mocking dependencies to ensure that the test only covers the function under test.

Ideally, unit tests are written before the function(s) they test (i.e.: following Test Driven Development principles). If writing and performing unit tests is required for new work, your last chance to do so is before committing or submitting your code for code review.

Key technologies for unit testing are:

  • phpUnit, RSpec, Jasmine, QUnit, Unit.js, etc. (sometimes collectively referred to as xUnit because many follow a naming pattern of <language abbreviation>Unit).
    • Note that SimpleTest in Drupal 6 contrib and in Drupal 7 core can be used to do unit tests, but it's not very good at it, so it's been replaced with phpUnit in Drupal 8.
  • Mock objects (e.g.: Hamcrest).

... note that many of the key technologies can also be used for integration and acceptance (behaviour) testing.

Other names for unit tests are:

  • component tests

Some books on unit tests and mock objects that I've read and recommend are:

Integration tests

Integration tests are typically grey-box tests to cover interactions between objects and interfaces, on a limited scope, typically on a per-object or per-subsystem level. Each object and subsystem typically has one or more integration tests that focus on ensuring the object/subsystem interacts with it's dependencies in the expected manner. Small changes to the code under test might require changes to the integration tests, especially when they change the way an object/subsystem interacts with other objects/subsystems.

Integration tests are typically medium-length and quickly-written by the software developer who is writing the object/subsystem code, by checking success and failure states, how they interact with other components (through mock objects), what they accept as input, what they produce as outputs. Mocking dependencies, shared resources and inter-process-communication is common practice at this level.

Ideally, integration tests are written before the object(s) they test (i.e.: following TDD principles). If writing and performing integration tests is required for new work, your last chance to do so is before committing or submitting your code for code review.

Key technologies for integration testing are:

... again, because unit tests and integration tests are so similar, they share a lot of the same technologies.

Other names for integration tests are:

  • integration & testing (I&T)

Some books on unit tests and mock objects that I've read and recommend are:

Acceptance tests

Acceptance tests are typically black-box tests to cover how a user moves through a system on a broader scope, typically at the user-interface level. Each user-interface display typically has a number of acceptance tests that focus on ensuring the user can complete a certain set of tasks using that display, that the display functions correctly, and that it meets the client's requirements. Small changes to the code under test only require changes to the acceptance tests if the changes affect the user interface.

Acceptance tests are typically short and written by the product owner, client, tester, or in some cases, the developer, by looking at the user story / ticket and outlining the steps the user must take to complete the requested functionality.

Ideally, acceptance tests are written by the client, or product owner before the UI is developed and any work is done. If writing and performing acceptance tests is required for new work, your last chance to do so is before committing or submitting your code for code review.

Ideally, parameters for accessibility testing (i.e.: level of conformance) and browser testing (i.e.: list of supported browsers) should be defined by the client before any work is done; and the latest these should be defined is before any work is started.

Key technologies for acceptance testing are:

  • Manual tests (using manual test cases).
  • The Gherkin domain-specific language.
    • Tests written in Gherkin are turned into mouse clicks, keystrokes, etc. by interpreters (e.g.: Behat, Cucumber, SpecFlow).
      • These interpreters forward these mouse clicks, keystrokes, etc. through controllers (e.g.: Mink, Webdriver, CasperJS) to browsers.
        • Controllers like Mink or Webdriver then control:
    • Behavioural output from browsers is usually forwarded back to the Gherkin interpreters for analysis.
    • Visual output from browsers can be forwarded to visual regression tools (e.g.: the Galen framework).
  • SimpleTest in Drupal 6 contrib and in Drupal 7 core.
  • Visual difference tools (e.g.: Shoov).
  • Accessibility testing, both automated (e.g.: Quail) and manual (e.g.: VoiceOver, JAWS).
  • Browser testing (i.e.: ensuring it works in each browser), either automatically (typically performed with the Gherkin stack above), or manually (using a manual test case with local browsers, browsers in virtual machines, or browsers in the cloud).

Other names for acceptance tests are:

  • conformance tests
  • behaviour tests
  • functional tests
  • User Acceptance Tests (UAT)
  • validation tests
Refinement tests

Refinement tests are usually black-box tests to determine if a proposed UI is:

  • useful (does the system do what the user wants to do)
  • usable (can the user figure out how to get their tasks done)
  • aesthetically pleasing (does the UI look good)
  • identifiable (is the purpose of the system clear)
  • inspirational (does the system inspire the users to use it), and,
  • valuable (does the user value the system and it's purpose)

... on a broad scope, at the user-interface level. Each design stage / refinement typically undergoes a series of tests to ensure the design provides a good end-user experience. Changes to the code under test don't normally require changes to the refinement tests unless a desired UI element is deemed too costly to complete.

Refinement tests are typically written by a designer or UX expert by presenting a UI design to users and gathering data on how they experience it, and may be repeated as the design progresses. Beginning refinement testing before any real (non-prototype) code is implemented often reduces the number of design / UI changes later on in the development cycle, as the biggest usability problems can be identified as early as possible.

Ideally, refinement tests are written before the UI is developed and any work is done. If writing and performing refinement tests is required for new work, your last chance to do so is before committing or submitting your code for code review.

Key technologies for refinement testing are:

  • Visual difference tools (e.g.: Shoov).
  • A/B testing frameworks (e.g.: Acquia Lift).
  • Accessibility testing, both automated (e.g.: Quail) and manual (e.g.: VoiceOver, JAWS).
  • Talking to actual users.
  • Observing how users use the system.

Other names for refinement tests are:

  • UX tests
  • Usability tests
  • Business-value tests
  • Return On Investment (ROI) tests
  • End-user tests
  • Field tests

Some books on refinement tests that I've read and recommend are:

System testing

System tests are typically black-box tests to cover the system as a whole and catch regressions, on an extremely broad scope, at the user-interface level. The system usually has a number of system tests, each of which may focus on an important aspect of the system. Small changes to the code under test don't normally require changes to the system tests.

System tests are typically written by the tester, developer, and product owner, to by writing regression tests, setting performance acceptability thresholds, stress-testing the system, ensuring the system is compatible with the systems it's designed to work with (e.g.: where it will be deployed), and whether the system can recover from unexpected, serious problems outside of it's control (recovery tests).

Ideally, system tests are written or their parameters are chosen before any development work is done. If writing and performing system tests is required for new work, your last chance to do this is after integrating code together, usually before a demo to the client or a beta test.

One thing to note about system testing is that the results of the tests aren't always a strict pass/fail, and therefore aren't always actionable. In this case, trends are more important: you should expect software that just got a whole bunch of new features to be a bit slower; but if it's a lot slower, then you should probably examine the new code and schedule some time to refactor.

Key technologies for system testing are:

  • Analysis tools (e.g.: New Relic)
  • Load-testing tools (e.g.: Siege)
  • Manual tests

Other names for system tests are:

  • End-user tests
  • Field tests
  • Regression tests
  • Performance tests
  • Failure tests
Bonus: Smoke tests

Smoke tests are extremely-small, preliminary, typically ad-hoc tests to reveal major defects that would typically preclude someone's ability to run other tests. For example:

  • code that does not compile because of a syntax error prevents all tests from being run, therefore, syntax linters could be considered a type of smoke test;
  • if a file added in the latest deployment does not exist after the deployment, or the file is empty (and it isn't supposed to be), that's usually a good indication that a deployment failed.

Rumor has it that the term "smoke tests" is a calque from the discipline of electrical engineering, where, if you plug something in and it starts to smoke, that typically indicates that something is wrong and would prevent further testing.

Other names for smoke tests are:

  • confidence tests
  • sanity tests
  • intake tests
In conclusion

Hopefully, this blog post will help you to understand some of the terminology that surrounds software testing.

Special thanks to my friend Anand Sharma, who is just as passionate about software quality, and has been a big help and influence in helping me learn software testing. He also reviewed the software testing cheat sheet for me. Also, thanks to Patrick Connelly for the great tools he built and conversations we've had about continuous integration and software quality in general.

Some books on this subject that I've read and strongly recommend are:

If you're looking to implement formal software testing at your organization, don't be discouraged by the fact that it takes a while to learn how to write good tests: it's worth the investment.

Next week, I'll write a bit about automated testing, continuous integration, and continuous delivery.

AttachmentSize Software Testing Cheat Sheet (updated 2015-07-31)120.53 KB Topic: 
Categories: Drupal

Web Wash: How to Display Icons in Drupal using Icon API

Planet Drupal - 3 August 2015 - 4:15am

Good use of icons on a website can really lift its overall design. Of course, you can't just slap them on and expect a site to look brilliant. It's all about choosing the right type of icons to match the design.

Once your designer has chosen a font library like Font Awesome, or made their own, what is the best way of displaying them in Drupal? The quick and simple way is to get the designer to style them using CSS but this is not flexible.

What if an editor wants to choose which icon is displayed in a menu? If you've added them to the menu manually via CSS then the editor won't have the ability to change the icon in the future.

The Icon API module integrates common icon bundles like Font Awesome, Bootstrap and more within Drupal. The module offers integration with a suite of sub-modules. For example, if you want to add icons to menus then install the icon_menu module.

In this tutorial, we'll configure Icon API to allow an editor to add icons to menus and directly into content. We'll do this using the Font Awesome icon bundle.

Categories: Drupal

OSTraining: New Video Class: Speeding Up Your Drupal Site

Planet Drupal - 3 August 2015 - 1:04am

Drupal is a fantastic CMS, but it can be slow if the site is complex or on a slow server. With Google's focus on site speed, this is a very important issue.

In this week's new class, "Speeding Up Your Drupal Site", Robert helps us get the most out of Drupal's power without sacrificing performance.

Robert explains the caching power of Drupal, and introduces you to several great modules to help speed up your site.

Categories: Drupal

Web Omelette: Write your own Views Bulk Operations actions in Drupal 7

Planet Drupal - 3 August 2015 - 12:05am

Views Bulk Operations (VBO) is a powerful module that leverages Views to allow site administrators to perform bulk operations on multiple entities at once. It does so efficiently by processing the items in batches over multiple requests to avoid timeouts.

Installing the module will already provide you with a host of various actions you can perform in bulk on various entities. You can publish 1000 nodes at once, delete them or even change their author. And these are just a few examples of what you can do.

In this article we are going to look at programatically creating our own action that we can trigger with VBO to affect multiple node entities. Sometimes you need to write your own because the use case does not quite fit in the extensive list of actions the module provides.

For our example, let's assume we have an entity reference field called field_users on both the article and basic page content types. This field can reference whatever user it wants. And the requirement is to be able to bulk update the value of this field on a bunch of nodes of both these node types at once.

Out of the box, VBO provides us with an action to change the value of a field but this doesn't help us in this case. When adding a value to this field via VBO, we are presented with as many instances of the field as different node types are in the selection. And this is not ideal if we want to scale the functionality to more than one content type. What we want is to select a number of nodes and then only once provide a value to this field. So let's see how we can define a custom VBO action for this use case.

The action

To define a new action we need to implement hook_action_info():

/** * Implements hook_action_info(). */ function my_module_action_info() { return array( 'my_module_my_custom_action' => array( 'type' => 'entity', 'label' => t('Add a user to Users field'), 'behavior' => array('changes_property'), 'configurable' => TRUE, 'vbo_configurable' => FALSE, 'triggers' => array('any'), ), ); }

With this hook implementation we are defining our own action called my_module_my_custom_action which is available to be triggered on all entity types (because we specified entity for the type) and it acts as a property changer. It is configurable using the default Action API but we don't need any kind of VBO specific configuration. For more information on all the values that you can pass here, feel free to consult the documentation page for VBO.

Next, it's time to create the configuration form for this action, namely the form that will be presented to us to select the user we want to add to the field_users reference field:

function my_module_my_custom_action_form() { $form = array(); $form['user'] = array( '#type' => 'textfield', '#title' => t('User'), '#maxlength' => 60, '#autocomplete_path' => 'user/autocomplete', '#weight' => -1, ); return $form; }

The function name takes from the machine name of the action suffixed by _form and is responsible for creating and returning a form array. All we need is one field which uses the core user/autocomplete path to load users via Ajax. Simple enough.

So now after we make a bulk selection and choose our action, we'll be prompted with this form to choose the user we want to add to the reference field. It follows to couple it with a submit handler that will save the value into the context of the operation:

function my_module_my_custom_action_submit($form, &$form_state) { $uid = db_query('SELECT uid from {users} WHERE name = :name', array(':name' => $form_state['values']['user']))->fetchField(); return array( 'uid' => $uid, ); }

The naming of this function is similar to the previous one except for the suffix being _submit this time around. In it, we load from the database the uid of the user that was referenced in the form field by name and return that inside an array. The latter will then be merged into the $context variable available in the next step.

So it's now time to write the final function which represents this step by adding the selected user to the existing ones in that field across all the selected nodes, regardless of their type:

function my_module_my_custom_action(&$entity, $context) { if (!isset($entity->field_users)) { return; } if (!isset($context['uid'])) { return; } if (!empty($entity->field_users)) { foreach ($entity->field_users[LANGUAGE_NONE] as $ref) { if ($ref['target_id'] === $context['uid']) { return; } } } $user = array( 'target_id' => $context['uid'], ); if (!empty($entity->field_users)) { $entity->field_users[LANGUAGE_NONE][] = $user; return; } $entity->field_users[LANGUAGE_NONE] = array($user); }

The name of this function is exactly the same as the machine name of the action, the reason for which we prefixed the latter with the module name. As arguments, this function gets the entity object that is being changed (by reference) and the context of the operation.

We start by returning early if the current entity doesn't have our field_users field or if by any chance the uid key is not available inside $context. Then we loop through all the values of the field and return if the selected uid already exists (we don't want to add it twice). And last, we add the selected uid to the list of existing users in the field by taking into account the possibilities that the field can be empty or it can already contain values. After passing through this action, VBO will automatically save the node with the changes for us.

And that is pretty much it. Clearing the cache will make the new action available in the VBO configuration of your view. Adding it will then allow you to select as many nodes as you want, specify a user via the autocomplete field and have that user be added to the field_users field of all those nodes. And the cool thing is that you can select any node you want: if the field doesn't exist on that content type, it will just be skipped gracefully because we are checking for this inside the action logic.

Hope this helps.

In Drupal var switchTo5x = true;stLight.options({"publisher":"dr-8de6c3c4-3462-9715-caaf-ce2c161a50c"});
Categories: Drupal

Damien McKenna: My Drupal contrib plans for August, updated

Planet Drupal - 2 August 2015 - 6:03pm

A few weeks ago I posted my plans for my personal Drupal contributions for the next month-or-so. I wanted to give a minor update on what I'd managed to achieve so far.

Categories: Drupal

Inside IFrame

New Drupal Modules - 2 August 2015 - 10:55am

Sometimes a website needs to be displayed inside an iFrame, as well as being displayed in a full window. In the case when it is displayed inside an iFrame, it should be modified a bit to better fit this display, for example some parts can be hidden, the margin of the page can be lowered or removed, etc. These modifications can be done by including an extra CSS file that contains the necessary customizations.

Categories: Drupal

Small ads

New Drupal Modules - 2 August 2015 - 9:05am

Drupal 8 successor to D7 Offers & Wants, which supports local communities to share and exchange their stuff and skills.

Ready rolled 'feature' type module allows permitted users to post ads and browse by category.

Smallads is its own entity type which is planned to have a remote storage controller pointing to REST API service. The entity comes with several fields already - image, geolocation, expiry date. Some handy views and blocks are provided also.

Categories: Drupal


New Drupal Modules - 2 August 2015 - 6:49am

This module is moving poll functionality into entities. For now it should be mostly usable for developers, which may enjoy that a poll is an entity and choices are also entities (so they can have fields!). Poll types, widgets, results displays are abstracted, so you can make your own. I tried to make it in a way that should allow you to relatively easily implement any voting system you wish.

Categories: Drupal

Commerce Cart Empty

New Drupal Modules - 2 August 2015 - 3:43am

Provides a way for the current user's cart to be emptied.


Once enabled, an option will be available on the checkout configuration page (admin/commerce/config/checkout) to control the path used to trigger the cart emptying.

Credits / Contact

Written and maintained by Damien McKenna.

Categories: Drupal

Commerce Checkout Product List

New Drupal Modules - 1 August 2015 - 11:13am

Provides a checkout pane that lists all active products, allowing the visitor to add & remove products from the current order.

This module is a fork of the Commerce Cart Form Checkout Pane module; that module allows editing the products currently in the user's cart, whereas this module shows all products.

Related modules

Some other modules work well with this one:

Categories: Drupal


New Drupal Modules - 1 August 2015 - 8:27am

Integrates Zoho SalesIQ chat with your drupal site.

  • Register to an account on Zoho SalesIQ
  • Copy the embedname of your chat widget. Can find it here:
  • Goto to the configuration page admin/config/development/zoho_salesiq and paste embed name.
Configuration options

With this module the following configuration options are available:

Categories: Drupal

Info plugins

New Drupal Modules - 1 August 2015 - 12:12am

This module is for developers. It provides cTools plugins for common _info types of functionality.

For example, it allows you to define a core Drupal block the same way as you would define a cTools content_type plugin or a context one to use with Panels.

It aims at clearing a bit the mess that ensues when a site needs to define many such blocks or other _info based extensions. I always hated the switch statements that cluttered the hook_block_* or hook_field_formatter_* implementations.

Categories: Drupal

Simplenews Status Reset

New Drupal Modules - 31 July 2015 - 4:27pm

Simplenews Status Reset is a tiny module, that allows to reset the sent status of an already sent Simplenews newsletter issue to "not sent". This allows to resend a newsletter (e.g. to a different category) without duplicating the node or changing the status value by hand in the database.

Categories: Drupal

Webform Button Classes

New Drupal Modules - 31 July 2015 - 1:03pm

This is simple module for adding some extra classes to Webform module buttons.
Configuration is located under each Webform instance advanced settings fieldset.
This module is built for Webform 4.x

Categories: Drupal

Farm MapKnitter

New Drupal Modules - 31 July 2015 - 12:30pm

Provides integration with Public Lab's

Description available on GitHub:

Categories: Drupal

Lullabot: The New

Planet Drupal - 31 July 2015 - 12:09pm
React.js, CouchDB, Node.js, de-coupling Drupal; if any of that sounds cool to you, then this is the podcast for you. Kyle Hofmeyer gathered a several Lullabots together, who helped create the new, to learn what kind of wizardry was used to make this thing purr like a happy kitten. Jared Ponchot talks about the advantages this process provided for him and his design team. Sally Young talks about the guts of the site and the magic that went in to making this de-coupled Drupal site a success. We are also joined by Kris Bulman, Wes Ruvalcaba, and Betty Tran as they share their experience building the site. From front-end advantages to lazyboyDB, this podcast has it all.
Categories: Drupal

Lullabot: Announcing The New

Planet Drupal - 31 July 2015 - 12:05pm
Mmmm… love that new website smell! Some history

It's been nearly 10 years since we launched our first company website at During that time, we've done five full redesigns of the site. The company has grown from two people to 62. We've expanded from a small Drupal consulting and education company to a full-service agency with a complete Design team, dedicated front-end developers, and of course, the expert Drupal back-end development which has always been our foundation.

As we've grown, our site design has reflected our focus and skills. The first site that Matt and I put together back in 2005 was intentionally sparse – not exactly beautiful, but functional and simple to maintain for just 2 or 3 people. As we hired talented designers and skilled front-end developers, site redesigns became more complex. In 2010, we split our Drupal education services into Drupalize.Me and the main focus of became our client services work, showcasing our design and development projects and sharing insights from our team.

Revving up the new

The newest iteration of is our most ambitious to date. As with most of our client engagements, the project started with research. Our Design team interviewed existing and potential clients, site visitors, and the Lullabot team to understand how people were using our site – what they wanted to get out of it, and why they visited. Our team distilled all they'd learned into goals and early wireframes for the site. They then worked with our Development staff to try to come up with the most flexible way of achieving these goals so that we could have full control of the site in ways that Drupal often doesn't afford. They wanted full <html> to </html> blue-sky design of any arbitrary page on the site without losing Drupal's amazing content management capabilities.

The technical team settled on a decoupled, isomorphic approach using Facebook's React, Node.js, CouchDB (a noSQL database) and Drupal as the backend CMS.

Content management is what Drupal does best, and this happens through a purpose-built subsite where the Lullabot team can login and post articles, podcasts, and manage their bios. Drupal pushes content into CouchDB, which exposes a REST API for React to consume. React is an isomorphic library (its code can run both in the server and the client), which means that when a visitor first visits the site, they receive the html of the entire page. Then, the rest of the navigation happens client-side, updating just the parts of the page which are different from the current one. Furthermore, React is written to be completely backward compatible with older browsers.

Our clients are often in need of API-driven native mobile apps, television-based apps, and content ingestion on connected devices. We've implemented these things in less holistic ways with our clients in the past. But the new gave us a chance to experiment with some methodologies that weren't quite tried-and-tested enough to recommend to our clients. But now that we've had a chance to see the type of flexibility they give us on, we'll be adding this to the array of architectural strategies that we can consider for our clients in the future.

Look ma, no hands!

The results are amazing; high-speed, high-performance, and superlative flexibility. In layman's terms, this means our Design and Front-end people can go crazy – implementing blue-sky ideas without the usual Drupal markup constraints. The new site is fully responsive. Articles and portfolio work pages can have giant, dazzling, full browser-height background images or videos. Articles have big text that is easy to read on any scale from large desktop monitors to the smallest phone screens. Furthermore, we did everything with an eye toward blazing fast page loads. We omitted jQuery, trading convenience in the development process for speedy page loads. Then we looked at every http request, every image, every library to make sure our website was as snappy on an older smartphone as it was on the desktop. Best of all, we off-loaded much of the heavy lifting to the client-side with React.

Design-wise, the new site is uncluttered, sparse, and relatively simple. But whether you're looking for our vast archive of articles or podcasts, information about what services Lullabot offers, who we've worked with and what we've done, or you're curious to know what it's like to work at Lullabot, it's all there.

Over the coming months, we will be writing a series of articles and doing a few podcasts talking about different aspects of the new site. Please subscribe to the Lullabot email newsletter below and you'll be the first to know when new articles are published.

Categories: Drupal

Panels curator

New Drupal Modules - 31 July 2015 - 11:32am

Panels curator provides content administration tools for panels panes groups. This allows you to group panes into groups and remove items from those buckets to limit the panes that are available.

This module allows you to create and manage panels 'groups', which can be configured so that only specific panels/panes/views/etc are available to the content editors. This greatly increases the ease of use for the In-Place editor and back-end panels admin interface.

Categories: Drupal

Midwestern Mac, LLC: Launching my first Drupal 8 website — in my basement!

Planet Drupal - 31 July 2015 - 10:48am

I've been working with Drupal 8 for a long time, keeping Honeypot and some other modules up to date, and doing some dry-runs of migrating a few smaller sites from Drupal 7 to Drupal 8, just to hone my D8 familiarity.

I finally launched a 'for real' Drupal 8 site, which is currently running on Drupal 8 HEAD—on a cluster of Raspberry Pi 2 computers in my basement! You can view the site at, and I've already started posting some articles about running Drupal 8 on the servers, how I built the cluster, some of the limitations of at-home webhosting, etc.

Categories: Drupal

OSTraining: Image Optimization with and

Planet Drupal - 31 July 2015 - 10:15am

One of the biggest factors to a slow page load is unoptimized image sizes. The bigger the image, the more time it takes the browser to load it.

This tutorial will show you the two free tools that I use to optimize images quickly.

These services will be useful whether you use WordPress, Drupal, Joomla or any other platform.

Categories: Drupal
Syndicate content

about seo