Play with Display: Altering Drupal Field Collections

How do you insert a text field into a rendered entity, all within a field collection? This question came to mind on a recent Drupal 7 build. What at first sounded complicated turned into a concise and elegant solution.

The basis of the requirement broke down into the need for events to list those participating in the event. The build already had existing Event and Profile content types, so the new functionality would only require implementing the list of Profiles participating in an event. Each participant would include their role at the event, along with links to contact them.

blog

To implement this, an Event Participant field collection was added as a field to the Event content type. Each instance of the field collection included a single Profile content type and a single text field for their role at the Event. The Profile would then be displayed as a rendered entity within the field collection so that the Profile’s image and contact links could be displayed. The point at issue then arose. How would the Participant’s role at the event be placed within the rendered Profile teaser, along with the other Profile fields? To the user it needed to look like a single unified entity, with the Profile’s image, role at the Event, Profile name, and contact links all included.

Screen Shot 2014-12-11 at 4.27.43 PM.png

After some initial brainstorming a handful of different approaches came to mind. The initial impression was to use template_preprocess_field() since it allows the alteration of values in the theme layer. The participant role field would be removed from it’s initial location and inserted into the participant profile object. This did not work though. Despite the repositioning of elements within the render array, the changes occur too late in the rendering execution. The render array had already been rendered and thus the display remained the same.

After quickly realizing a theme function wasn’t the answer, hook_node_view() came to mind. The hook allows for the alteration of a node before it is rendered and so all that would be needed would be to shift the location of the Participant Role field within the $node array. The issue with this implementation and the reason it wasn’t chosen, is that it would require reaching out to the global state to determine what changes are needed. In other words hook_node_view() doesn’t realize what context it is called under and would thus require a hack of sorts to determine when it was being called under an Event node. This could be worked around by checking the URL path, but this is not best practice as it is brittle and prone to breaking with future site updates.

As they say the third time’s the charm. The final solution was to use hook_field_collection_item_view(). This hook allows for the alteration of a field collection item before rendering. Unlike many of the other options, this hook is called for each field collection item, allowing one to both check the field collection name and adjust it’s internal field ordering, before any rendering occurs. Using this hook, each Event Participant field collection item is altered, removing the Role field and inserting it into the Profile rendered entity. Simple as that. Now each Event Participant is correctly displayed as a single unified entity, with an image, name, and a set of contact links.

Through several quick, small, iterations an elegant, straight-forward solution was found to what at first sounded like a complicated feature request. Now users viewing an Event can see a list of Participants, with each Participant displayed as a single item. Check out more on field collections on the Phase2 blog!

Drupal 8 in a Changing CMS Landscape

Recently, I’ve noticed certain trends in our industry which I believe will greatly impact the evolution of Drupal. It’s undeniable: the CMS landscape is changing as the future of the web gears toward content APIs and other ways of interacting with a content storage system. As this shift deepens, all-in-one, full-stack Drupal packages will become less important than Drupal’s ability to integrate and operate with other content stores and applications that aggregate that content for display.

There are already numerous examples of this. Social integrations (with Disqus, for instance) allow social media conversation to happen directly on the page, but not in the CMS. Other integrations, like advertisements or the injection of third-party content, demonstrate how necessary it has become for a CMS to manage external content from multiple sources. Stock tickers and quotes are a perfect example, as they inject stock quotes from external sources into their CMS instead of aggregating that content internally. Those quotes are not generated or stored within Drupal – but Drupal allows site maintainers to easily manage the location and format of that data.

imagesDrupal has proven itself to serve as an excellent structured content store, and Drupal 8 will take that a step further by enabling better access and integration into the content store. As Drupal evolves to becomes more of a robust content repository, its ability to seamlessly integrate disparate content and data will likely out-weigh its prominence as a front-end rendering engine for HTML. The front-end itself is likely to move toward being a separate application altogether, likely based in a JS framework (e.g. Angular or React) or serving the ever-growing mobile landscape. Drupal is also moving in this direction by building front-end abstractions (like Twig) that are lighter, faster, and more suitable than developing a traditional Drupal theme. This provides an opportunity to create more efficient and speedy development cycles by integrating new tools for design in Drupal that reach the web more broadly. New tools like Pattern Lab and Mustache Templates can begin to extend Drupal’s front-end capabilities in new ways, further pushing Drupal’s value as a content store rather than an engine for creating websites.

Reuters Olympic Site Content EngineEnterprise media sites have taken the lead on embracing Drupal as a unified content repository. Thomson Reuters’ 2012 Olympic site, for example, expertly utilized Drupal as a content ingestion engine. By integrating with the company’s extensive content feed service, Media Connect, Reuters accumulated photos, videos, and text articles to populate and publish through a Drupal platform. In the coming years we will become the standard approach for more media and publishing properties, and I suspect that the “enterprise” will follow suit.

These developments have an inevitable outcome which is captured by the idea of COPE (“Create Once, Publish Everywhere”), a concept illustrated beautifully by NPR’s API. COPE isn’t a new concept, but the Drupal community has only recently begun to fully utilize it in terms of ingesting content from multiple sources, as well as publishing and distributing content through multiple channels. In the coming years, COPE will manifest in a number of ways, but for the purposes of this blog post I am focusing on content APIs as the most relevant implementation of COPE for the Drupal community (for now).

Content APIs in Drupal will bring about the clean separation between content creation, storage, and management, as distinct from the display of content. This separation allows managing content with a common mechanism, yet rendering it in through a variety of experiences. It will become commonplace to build user experiences using the myriad of flexible and dynamic front-end frameworks on top of a Drupal API, capturing the potent capabilities of Drupal as a content aggregation system. Not only will building multi-channel responsive applications with amazing design be much easier, but content creators will gain greater control over access to their content. Private companies, for instance, can sell access to valuable content, while government agencies can provide public access.

Drupal 8 is an important turning point, bringing Drupal closer to the decoupled, API-favorable content engine it will evolve into – a positive development. What changes do you see in the CMS landscape, and how will Drupal play a role? Comment below!

Drushful Thinking

What is Drush?

If you’re asking that question right now then congratulations! You are one of the lucky people who will have your life changed today! Cancel everything and read up on Drush, the command line bridge to Drupal.

Everybody knows about Drush, ya Dingus!

That’s more like it. Who doesn’t love Drush, right? Right!

But more and more, I find myself seeing people reinventing things that Drush already handles because they just don’t know all that Drush can do. It’s getting frustrating, and I want to fix that.

First, The Basics

Stuff everybody knows

Here are a few Drush commands that most people know and love, just to get them out of the way:

  • drush updb: run pending database updates
  • drush cc all: clear all caches
  • drush dl <something>: download the <something> module
  • drush en <something>: enable the <something> module

Stuff everybody knows (Features Edition)

And if you’re using Features, you’re probably familiar with:

  • drush fra: revert all Features
  • drush fe: export a new or updated Feature with a new component
  • drush fu <featurename>: update the <featurename> Feature with updated site config
  • drush fr <featurename>: revert the site’s config to the current state of the <featurename> Feature

Aliases

For a lot of the fun stuff, you’ll have to understand Drush aliases. If you don’t, here’s the gist: Drush aliases give you an easy way to run Drush commands on remote Drupal sites, as opposed to only being able to use it on your local sites. If you’re constantly SSH’ing into different environments just to run a couple quick commands, you need to stop doing that.

There’s lots of documentation about Drush aliases and how to create your own, but most of the docs lack notes on some of the lesser known awesome things you can do with aliases. Keep reading, sailor.

Well, one more thing. This is probably a good time to mention a couple quick commands.

Firstly, let’s run an arbitrary shell command on our dev environment.

Or maybe we should just go ahead and SSH in to do something a little more complex.

Or maybe we need to do a bunch of aliased commands, but we want to do it without SSH’ing in (because the commands require local files or something). We can make a Drush alias persist until we tell it to stop using:

And then when we’re done doing what we do, we can just run it again without the “@foo-dev” argument to unset it.

Now, keep reading, sailor.

Syncing Ship

(Warning: these headlines are going to get worse and worse)

One of the most common things to do with Drush aliases is to sync stuff from one alias to another.

For example, want to sync the dev site database down into your local?

How about files? Sync ‘em!

Or maybe some unwashed sent you a DB dump and you have to import it the old fashioned way?

Sometimes you want to drop your entire database before importing, to make sure you don’t get any tables left behind from your old install that aren’t supposed to be there. That’s as easy as:

Sometimes, it’s useful to be able to automate running arbitrary SQL commands on multiple environments, and that’s pretty easy too. Say for example that you quickly want to get the username for uid 1 on the prod environment (the “drush user-information” command would be much better for this, but shut up).

That one is also good for automation, like if you want to write a quick script that changes the username for uid 1 on all environments.

Drupal Without Drupal

It’s often useful to run one-off arbitrary code within the context of Drupal, without having to actually put it in the codebase somewhere. This is typically done one of two ways:

If it’s just a short one-liner, then there’s the ever-useful “php-eval” (aka “ev”) command. For example, let’s inspect a node object.

Or if it’s a longer one, then we can just throw our code into a PHP file, and run it using:

Reports Cohorts

Drush is really good at getting us information from Drupal without waiting for a full page load.

How many times have you navigated to the Watchdog page and sat through page load after page load while you went through the pagination and added filtering and blah blah blah to find an error message? Stop doing that! Do this instead:

There are a lot of useful options for watchdog-show, such as:

  • –tail (continuously show new messages)
  • –full (show the full output, with all of the fields, instead of the summarized version)
  • –severity (such as “–severity=error”)
  • –count (show more than the default 10, such as “–count=100″)

And I’d bet you’re familiar with “drush vget” to get variables, but did you know you can pass “–format=whatever” to get the results formatted as JSON or CSV or YAML or a bunch of other things, for easy scripting?

Another one of my favorites is this charm, which basically prints out the stuff you see on the Status Report page in Drupal. It’s nice for sanity checking before pushing releases live.

And then there’s this guy, which prints out a bunch of useful info about the current installation, such as DB info, path to PHP executable and .ini file, Drupal version, Drupal root, etc. It’s a nice first step when debugging a broken install.

And for those times when you need to edit a config file (php.ini, or settings.php, or an alias file, or .htaccess, etc.), you can run this to let you choose which of those files to edit and it’ll open it up in an editor for you:

Using Users

Drush is nothing short of a miracle when it comes to user management.

First of all, there’s the ever-annoying task of logging in as this user or that user. You usually don’t know the password, or maybe you’re just too lazy to type it. Run this to open up your browser with a one-time login link so you can skip all of that malarky:

Or, if you’re slightly less lazy, and just want to change the password to something so that you can log in the old fashioned way:

Then there’s the “fun” process of adding a user and filling out the form. Skip that:

Once that’s done, you probably want to give that new user some roles. For role stuff, you have this:

But watch out! The role you need to add doesn’t exist yet! Let’s add it, and give it some permissions.

If you just need to show information about a user, such as email address, roles, UID, etc., try this. I’m embarrassed to say that I’ve been using raw SQL for this for years.

Fields of Dreams

One of the most under-used things that Drush gives you is field management tools. I’m going to be lame here and just copy and paste the docs, since they’re pretty self explanatory.

Other Schtuff

Here are some great commands that don’t really fit into any clear-cut categories.

It has some neat archiving tools:

Somewhat similar to those is this one, which will download and install Drupal, serve it using a little built-in server, and log you in, all in one command. Note that this one includes about a bazillion options and is super duper powerful.

Drush also lets you play with the cache, which can save a lot of time when debugging a caching issue:

There are a couple unknown commands for working with contrib:

Run cron! Not exciting, but super useful.

Have you ever been in the middle of debugging and you know that something is happening in a form_alter (or some other hook) but you’re not sure in which module? Try this command, which will tell you all of the implementations of a given hook, and let you choose one to view the source code of it.

And finally, this bad boy is basically “Drush docs in a box” and has a TON of useful info. Seriously, try it now.

Drushful Thinking

There’s a giant heap of useful Drush commands, some of which you hopefully hadn’t seen before. So what, right?

The “so what” is that it’s useful to start thinking in terms of “how can Drush do this for me?” and you’ll often find that the answer is “pretty easily.”

Play a game with yourself. Next time you’re working on site building or anything that involves a lot of clicky clicky in the Drupal UI, give yourself a jellybean or a chip or something every time you do something in Drush instead of in the UI.

But why? Well for one, before you know it, you’ll be spending  much less time waiting on page loads. But secondly, Drush lends itself to automation, and thinking in terms of Drush naturally leads you to think in terms of automating and scripting things, which is a great place to be.

Practice some Drushful Thinking! And let me know any of your favorite Drush tips and tricks in the comments. Check out drushcommands.com for some more inspiration.

Make Your Product Vision Real – A Case for Incorporating Prototyping Into Your Next Project

As product designers and experience strategists, we research how people use systems and design products that tap into users’ natural behaviors. We want people to instinctively know how our product works.

Years of research into the human mind tells us that our brains love patterns, the repeated way in which something happens or is done. Our subconscious mind uses what we’ve learned from patterns – like turning a knob will open a door – to instinctively make decisions about what we do throughout our day. This is why we can walk or breathe without thinking about it – we spend most of our time running on autopilot.

We have an understanding of how people make decisions, but we forget to apply this knowledge when communicating our product vision to stakeholders.

There are Drawbacks to Designing in the Abstract

Experience design deliverables, or artifacts, are abstract. We too often produce artifacts, intended to build a shared understanding of a product vision, that are hard to understand. Low-fidelity wireframes and complex flow diagrams require stakeholders to think hard about what we are trying to communicate. They mentally fill in the gaps where we lack details. We consistently break Steve Krug’s number one rule: “Don’t make me think!”

Imagine how these abstract artifacts skew conversations about a product:

We show a stakeholder some wireframes and talk them through the features. Once they see them they begin to imagine the ways features will look and act based on similar products they have used.

While perfectly natural, this behavior is problematic – what we envision may be nothing like products this stakeholder has previously used. These assumptions your stakeholder makes will lead to you and your stakeholders having different expectations during product development.

You need to make artifacts as real as possible in order to elicit the most unbiased, unimpeachable feedback from users during research. You do not need to build a fully functioning product to validate your idea.You do need to eliminate or reduce the guesswork needed to understand how your product will work.

Make Your Product Vision Real

Prototyping is a great way to eliminate ambiguity so that you get the best results from user research. A prototype is a preliminary model of a product used to show a concept or validate an idea. A prototype should only contain the minimum amount of content, design and functionality needed to demonstrate how the end-product will function.

Context is key to determining fidelity of a prototype. If you are conducting user testing with a tech-savvy group of stakeholders, clickable wireframes may suffice. If you are introducing a new concept to a set of clients, then you may need a higher-fidelity, interactive web page. Your prototype should only contain the fidelity needed to have a meaningful conversation with your users about your product.

Build The Right Prototype For You

There are many different approaches to building prototypes. You can link wireframes together to show user flow with a system like inVision, or build interactive features using an open source CMS like Drupal.

When creating prototypes, make sure to include the following:

  1. The main actions that a user can take and the reactions they will receive from interactive elements.

  2. The key messages you want to communicate to users at different stages of their interaction.

  3. A programmatic way to track user behavior while they use the prototype.

Get Better Results from Your Projects

Some of the many benefits of prototyping are:

  • It produces more accurate results from user testing, allowing you to better determine what works and what doesn’t.

  • It gives you more opportunity to focus on interaction design by forcing you to have conversations about interactive elements during user research rather than development.

  • Prototypes bring less-apparent usability issues to light earlier in the development process.

  • You have a potential starting point to work from when beginning development, minimizing the amount of work that needs to be done in the long run.

John Whalen said “UX does not happen on a screen. It happens here. In the mind.” Keep that in mind (no pun intended) as you seek to build a shared understanding of, and validate, your product ideas. The more real you make the experience of interacting with your product early in the design process, the more accurate a feedback you will get from your users. For more thoughts on prototyping, check out Frederic Mitchell’s “Static Prototyping and Keeping Drupal Simple (KDS)” and “The Devil’s in The Details” by Sharon Smith!

Transitioning to Drupal 8 templates with Twig

As many of us know, Drupal 8 beta was released at the beginning of October which has given us a great preview of the goodies to come. One of those goodies is a new theme engine, Twig, which replaces PHPTemplate. Twig gives us a lot of extra power over our templates and allows us to clean up a lot of the extra cruft that PHPTemplate forced us to add.

So you may be asking, how will our brand new Drupal 8 templates look? Well they are going to be a lot leaner. The extra cruft of php tags, functions, and other miscellaneous bits are no longer needed – in fact, they don’t even work in Twig templates. Arguably, it will be easier to read at a glance what is happening in the Twig versions of Drupal templates. For a great example of how the new templates will look, we can crack open the Views module and compare the templates in the Views module 7.x version to the ones in the Views 8.x version. So let’s compare the views-view.tpl.php file from Views 7.x to views-view.html.twig file in Views 8.x.

Views-compare-part-oneViews-compare-part-two

Twig Comments

Starting from the top, lets work our way down to see what has changed. In the documentation section we can see that for the large block of comments, as well as single line comments, the {# #} syntax is used.

In the list of variables variables that are available to use, you may notice a few other changes. For example, Twig is not raw PHP, so the ‘$’ is not used at the beginning of variable names. Another change is that is that the $classes_array has been replaced by the attributes variable.

Rendering Variables

 Views-compare_example_one

Moving down to line #40 we can see the first instance of a variables rendered using Twig. The double curly bracket syntax, {{ my_variable }}, tells Twig that this is a variable and it needs to be rendered out. A variation of this syntax uses dot-notation to render variables contained in an array/object. This syntax looks like {{ my_variable.property_or_element }}, which makes it extremely easy to use. Dot notation is not used in this particular Twig template.

Twig Filters

Another powerful feature of Twig is template filters. Filters allow us to do simple manipulations of variables. The syntax for using a filter is similar to the syntax for rendering a variable. The difference is that after the variable name, you insert a | (pipe), followed by the name of the filter. For an example to make a string from a variable all lowercase you would do {{ variable_name|lower }} which transform all of the characters to lowercase. If you have used templating systems from other frameworks, such as Angular.js, this syntax may look familiar to you. This particular Views template does not use filters, but you can see examples of different filters on the Twig documentation site. If none of the predefined filters satisfy your requirements, you can extend Twig to create your own filter. The Twig documentation site provides details about creating your own custom filters..

Twig Logic

Views-compare_example_two

Jumping to line #42, we can see the {% %} (curly-bracket and percentage symbol) syntax, which is used for template logic, such as if statements. This syntax tells Twig that we are not rendering something, but rather that we need to process some logic, such as a control structure or loop, in our template.

The Takeaway

This blog post is a high level overview of how Twig templates in Drupal 8 will look.  With Twig, we can choose to use the out-of-the box tools it provides, or we can dive in and extend it with additional features such as new filters. For more information I would highly recommend reading through the Twig documentation for designers and for developers.

BADCamp Sprinting Success Story : Drush make files support YAML

After a very successful drush code-sprint at BADCamp 2014, drush make now supports YAML format!

Instead of the old INI format

YAML can be used with the latest version of Drush 7:

Included .make files whether local, or discovered recursively within downloaded projects, can be in either YAML of INI format.

In order to use the newly-supported YAML format, simply name files with a .yml extension, such as my_project.make.yml.

The best part? This can be used now! Even though YAML files are mostly a new concept for Drupal 8, drush make will parse YAML make files for Drupal 7, and even Drupal 6. Want to learn more about DRUSH make files? Check out Joe Turgeon’s “Getting Started With Grunt Drupal Tasks

AngularJS Meet Open Atrium

atrium-logo (1) The recent 2.23 version of Open Atrium contains a cool new interactive site builder and navigator application (see it in action). This application was written using the AngularJS framework.  The combination of Drupal, jQuery, and AngularJS proved to be powerful, but wasn’t without some pitfalls.

Using AngularJS in Drupal

AngularJS-large The basics of using Angular within Drupal is pretty straight-forward.  Simply reference the external AngularJS scripts using the drupal_add_js() function, then add your custom javascript app code, then use a tpl template to generate the markup including the normal Angular tags.  For example, here is the Drupal module code, javascript and template for a simple Angular app:

Now, obviously we aren’t using the full Angular framework here.  We aren’t using any directives, nor are we really using Angular as a MVC framework.  But it gives you the idea of how easy it is to get started playing with basic Angular functionality.

Angular plus jQuery

Developing javascript applications in Angular requires a different mindset from normal Drupal and jQuery development.  In jQuery you are often manipulating the DOM directly, whereas Angular is a full framework that allows data to be bound and manipulated on page elements.  Trying to combine both is often a source of frustration unless you understand more about how Angular works behind the scenes. Specifically, Angular has it’s own execution loop causing a mix of Angular and jQuery code to not seem to execute in a straightforward order.  For example, in the above code, we set the class of the H3 based on the current “count” variable.  What if we modified the updateCount function to try and set a css property for this class:

If you click the button you’ll notice that the css color does NOT change to red! The problem is that Angular is executing the query function call BEFORE it actually updates the page.  You need to delay the jQuery so it executes after the current Angular event loop is finished.  If you change the code to:

then it will work.  The timeout value can be anything greater than zero.  It just needs to be something to take the jQuery execution outside the Angular loop. Now, that was a horrid example!  You would never actually manipulate the css and class properties like this in a real application.  But it was a simple way to demonstrate some of the possible pitfalls waiting to trap you when mixing jQuery with Angular.

Drupal Behaviors

When doing javascript the “Drupal way”, you typically create a behavior “attach” handler.  Drupal executes all of the behaviors when the page is updated, passing the context of what part of the page has changed.  For example, in an Ajax update, the DOM that was updated by Ajax is passed as the context to all attached behavior functions. Angular doesn’t know anything about these behaviors.  When Angular updates something on the page, the behaviors are never called.  If you need something updated from a Drupal behavior, you need to call Drupal.attachBehaviors() directly.

Angular with CTools modals

In the Open Atrium site map, we have buttons for adding a New Space or New Section.  These are links to the Open Atrium Wizard module which wraps the normal Drupal node/add form into a CTools modal popup and groups the fields into “steps” that can be shown within vertical tabs.  This is used to provide a simpler content creation wizard for new users who don’t need to see the full node/all form, and yet still allows all modules that hook into this form via form_alters to work as expected. The tricky part of this is that as you navigate through the sitemap, Angular is updating the URLs of these “New” links.  But CTools creates a Drupal Ajax object for each link with the “ctools-use-modal” class in it’s Drupal behavior javascript.  This causes the URL of the first link to be cached.  When Angular updates the page and changes the link URLs, this Ajax object cache is not updated. To solve this within the Open Atrium Sitemap app, an event is called when the page is updated, and we update the cached Ajax object directly via the Drupal.ajax array. This was a rather kludgy way to handle it.  Ultimately it would be better to create a true Angular “Directive” that encapsulates the CTools modal requirements in a way that is more reusable.

Summary

Angular can be a very useful framework for building highly interactive front-ends.  Using Drupal as the backend is relatively straight-forward.  Angular allowed us to create a very cool and intuitive interface for navigating and creating content quickly within Open Atrium far easier than it would have been in jQuery alone.  In fact, we began the interactive site map tool in jQuery and the code quickly became unmanageable.  Adding functionality such as drag/drop for rearranging your spaces and sections would have been a mess in jQuery.  In Angular it was very straight-forward. Once you understand how Angular works, you’ll be able to blend the best of Drupal + jQuery + Angular into very rich interfaces.  Programming in Angular is very different.  Learn more about Angular on the Phase2 blog!

Hallway to the Future: Reflections of a Drupal Enthusiast

Before we go to the future, a little detour to the past…

Enjoy the view from the top of the center of knowledge and mysticism of the Incas, facilitated by the incredible #DrupalPicchu.

Seven years ago, I decided to go in a new direction. I left the non-profit I’d been working for, which focused on my exact academic interests, to join an entertainment company. There, I would be a part of  a team building and using an internet system covered in nodes, blocks, exposed integers and pagers that run on computer time: Drupal.

As I looked into the future, this modular open source “content holder software” seemed poised to be a springboard for a lot of smart, kind, passionate people to come together and build something greater than themselves.

Community is Key

Fueled by meetups, the community has a very involved distributed culture and communication network in which people form alliances around ideas.  There were a lot of aspects reminiscent of some of the indigenous communities funded by the NGO where I’d previously worked. The center of both was “the community” or in Spanish “la communidad.”  Even in a big company, the community is a major part of the story when open source is involved.

Screen Shot 2014-09-04 at 11.09.45 AM

Some Sony connected Drupalers at DC Chicago. Photo credit: Thomas Turnbull

About 2.5 years ago, I started a new chapter at Phase2, continuing along the path that I had started when I decided to see what all the Drupal fuss was about.

Screen Shot 2014-09-04 at 11.10.46 AM

Phase2 orange related sign I saw in a cornfield.

As one of the leaders in open source and big Drupal, Phase2 has a high concentration of smart, talented and passionate people in addition to the amazing clients we work with to build amazing open source web systems.

DSCF1631

Phase2 team at DC Austin

It’s All Happening.

Seven years later, we stand on the cusp of a very interesting time for open source. Drupal powers a key segment of the web, and its societal power to influence culture is outstanding. You can petition the president, donate to poverty fighting in NYC, buy a bicycle, keep up to date with latest science news or local news,  watch college sports, discuss servers and what software lives on them, coordinate the large amount of information on a humanitarian crisis, catch the latest music video, decide what to major in at your University, visualize a social movement, hear about the latest in international crowd funding,  and launch your own indigenous digital asset management library.

Drupal is not only the enterprise system of record for open source, but it is growing in leaps and bounds throughout the world, supported by its sophisticated multi-lingual underpinning. Over the last year, I’ve had the incredible opportunity to get to know the international community even more through attending and speaking at several amazing camps in South and Central America: Drupal Summit Loja, Drupal Camp Costa Rica, Drupal Picchu & Drupal Camp Mexico City.

Screen Shot 2014-09-04 at 11.14.45 AM

Drupal Picchu group shot via Cristian Torres

Right now, Drupal powers academic institutions, Fortune 500 platforms, and global non-profits. This is Drupal. This is what we have to start from! Not to mention Drupal’s greatest asset: the incredible community of people that develop its core, use it to get their content to the world, make it easy to host, consult on strategies, and share approaches with others.

Looking to the Future of Open Source…

Just imagine – if all of the above has happened in the last seven years, what will the next 11 bring?

While the technical advances in Drupal 8 are amazing, it’s the implications for the communities around Drupal which I feel most connected to.

  • We are becoming more accessible to non-English languages through the #D8MI (Drupal Multilingual headed up by Gábor Hojtsy). This will allow Drupal to become more globalized than it already is, opening up our ability to interact with even more communities around the world.

  • We are becoming more technically accessible as well accessible. By Drupal adopting HTML5, we make it easier to create responsive, and accessible websites for a greater range of abilities and technical capacities.

  • Through the ideas in the Drupal as a RESTful data store it will become even easier for us to integrate with other software projects, making us more collaborative, and creating a more positive and open world.

As Drupal continues to evolve in the open source space and expand globally, I hope to see more inspiring stories like this one of a community using open source technology to build and operate their own cellular networks in rural Mexico.

I look forward to continuing to engage and be a part of this awesome community, and I’d like to hear your story as well. How did you get involved in our eclectic and awesome community? In what ways are you most excited to see Drupal evolve in the future?

If you are in the Bay Area this week, check out the Bay Area Drupal Camp (BADCamp) November 6th-9th.  This completely free, volunteer run 4 day conference is yet another example of the power of open source community.  Join me at the BADCamp non profit summit tomorrow to learn how nonprofits are leveraging Drupal to further their organization’s missions and ultimately contribute to our shared global community.

And for those international adventurers and folks in Latin – the first DrupalCon Latin America is February in Bogota, Colombia #vamosalfuturo.

 

Getting Started with Grunt Drupal Tasks

In September, Phase2 released a Grunt-based tool for building and testing Drupal sites. We have been working on the tool since January, and after adopting it as part of our standard approach for new Drupal sites, we wanted to contribute it back to the community. We are happy invite you to get started with Grunt Drupal Tasks.

Grunt is a popular JavaScript-based task runner, meaning it’s a framework for automating tasks. It’s gained traction for automating common development tasks, like compiling CSS from Sass, minifying JavaScript, generating sprites, checking code standards, and more. There are thousands of plugins available that can be implemented out-of-the-box to do these common tasks or integrate with other supporting tools. (I mentioned that this is all free and open source software, right?)

Grunt Drupal Tasks is a Grunt plugin that defines processes that we have identified as best practices for building and testing Drupal sites.

Building Drupal

The cornerstone of Grunt Drupal Tasks is the “build” process, which assembles a runnable Drupal site docroot from a Drush make file and custom code and configuration.

The make file defines the version of Drupal core to use, the contrib modules, themes, and libraries to download, and even patches to apply to any of these components. The make file can include components released on Drupal.org or stored in public or private repositories. For patches, our best practice is to reference patches hosted on Drupal.org and associated with an issue. With these options, the entire set of components for a Drupal site can be declared in a make file and consistently retrieved using Drush.

After the Drush make process assembles all external dependencies for the project, the Grunt Drupal Tasks build process adds custom code and configuration. This includes custom installation profiles, modules, and themes, as well as “sites” directory files, like sites.php and settings.php for one or many subsites, and other “static” files to override, like .htaccess and robots.txt. These custom components are added to the built docroot by symlink, so it is not necessary to rebuild for every update to custom source code.

These steps results in a Drupal docroot assembled from custom source in the following structure:

Grunt Drupal Tasks includes other optional build steps, which can be enabled as needed for projects. One such task is the “compile theme” step will compile Sass files into CSS.

This build process gives us a reliable way for assembling Drupal core and contrib components, for adding our custom code, and integrating development tools like Sass. By using Grunt to automate this procedure, it becomes a portable script that can be shared among the project’s developers and used in deployment environments.

Testing Drupal

In order to help make best practices the default, Grunt Drupal Tasks includes support for a number of code quality and testing tools.

A “validate” task is provided that includes checking basic PHP syntax and Drupal coding standards using PHPLint and PHP Code Sniffer. We highly recommended that developers use this command while coding, and have included it as part of the default build process.

An “analyze” task is also provided, which adds support for the PHP Mess Detector. This task may be longer-running, so it is better suited to run as part of a continuous integration system, like Jenkins.

Finally, a “behat” task is provided for running test scenarios with Behat and the Drupal Extension. This encourages writing Behat tests for the project and committing them with the project code and build tools, so the tests can be run by other developers and in the integration environment by a continuous integration system.

Scaffolding for Drupal Projects

The old starting point for Drupal projects was a vanilla copy of Drupal core. Grunt Drupal Tasks offers scaffolding for Drupal projects that starts with Drush make, integrates custom code and overrides, and provides consistent support for a variety of developer tools.

This scaffolding is provided through the example included with Grunt Drupal Tasks, which is the recommended starting point for new projects. The scaffold structure adds a layer above the aforementioned “src” directory; this layer includes code and configuration related to Grunt Drupal Tasks (Gruntconfig.json and Gruntfile.js), dependencies for the supporting tools (composer.json), and other resources for the tools (features/, behat.yml, and phpmd.xml).

The example includes the following:

For full documentation on starting a new project with Grunt Drupal Tasks, see CONFIG.md.

Learning More

Watch the Phase2 blog for more information about Grunt Drupal Tasks. If you are attending the Bay Area Drupal Camp this week, please check out my session on Using Grunt to Manage Drupal Build and Testing Tools.

Introducing the Behat Drupal Extension 3.0

I am proud to announce the release of the Behat Drupal Extension 3.0! Since 2012, the Drupal Extension has been used for Behaviour Driven Development of thousands of Drupal sites all over the world. The project began as part of the Drupal.org upgrade, and was quickly generalized to enable the testing of any Drupal site.

Version 3 has many exciting new features, and is compatible with Behat 3. Note version 2 does not exist, wanting to avoid version soup.

Behavior Driven Development at BADCamp

Before I dive into the new features, it is important to clarify the difference between testing an application, and Behavior Driven Development (BDD).

As everzet pointed out at Drupalcon no business-critical feature starts with

rather, it starts with a conversation

While both are testing something, only the latter is truly describing a behavior that matters to a stakeholder. This is the subject of a blog post, or series of posts, in and of itself, so more on this subject later.

What’s new

Documentation

Documentation for this project has been integrated into the repository, and is automatically building on readthedocs.org. Thanks to Melissa Anderson for this awesome work!

A starter context

A starter Drupal context that makes no assumptions around the language used for each test, but still provides all the previous functionality to interact directly with Drupal.

Users are encouraged to start tests from this context which will allow them to use truly ubiquitous language that is specific to each project.

Drupal Drivers

The Drupal Drivers now exist in a separate project, allowing for non-Behat applications to interact with Drupal (e.g., calling directly from Mink, or Codeception).

Note that the Drupal 6 driver has been removed, but since drivers are now separate projects, it will be easy to port that over to the Drupal Extension 3, should somebody want.

It should also be noted that Drupal 8 support will require ongoing work as the code base there evolves towards release.

More granular pre-defined step-definitions

Existing step definitions have been split into 4 indepentent contexts:

  • DrupalContext – This contains steps for working with content, users, and taxonomies.
  • MinkContext – This is an extension to the Mink Extension, providing additional steps for working with regions and forms.
  • MessageContext – Provides steps for working with Drupal success/warning/error messages.
  • DrushContext – Provides steps for calling drush commands directly from scenarios

This allows for the use of some pre-definied step-definitions, rather than the previous all-or-none approach.

No more regex!

The pre-definied steps now use the new turnip syntax introduced in Behat 3:

rather than

What’s a ‘node’?!

The term node has been removed from steps and replaced with content in all pre-defined steps.

What’s next?

BDD Mini Summit

I will be attending the Behat mini-summit at BADCamp along with several other folks from Phase 2. I hope to highlight the Drupal Extension 3, and discuss best-practices for the wide variety of testing needs. I also hope to continue discussions around Behat, Mink and Drupal core.