Apr 23 2019
Apr 23

One key theme was constant throughout the entire event: experience. While experience is nothing new, something felt different. The focus on experience at DrupalCon 2019 was truly authentic, and during the event these three things really stuck out:

Drupal community experience

The Drupal community is committed to creating a collaborative space for all contributors. At the Driesnote, this point was reinforced by the focus on Diversity and Inclusion to improve everyone’s experience on the Drupal platform. Seeing what the community had contributed in 2018, and what is to come for Drupal migrations and platform, was inspiring.

Commitment to Drupal platform development to better deliver customer experiences

Sessions throughout the week highlighted improving customer experiences. Experience accompanying development is not a new concept, but we saw how contributors are bringing that to life. Drupal itself is evolving to enable improved customer experiences, which allows us to eliminate technical barriers other platforms are still struggling with.

DrupalCon experiences - for all Drupal users

The community’s relentless focus on improving the platform for not only developers, but content editors and digital marketers were recognized with the addition of two content tracks: Content Editors and Digital Marketers, and Decision Makers. I was also privileged to host a training session for community members in project management to further expand resources at DrupalCon for non-developers.


At DrupalCon 2019 Seattle, our team not only learned about many of the advancements in the Drupal community, but we were also able to share our experiences, learnings and case studies from our recent Drupal work. In case you missed, or would like to learn more, check out these FFW session recordings:

Building Websites for the Asian Market

Businesses are always taking opportunities for growth and are looking to expand to new markets. One of the emerging areas where a lot of companies are looking to build a presence is Asia. Acquiring new customers in a new market and then serving them means that all these companies need a website/digital footprint to serve the target audience.

FFW team members, Andrew Wilden, Director of Solutions & Strategy, and Adriana Mosnoi, Senior Project Manager, discuss customizing user experiences for the Asian market and how translation is simply not sufficient for design and building websites that are relevant for diverse cultures.

Stanford and FFW - Defaulting to Open

For higher education institutes, every bit of the digital budget counts. While it can be hard to justify investing money back into open source projects, the Stanford Web Services has gotten a lot back from their investments into Drupal.

This session discusses how organizations — both on the agency side and on the client side — maximized their ROI by investing back into the Drupal community. Andrew Willden, Director of Solutions & Strategy, FFW and Alison Ho, Web Project Manager, Stanford Web Services, share how those investments have helped Stanford Web Services do even more, better.

30 Minutes to Actionable Strategies that will Improve Customer Experience

Ever feel like you're jumping from one problem to the next putting out fires but never get the bandwidth to implement longer term solutions?  Learn how to create actionable strategies to improve customer experiences. I cover the importance of establishing baseline assessments and measuring progress through regular formal audits of your content, architecture, workflow and infrastructure to seize opportunities that will strengthen visitor journeys and increase conversions.

Drupal Blue/Green Deployment with AWS ECS

Drupal deployments are hard. You have to make sure your code is deployed, composer dependencies are pulled, schema updates are performed and caches cleared, all while keeping your website up and responsive for the users. Add in the complexity of hosting on multiple servers and users updating content 24/7, it gets even more interesting.

Blue/Green deployments is the solution to this problem, Alexei Gorobet, Group Architect, asgorobet, shares how to do that with Drupal.


We’re already looking ahead to DrupalCon 2020 in Minneapolis. If you have feedback on FFW content or ideas for 30 minute lightning sessions, I would love to hear it. You can send me suggestions directly on Drupal.org at rgs.

Want to continue expanding your Drupal knowledge outside of DrupalCon? Check out our calendar of upcoming trainings. Also click here to view all of our all learning resources.

Jan 09 2019
Jan 09

Drupal 9 is coming. Even if it feels like you only just upgraded to Drupal 8, soon it’ll be time to make the switch to the next version. Fortunately, the shift from Drupal 8 to Drupal 9 should be relatively painless for most organizations. Here’s why.

A little background

Though tools were built in to make the upgrade from Drupal 6 or 7 to Drupal 8 run as smoothly as possible, it could still be a difficult or dramatic process. Drupal 8 marked a major shift for the Drupal world: it introduced major new dependencies, such as Symfony, and a host of new features in Core. The new structure of the software made it tricky to upgrade sites in the first place, which was complicated by the fact that it took a long time for a number of modules to be properly optimized and secured for the new version.

Drupal 9: A natural extension of Drupal 8

Fortunately, the large number of changes made to the Drupal platform in Drupal 8 have made it relatively simple to build, expand, and upgrade for the future. The new software has been designed specifically to make it simple to transition between Drupal 8 and Drupal 9, so that making the migration requires little more work than upgrading between minor version of Drupal 8.

In fact, as Dries Buytaert (the founder and project lead of Drupal) wrote recently in a blog on Drupal.org:

Instead of working on Drupal 9 in a separate codebase, we are building Drupal 9 in Drupal 8. This means that we are adding new functionality as backwards-compatible code and experimental features. Once the code becomes stable, we deprecate any old functionality.

Planning for Drupal 9

As more information is released about the new features and updates in Drupal 9, organizations should consider their digital roadmaps and how the new platform will affect them. And regardless of what your plans are feature-wise, your organization should begin planning to upgrade to Drupal 9 no later than summer of 2021. The reason for that is because the projected end-of-life for the Drupal 8 software is November of 2021, when Symfony 3 (Drupal 8’s largest major dependency) will no longer be supported by its own community.

In the meantime, the best thing your organization can do to prepare for the launch of Drupal 9 is to make sure that you keep your Drupal 8 site fully up to date.

For help planning out your Drupal roadmap, and to make sure that you’ll be ready for a smooth upgrade to Drupal 9 when it releases, contact FFW. We’re here to help you plan out your long-term Drupal strategy and make sure that your team can make the most of your site today, tomorrow, and after Drupal 9 is released.

Dec 14 2017
Dec 14

For anyone who's ever looked up a definition of a Drupal term and still wondered what it means, here are some practical explanations you can use to navigate the Drupal-verse. This is the latest in a series on Drupal-specific terminology.


Regions divide Drupal pages into different sections. Each section contains information that determines the positions of various elements. These elements can include menus, headers, footers, and sidebars. The elements in each Region are called Blocks. (For more information on Blocks, see Aliases, Blocks, and Content Types.)

A Drupal site's active theme keeps information on the number, name, and location of each Region. Different themes can have different Regions. Typically, administrative themes have fewer regions spaced in wide columns across a page. The themes that face a site's end-users often have more complex layouts, which means more Regions. (To learn more about Themes, see Article, Base Theme, Content.

Together, Blocks and Regions make up Drupal's core's primary layout functionality. This combination is a simple yet powerful solution that has been steadily expanded with each major version of Drupal. 

As a note: Drupal Regions can be overridden by contributed modules such as Panels. Regions can also be overridden by custom page templates that apply to specific URLs or URL alias patterns. While the use of Panels can increase overhead and complexity, it makes additional layouts and landing page capabilities available to site builders. Layouts made with Panels are saved in the site's database, which mitigates the risk of rolling custom code by editing a site's theme files.


A Drupal Revision is a saved version of a set of changes to a piece of Drupal content created with a Content Entity. Revisions apply to any piece of content on a site, including Articles, Basic Pages, and custom content types.

After a piece of content is created, any changes or updates made to the content are saved in new versions, or Revisions. Drupal does this rather than editing an existing published version. These versions are stored indefinitely each time a set of changes is saved, and can be found on a content item's administrative interface. Users can save revisions in unpublished draft form, to be published at a later date. Previous versions can also be republished, which allows content authors to revert content to an earlier state.

Drupal's core revision feature supports a powerful workflow functionality that can be custom-configured to align with an organization's processes for content approval. Revision functionality can also be extended with the contributed Diff module to highlight changes between various drafts.


Roles assign various permissions to a Drupal site's users. This includes the ability to edit and manage content and configure settings. Roles are typically grouped into sets of permissions that are determined by a user's expertise in the organization. A Role is a user-defined set of permissions that can be granted to groups of individuals. Typical Drupal user roles include Administrator (preconfigured), Content Creator, and Content Manager.

Anonymous and Authenticated are two special preconfigured user states that are accessed through the user administrative pages. Anonymous users are typically granted only the most basic permissions. By definition, Authenticated users are those that are known to the system. Authenticated users have an account and unique email address that associated with a cookie that resides locally in their browser.

When new functionality is added to Drupal, additional permissions are typically added to the system. These permissions can then be assigned to new or existing roles.

What Next?

If you've got questions about specific Drupal terms, let us know. Drop a request for a definition in the comments and we'll add it to our next ABCs of Drupal post. 

Aug 31 2017
Aug 31

The web has no shortage of digital trends that will pop up on your radar, and one whose momentum has increased over the last couple years is decoupling. In simple terms, the concept of decoupling means separating the frontend of your website from the backend. This means the components of a site that a visitor sees and interacts with (menus, page content, widgets) are built and displayed by software running in the web browser. The backend software, running on the server, accepts requests from the frontend for these different page components and returns them as essentially raw data.

With this full separation of concerns, each half of the website can focus on what it does best; the backend focusing on business logic and retrieval of data, the frontend focusing on display and user experience.

How Do We Achieve This?

This is where JavaScript frontend frameworks come into play. Popular ones include Angular, which we at FFW have used quite successfully on projects, or React, Ember, and many others too numerous to count. These frameworks enable a skilled developer to build a complex and highly interactive frontend without constant page refreshes that require the full attention of the backend.

To do this, it helps to have a powerful and flexible content management system, which doesn’t require lots of custom programming and reinvention of the wheel. This is where Drupal comes in. We’ve done this quite successfully with Drupal due to its robust and flexible API. Drupal 8 pushes this even further with its API first approach, and superior set of APIs.

Drupal 8 Services

Things like the built-in RESTful web services and superior content modeling tools do most of the work of building that backend system. Eventually the backend will communicate effortlessly with frontend systems and other applications and third-party service. This makes Drupal an effective content hub for distributing your content to any application that needs it.

Pros and Cons

When introducing anything new there are various factors to consider. A decoupled fronted can improve perceived performance and enhance interactivity. It can also do something very difficult with a fully baked content management system, where all rendering is handled by the backend. It enables developers and development teams to design and build a frontend almost completely independently from how the backend is developed. Your templating system, how CSS is built and managed, preferred methods for design components, all this can be treated like a separate project. Your designers and frontend developers don’t even have to have skills specific to the CMS you are using.

Life, of course, is never perfect. The main drawbacks become apparent when really thinking about how all this affects the way your site is built and managed. When using a CMS like Drupal, you start losing a lot of the key features that make it the tool it is. Can you use Drupal’s site building tools to, for example, change the order of fields displayed on a page? Things like that are now being hard-coded into the frontend. We also start losing some of the multilingual features, it plays less nice with metatags and other SEO features, and potentially increases the amount of work and skills needed to build your website. Those aren’t all unsolvable problems, but you’ll need to consider them when deciding where you are willing to devote the development time to building a decoupled site.

Two Approaches

If you understand the concept of separating your frontend and backend, you’ll start seeing two approaches while doing your research. “Headless” Drupal, which just means a fully decoupled frontend. The other is “progressive” decoupling. “What the heck is that?” you might say. Progressive decoupling blurs the line between what the frontend and backend are doing, rather than fully decoupling the two.

Progressive decoupling starts with a traditional website approach, with no decoupling, and the backend doing most of the work to produce the web page. Then, individual components that are deemed more interactive or take longer to produce are handled by the frontend. This approach plays a little more nicely with tools already present in your CMS, and is easier to implement on any existing website.

New Hotness Can Burn

Decoupling a website is a great way to solve some problems of the traditional website module. We certainly advocate it for projects suffering from those problems. But, as with all technology, make sure your use case has the need before forcing technology onto it. The decoupling approach can revolutionize your site visitor’s experience, but if forced to fit it can create new problems, increase development time, and inflate your costs.

A simple site, with few frontend performance problems, largely static content, and little need for things like user- or region-specific content, is not likely to need something like a decoupled frontend. My advice: Let your requirements always inform your solution. Technology is great at solving problems, but don’t let it create them by misapplying it to your project. If you want to talk about whether decoupled Drupal might be right for you, please contact us.

Aug 09 2017
Aug 09

Last week, FFW was proud to attend and sponsor Drupal GovCon, a Drupal Camp dedicated to serving Drupal users in the government sector and hosted in the greater Washington, DC area. The event consisted of three days of great conversations, sessions, and sprints in the FFW Sponsored Sprint Lounge. We’d also like to congratulate the GovCon organizers on this year’s amazing event, which had more attendees and excitement than ever before.

A chance to reconnect

One of the things we noticed at GovCon was the amazing enthusiasm about the Drupal project, and especially Drupal 8. We got to be part of a lot of great conversations about Drupal 8, and appreciated the chance to reconnect with colleagues who are interested in Drupal and its capabilities. One of our teammates, David Hernandez, had an especially great session about Docksal and VMs, and had a lot of great conversations later about the subject matter.

For us, the chance to meet up with our friends and colleagues is the most important part of attending camps. Being able to take the time to have in-depth conversations with other people and organizations who are using Drupal in new and challenging ways is incredibly valuable to us, and is a great way of understanding the problems and challenges that others in our industry are facing on a day-to-day basis.

Open source and government sites

In our work with governments and other big organizations with strict governance rules, we’ve found that open source software is an ideal choice. In addition to being far more secure than closed-source alternatives, software like Drupal simplifies the process of managing permissions and creating content that can be read by anyone, anywhere, on any device.

Additionally, the flexibility of open-source solutions makes it easier to integrate digital platforms with a variety of systems so that simple transactions can be automated. For example, see how several Danish municipalities built solutions that could better serve their constituents with help from FFW.

Ultimately, we know that open source is a great solution for governments, and we had a wonderful time connecting with other like-minded people at GovCon last week. We were glad for the chance to sponsor such a great event, and look forward to connecting to more Drupalers in the government sector in the future.


Jul 14 2017
Jul 14

I teach Drupal. A lot. Often when I talk about Drupal I talk about how some people never leave their comfort zone to learn new things. Sometimes I make wise cracks about Flash or ColdFusion. Everyone gets the joke. Soon I'll be joking about standalone shopping carts. I think most people will get that joke too.

It's not that many shopping cart services aren't good. In fact, many are excellent. eCommerce is one of the more mature areas of the internet - after all - selling things is what catapulted the web into prominence and it all happened in the shopping cart. But eCommerce is much more challenging now and to be competitive in today's market businesses need much more than a tool that takes their client's money.

Businesses need to think in terms of Digital Experience Platforms or DXP's.

Questions and Answers

Why is eCommerce so much more complicated?

I once had the soon to be president of Black and Decker stress to me one of the most important questions in business: "What is our product and how do we bring it to market?" he said.

While those are still arguably the most important questions, we understand there are more that need to be asked and answered. Consider the following list.

How can we bring…

  • the right product or service…
  • to the right customers…
  • at the right time…
  • at the right place…
  • in the right condition…
  • in the right quantity…
  • at the right price?

To be competitive in today's retail environment you've got to be able to answer these questions for both online and walk-in customers.

Now answer these:

  • Does your shopping cart help you answer these questions?
  • Does your website help you answer these questions?
  • Do any of your sales channels help you answer these questions?

If you answered yes to any of them, congrats. Now ask:

  • How much are you paying for answers?
  • How much are you failing to earn because you don't have good answers?

Finally ask yourself this set of questions:

  • Do my tools help me flatten my business process or streamline my organization: this should include everything from your supply chain to your sales operations.
  • Do your tools just help you keep your head above water?
  • How much overhead do they add to your business process?

It's the Content, and the Experience

The good news is the answers to many of the market questions are out there for anyone who is able to generate high value content, collect data and turn it into useful information. While that is a huge complex equation it can be answered by the right tools and right decisions. The answers to the questions driving today's markets are in the content and the consumption of that content. The more, better, easily consumed, engaging, provocative content you make and manage the better your answers to your most critical market questions.

I think this simple smart observation about the importance of content published in Forbes by Melissa Pitts way back in 2012 still rings true.

With so much of our lives spent online, it's more important than ever to remember the wisdom expressed in Cluetrain. In case you've forgotten or never read it, it is is still some of the best, most common sense marketing truth out there today.

"Markets are conversations," the now famous line from the 1999 manifesto reads.

Newsflash: shopping carts don't manage content and they don't spark communities or conversations. Digital Experience Platforms start conversations. Think about how Facebook has evolved into an ecommerce powerhouse. Think about all the conversations going on within Amazon - 'Hello Alexa!'

Ask yourself one final question: Does my shopping cart spark conversations?

I have no clue why so many eRetailers still rely so heavily on such limited tools for supporting their eCommerce. I do know they risk being the butt of jokes soon enough.

Repeat after me: 'A Shopping Cart is Not an eCommerce Solution and an eCommerce Solution is not a Digital Experience Platform.'

If you and your organization understand these critical concepts then you are on the right track.

The Only Smart eCommerce Solution is a Digital Experience Solution

Implementing a full fledged DXP solution will help you answer these market questions and much more. Most eCommerce 'solutions' are just shopping carts with a few bells and whistles that fall far short of the DXP mark especially when they can cost you upwards of $15K per year just to access. Shopping cart solutions just don't deliver.

At FFW we work with Drupal extensively. We started working with it because it was a great CMS. With the release of Drupal 8 it's an even better application platform and we continue to work with Drupal and invest in its future because it can be used to build innovative, integrated solutions that drive adoption across organizations and affinities. Drupal helps our clients gather tremendous amounts of data and then turn it into useful information. Drupal helps us deliver content and then harvest information about the visitors that consume that content. That helps us make the right match between consumers, products and services. That is the essence of a great Digital Experience Platform. And that is what helps our clients start to answer the questions that begin with, 'How can we bring the right product or service to market.'

You don't have to take our word for it. Read what the analysts are saying.

In future installments of this blog I'll discuss how Drupal as a Digital Experience Platform can help you engage communities in conversations about their needs and interests and how your message about your product or service can be conveyed authentically. I'll also talk about how it supports critical established trends like omni channel marketing and commerce everywhere. We'll look at how you can use Drupal to flatten your business process and bring your sales team closer to customers.

For more on topics like this and other digital solutions take a look at FFW's special training programs that will give your organization the competitive edge it needs to compete.

Jun 29 2017
Jun 29

For anyone who's ever looked up a definition of a Drupal term and been left wondering what it all means, here are some practical real world explanations you can use to navigate the Drupalverse. Watch this space and use comments to send us your feedback and requests.

Basic page

One of two default content types that ships preconfigured in Drupal core since Drupal 7. As a content type, Basic Page is made up of Title and Body fields.

All content types are part of Drupal’s core fields system and can be customized with different fields. The output of a Basic Page is configured to appear either as a teaser or a full version, sometimes referred to as ‘default' or as a node.  Unlike the Article content type, content created with the Basic Page content type is not by default configured to appear on the home page. Basic pages are often used on simple websites or for static displays of content such as an About Us page that is linked to from the main menu.

It’s helpful to understand that though its content type name is basic page, it is in point of fact it is neither basic nor a page. As a content type it uses fields and can be extensively customized and is no less suited to advanced configuration than any other content type. Nor is it as configured by default in Drupal a page strictly speaking. Content type forms are used to create content nodes, or entities, that are typically used as the main element in an assembly of other items, such as menus, images, lists, and blurbs that are arranged in blocks around the main content.


Drupal’s basic system code and feature set is bundled together in different major versions referred to as Drupal Core that can be downloaded from the Drupal.org website and installed through various methods.

Not all features are active in Drupal core and must be turned on if desired. The key concept behind core is that to take full advantage of code updates no one should ever, ever ‘hack’ core for use in a production web site. While there are some exceptions, a hacked core is usually a sign of inexperience working with Drupal or negligence.

Major versions of Drupal core have been identified as whole numbers since Drupal 5. Released on November 19, 2015, Drupal 8’s core was completely refactored around the Symfony2 PHP framework, representing a major shift in how Drupal websites and applications would be architected and constructed as well as how the Drupal platform could be used. Drupal 7 is still fully supported and used to power thousands of web properties. 


The term ‘multi-site’ is sometimes thrown around casually as a reference to more than one Drupal powered website.

The strict definition of multi-site refers to an installation of Drupal that runs more than one website off a single code base. However there are many different ways to configure a multi-site installation. Sites can share and run off the exact same code, or be extended or customized with other code per site. It’s possible to have several sites run off exactly the same code while other sites each run off a combination of shared code and code that is specific for each site.

Consider any multi-site effort very carefully. The decision to go multi-site should include considerations around hosting, IT capacity, and development workflows. 

May 26 2017
May 26

Last week we released our latest white paper, 4 Reasons to Fast Track Your Move to Drupal 8. In it we talk about Drupal 8’s APIs, the inevitability of digital transformation, the freedom to design anytime, its strong and stable codebase and just how easy it has become to migrate from earlier versions of Drupal and other platforms.

Today we focus on Drupal 8’s powerful APIs

100 Million Reasons to Fast Track Your Move to Drupal 8

We are in the midst of a data revolution. Every website, marketplace, phone and sensor on a machine and every wearable on your person is collecting data every minute of every day. Last year Google used 100 million gigabytes of disk space just to index an estimated 30 trillion surface web pages. The trend toward code as a commodity and data becoming the real currency of the digital economy started years ago. Today’s winners are organizations that can master the ability to effectively access, parse, target and distribute data. Doing so is both the great challenge and promise of the digital economy.

The most significant factor in the distribution and commercialization of data has been the reimagining of the API (Application Programming Interface) and their rapid proliferation. Modern APIs enable organizations to collect, compute and monetize data, pivot and build cost effective customer centered product and service iterations.

"2017 is the year APIs help complete the transformation of organizations into truly digital enterprises."    Tom Smith, Dec. 20, 2016, Integration Zone

As Smith writes in API Trends for 2017, APIs are no longer considered to be separate products and instead will form the core of a platform upon which new development will occur. 

Enter Drupal 8

With 30 pre-built APIs shipping with Drupal 8, they do indeed form the core of a powerful application building platform that can help organizations free their data from the limitations of the browser.

The fastest way to help you understand the advantages of Drupal 8’s API infrastructure is to begin with its core RESTful Web Services API.  REST in core includes all your favorite CRUD operations to create, read, update and delete content entities including the ability to read configuration entities. For more information read this detailed overview of web service solutions in Drupal 8 by Acquia CTO and Drupal founder Dries Buytaert. 

Like what you saw in core REST? Next take a serious look at the core Migrate API and its supporting core modules. You’ll find that upgrading from Drupal 6, Drupal 7 and even other platforms will help you design a clear and straight forward path to getting your data into Drupal 8 where you can begin to take advantage of it’s full range of API goodness. Visit this overview on upgrading from Drupal 6 or 7 to Drupal 8 for a step by step peak at the process. 

Links to all of Drupal 8’s core modules are provided below. Let us know what you think and download our new Drupal 8 Migration white paper for more information. 

May 10 2017
May 10

It’s hard to believe that another DrupalCon has come and gone — it feels like just yesterday when we were mourning the passing of Drupal 6 in New Orleans and unveiling our new branding in Los Angeles. DrupalCon Baltimore was a success for us, and we wanted to share some of our memories from the event.

Our Week at DrupalCon

It was an honor to introduce Dries on Tuesday morning at DrupalCon. We were grateful that we had the opportunity to discuss two projects that are near and dear to our hearts: The Open Y Drupal distribution, and Drupal Global Training Days.

We were also thrilled to have so many visitors drop by our booth. It was great seeing so many old friends and making new ones, and we’d like to say congratulations again to our raffle winners: Mark (pictured below) & Dennis, who won Apple Watches, and Patrick, who won an Amazon Echo.

FFW Session Recordings

We had a great time sharing our knowledge in trainings, sessions, and BOFs. If you didn’t catch the FFW crew in action, you can watch recordings of our sessions here:

  1. Anti-Crash Course: How to Avoid Drupal’s Most Common Pitfalls
  2. Using Drupal to Power the YMCA
  3. Scaling and Sharing: Building Custom Drupal Distributions for Federated Organizations
  4. Less Is More: What Modules, Features or API's Should We Cut From Core?
  5. Docksal: Better than VMs
Mark Bennet claiming his Apple Watch at the boothAdam Leighton at the FFW booth

Farewell, Baltimore; Hello, Vienna!

As always, we stayed for the community. We were heartened to see so many people working together to grow the project, navigate new territory, and have thoughtful conversations about the future of the Drupal software and the community’s governance. We’re looking forward to the continued discussions about the community’s structure and future; if you’d like to participate, you can find future meeting information here.

It was a pleasure to sponsor such a great event. We’re looking forward to seeing who we meet and what great conversations we have across the pond at DrupalCon Vienna this September.

DrupalCon group shot credit to Michael Cannon on Flickr.

Apr 21 2017
Apr 21

While working on a presentation for DrupalCon Baltimore, I was brainstorming various tactics and proposals for removing components and modules from Drupal core. The act of deleting something from core can, at first glance, seem simple, but it brings up a more interesting discussion.

First, some background

Earlier this year Dries Buytaert announced a change to the future backwards compatibility support for Drupal core. You can read more about the policy change in his post. To summarize, Drupal core will continue adding enhancements, marking replaced APIs as deprecated along the way. The next major version update of Drupal will simply be the removal of all the deprecated components.

Less than a month before this he also wrote about the opportunities prepackaged distributions present for Drupal 8. The new world of Composer-based dependency management is great for developers, but will become a new barrier to entry for beginners. The predefined packaging of distributions may be an important tool for combating this problem.

A clash of concerns

The real historical problem that has made the decision to add or remove components in Drupal core difficult is the dichotomy between Drupal as a framework and Drupal as a product. Framework advocates want a small, agile core focused on robust APIs that can advance at a faster pace. We’ve traditionally called this “small core.” Product advocates are focused on Drupal being a complete product for website building; with sensible defaults, out-of-the-box content modeling tools, and a plethora of features.

Let them eat cake, and have it, too

Is there a way to focus on the framework, but still provide the product-level utility that beginners, site builders, evaluators, and the like all need? Maybe.

Let’s give the small core crowd what they want and reduce Drupal core down to its core components and APIs. All the things subsystems need for Drupal to function, and only modules that the vast majority of sites will use and are fairly integrated into core; node, block, menu, field, views, etc. Everything removed will be put back into the contrib space, but maintained by the core commit team and component maintainers with the same high standards as core.

We then create an official, standard distribution that is prepackaged by drupal.org and pulls in all those additional components from the contrib space; themes, toolbar, forum, etc. This distribution would be maintained along with small core and be available on Drupal’s download page. (With small core available for download on its own.) The end result should be transparent to anyone downloading Drupal. The initial distribution would look exactly like Drupal 8 does right now.

Let small core focus on developer needs, and free up the distribution to focus on site builder and evaluator needs.

Here are some potential benefits I’ve been thinking about, most of which fall in line with the current direction of Drupal core:

  • Focus core on APIs
  • Allow developers that want to contribute to focus on those APIs, not product decisions.
  • Reduce some of the maintenance burden on core itself, or at least better segment it.
  • Moving most modules back to contrib would give component maintainers commit access to their modules and allow them to iterate and experiment.
  • Creating an official distribution separate from small core would let product managers, designers, and UX specialists focus entirely on Drupal the product; what modules and themes are included, default features, user testing, etc. (Something like the default content initiative would go right into the distribution, and never clutter core.)
  • Experimental modules/themes can be created in contrib first, and then when stable, added to the distribution via its composer file.
  • Small core would provide a small, vanilla starting point increasing the diversity and experimentation we might see with distributions; effectively removing all the unneeded components so builders can focus on what they want to add, not what they need to remove. The end result could be a wide range of Drupal “flavors” that look very different, but have the same core.

If you’d like to talk about this and the general topic of removing components from Drupal core, come to the Core Conversation session Peter Wolanin and I are having at DrupalCon Baltimore - Less is More - What Modules, Features, or APIs Should We Cut From Core?

Jan 10 2017
Jan 10

For anyone who's ever looked up a definition of a Drupal term and been left wondering what it all means, here are some practical real world explanations you can use to navigate the Drupalverse. Watch this space and use comments to send us your feedback and requests.


A camp is a gathering of Drupal experts and other interested humans set up to share best practices, emerging trends and other information. Camps are usually free or low cost and may be organized over one or several days. They are an excellent way to become familiar with the Drupal community and Drupal practices. 

Camps can be found all over the globe. Some are big, some are small, but regardless of size, beginners are always welcome. Many camps offer high-quality, paid trainings taught by leading Drupalists who are experienced in specific areas such as module development, theming or project management. 

Drupal camps are generally built around a series sessions, which are 45 to 90 minute presentations by Drupalists that cover specific topics, themes, or ideas. Most camps organize sessions to cover a variety of topics and experience level so that all attendees get to enjoy great content. Many camps will also organize contribution sprints on a subsequent day, where attendees write code for the Drupal project. 

Sprints are a great way to get more people contributing back to the Drupal project and also a great way to enable regular committers to work more collaboratively and effectively together around a specific set of issues. Visit Drupal.org for info on upcoming events and also Drupical.com a very handy aggregator of Drupal meet ups, camps and conferences.  

(FFW is very active in the camps scenes in the cities where we have offices. If you'd like to check out a Drupal Camp for yourself and want to know if FFW will be there, check out our events page, which lists out which upcoming camps we plan to attend.)

CLI: Command Line Interface

CLI stands for Command Line Interface, which can mean either the Drupal shell program (Drush) or the Symfony-based Drupal Console program. Configuration that occurs via a Drupal graphical user interface can often be performed much more effectively at the command line. 

Drush (rhymes with “crush”) is a mainstay of Drupal configuration and is well known by any developer who’s worth their salt. Drush refers to ‘Drupal Shell’, and is a shell-based software that allows users to administer Drupal sites of all versions from the command line. The other CLI, Drupal Console, was developed specifically for Drupal 8 and is used as a shell program to learn Drupal 8 development, configure Drupal sites, create custom module and theme scaffolding and debug custom code. 

A handy tip from Ray: If someone tries to get you in a conversation about which CLI is better or why we should only have one, it’s best to shrug your shoulders and walk away quietly.  

CMI: Configuration Management Initiative

The Configuration Management Initiative began as a Drupal 8 configuration effort. The goal of CMI was to strengthen Drupal’s configuration workflows. It was also built to mitigate potential roadblocks and collisions in production websites with user generated content that were also undergoing active development.

The main challenge for the CMI was to create a method of saving, versioning, reverting and making portable the changes made to a site’s configuration settings. The initiative lead to fundamental changes in how Drupal classifies and handles configuration data, and laid the foundation for significantly improved development workflows in Drupal 8. CMI is just another reason why you should be developing your next project using Drupal 8. 

To learn more about the unique nature of Drupal, download our Ebook: 10 Drupal Project Pitfalls to Avoid. This eBook has compiled a list of lessons we’ve learned in 15+ years of delivering digital solutions to some of the most recognizable brands in the world. 

Download the Ebook

Dec 27 2016
Dec 27

We had a lot of great accomplishments at FFW in 2016. It’s been a year where we’ve helped our clients shatter records and drive amazing business results. A great example of this is NBC Sports Digital, with whom we’ve collaborated with on a number of projects: we built new Drupal websites for NBCSports.com and its regional RSN networks, and we also constructed NBCOlympics.com, part of the most successful media event in history.

Building a Hub for America’s Sports Fans - NBCSports.com and Regional Sites

NBC Sports Digital asked us to implement a redesign of their digital sports hubs (NBCSports.com and Sports Regional Networks websites) before the start of the NFL season. They asked us specifically to focus on videos and advertising, to increase user and sponsor satisfaction.

Our team built each page according to NBC’s new designs, migrated the network’s data onto a scalable Drupal platform, and developed the new site to have custom layouts, themes, and functionality. We also implemented responsive design, ensuring the site looks great on any device. We were able to launch NBC Sports Digital’s new site before the NFL season kickoff with full video functionality and improved advertising, and the response has been great.

In addition to rebuilding NBCSports.com, we also rebuilt the websites for NBC Sports Group’s Regional Networks. NBC wanted its regional sites to have a consistent look and feel, so we set up a multisite project with all the same backend code. Our team implemented several feed customizations for each site so each different region would have unique content. The result is an ecosystem of regional sites with custom content and easy-to-maintain shared codebase—another win for NBC!

Visit the site:

NBCOlympics.com: A Gold Medal in Site Performance

In order to provide a best-in-class digital experience for NBC Olympics’ coverage of the 2016 Rio Games, NBCOlympics.com required a massive platform. When the opportunity arose for FFW to build the web platform to deliver performance, security, and stability at such a massive scale, we were excited to step up to the challenge. During the Rio Olympics, NBCOlympics.com hosted 3.3 billion total streaming minutes, 2.71 billion live streaming minutes, and was visited by 100 million unique users.

A thorough discovery phase allowed us to plan for the implementation of the extremely complex, and massive, project. After a year and a half of work, we launched the completed site in April of 2016. We also built in a state-of-the-art advertising platform, which helped NBC Sports to manage their sponsors’ content. The new platform served up content to a record number of users, who were able to view localized listings of broadcasts and watch live streams of the events from any device. 

We couldn’t be more proud of our teams who worked on all three sites, and we’d like to say thanks to NBC for letting us be part of such a historic event.

NBC Olympics has set the new benchmark for how to build and operate a Drupal-based CMS in a multi-platform world.Eric Black, CTO, NBC Sports Digital

Visit the site:

Nov 23 2016
Nov 23

At FFW, 90% of our staff spends all day, every day, working with code. We’re site builders and developers, and we’ve created a number of tools to help make our jobs easier. Today, we’re excited to share our Docksal development environment with you in the hopes that it will make your team’s life easier, too.

Docksal is an open-source tool created by FFW for defining and managing development environments. It brings together common development tools, minimizes time spent on configuration, and ensures the consistency of local development environments throughout a team’s continuous integration workflow.

Docksal automatically configures each project's environment to ensure team members are using the same tools, and versions, regardless of the individual requirements of each project. Most importantly, it makes the entire process easy. Docksal offers fully containerized environments with Docker, provides cross-platform support (MacOS, Windows, and Linux,) and has built-in tools that include:

  • drush
  • Drupal Console
  • WP-CLI
  • composer
  • PHP Code Sniffer
  • Apache Solr
  • Varnish
  • Memcache
  • Built-in testing support with Behat and Selenium.

Docksal will even automatically configure virtual hosts for you, so no more editing host files and server configurations.

How can Docksal help your organization?

Docksal has a threefold value proposition. It improves time-to-market and quality on development projects through:

  1. Bringing together common development tools on a unified platform
  2. Minimizing time spent configuring development environments
  3. Assuring quality by ensuring that local environments are consistent across a team’s continuous integration and development workflow.

Docksal makes it easy to bring new team members onto projects in no time flat: the software allows them to get set up and running easily and quickly. We built Docksal to streamline the process of adding team members to our projects: previously, they’d have to go find the code for the project, get it set up on their laptop, get it to work with everything on their laptop, perform a database dump, get the site running. We wanted to simplify this process.

Docksal reduces the work of several hours to several minutes. Our developers don’t have to waste time figuring out why the code isn’t working with the configurations they have on their computers, and our teammates who aren’t code-oriented don’t spend frustrating hours trying to simply access the project. With Docksal, anyone can get a specific Drupal environment set up and running on their machine in two minutes -- and everyone is running the same environment, which acts as an important check on quality and consistency.

Our suite of development tools

Docksal’s features may sound familiar to those of you who previously used our Drude tool. That’s because Docksal is Drude renamed and expanded. Docksal doesn’t just work with Drupal: it works with WordPress, stand-alone HTML files, or any other PHP project— because even though we all love Drupal, sometimes we have to work with other technologies, too.

In addition to Docksal, we’ve also created another development tool called CIBox. CIBox (Continuous Integration toolbox) is a development workflow tool that simplifies the process of checking changes to each project’s codebase. CIBox uses continuous integration -- the process of immediately testing new code when it’s contributed to a project -- to support a truly Agile development process.

CIBox allows developers to have an unlimited number of testing environments, deployment plans, and additional automations. It supports a continuous integration server dedicated to running site builds and tests, as well as a toolbox of scripts for Code Driven Development with Drupal, Wordpress, Symfony, Sylex support. It offers deployment plans and skeletons, and an improved QA workflow from most CI tools. Stay tuned for an upcoming blogpost that speaks to CI Box in more detail.

Try the software for yourself

Docksal and CIBox are both great tools for building projects and managing development environments. Both have saved us a lot of time and ensured that we have streamlined, quality-focused processes.. To get Docksal for yourself, visit docksal.io for downloads and more information, or to try CIBox, check here.  We hope that you give them a try — we think they’ll make your life better, too.

Oct 07 2016
Oct 07

For anyone who's ever looked up a definition of a Drupal term and been left wondering what it all means, here are some practical real world explanations you can use to navigate the Drupalverse. Watch this space and use comments to send us your feedback and requests.

Article: While newspapers and magazines have articles, the term 'Article' in Drupal denotes something more specific. An Article is one of two content types that have come preconfigured with Drupal since Drupal 7. As a content type, an Article is made up of Title, Body, Image, and Tag fields.

All content types are part of Drupal’s core fields system and can be customized with different fields. The output of an Article is usually configured to appear either as a teaser or a full version, which is sometimes referred to as the default or as a node. Unless your home page has been customized, article teasers will appear on your home page as a river of news with older items sinking to the bottom. This makes it easy to begin building a site with time sensitive content such as a blog. Most home pages are even customized so that selecting the ‘promote to front page’ toggle has no visible effect. If this happens to you, don't worry! Your site is not broken. It's just Articles at work.

Base Theme and Themes: A theme in Drupal is a collection of CSS, template files, and javascript that helps determine the look and feel of a Drupal website or application.

A theme typically defines different regions in code which can then be used to place various elements via configuration in a user interface. Base Themes are a common way of standardizing and optimizing Drupal front end development. They enable developers to focus on CSS styling and javascript without having to manipulate Drupal internals. A variety of different methods can be used to essentially copy and customize the styling of a base theme.

Among the advantages of using a base theme are less risk from custom coding and updates often provided by base theme maintainers that enable greater functionality or enhanced security. Some base themes make it easier to build a theme based on a popular published library, such as Twitter Bootstrap. Organizations often develop their own themes and use them internally as a base theme for different projects.

As a note: base themes typically only work with a given Drupal major version. For example, Drupal 7 theme will not work with a Drupal 6 or 8 theme. Major changes have taken place in theme development between Drupal 7 and the current version Drupal 8. But don't worry! Drupal 8 includes a new templating engine called Twig. Twig is a Symfony framework component that eliminates the necessity to write preprocess functions and other code. Generally, that's often not part of a front-end developers skill set, so Twig makes it easier than ever for front-end developers to create responsive and other advanced designs.

Content: The word "Content" can mean different things to different people, especially when Drupal is involved. When speaking to a Drupalist who’s been around for many versions, it may mean only something created by Drupal’s core node module or anything that has been created via a content type form by clicking on an ‘add content’ link. Others will use it to represent anything presented on a webpage.

Depending on who you are talking to and what their role is, this can lead to confusing discussions or debates about whether something is Content or something else. The best way to deal with this on a project is to understand the other definitions and always ask the speaker to please define what Content means to them. 

For example, Content can be structured or unstructured. (The preferred best practice in Drupal is always structured content validated at the field level.) Comments, images, and file attachments may also be considered Content. Images and file attachments are often referred to as assets because they are stored in a file system. In Drupal 8 you are more likely to hear this kind of Content referred to as an Entity, which thankfully simplifies the conversation.

Aug 24 2016
Aug 24

For anyone who's ever looked up a definition of a Drupal term and been left wondering what it all means, here are some practical real world explanations you can use to navigate the Drupalverse. Watch this space and use comments to send us your feedback and requests.

The Discipline of Dev Ops

Dev Ops, or Development Operations, is the intersection between IT managed hosting support and development. While it is a specialization in many organizations, senior developers, tech leads, and architects should be conversant in the various systems and tools to be used by your IT team or provider.

One of the primary goals of Dev Ops is to create standardized operating system iterations that are consistently reliable and easily replicable. Your unique infrastructure or hosting service plays a big role in these systems, which is why they tend to be customized to each project.

Standardized Dev Ops systems are used to create local and remote development environments, as well as staging and production environments, which all function in the same way. Having good Dev Ops systems in place means that your organization can support continuous development practices like version control and automated testing.

For any site that’s even moderately complex, having Dev Ops standards is huge. You don’t have to try to become a Dev Ops genius yourself: instead, you can find an organization like FFW to provide the level of Dev Ops help and support that is appropriate for the size and scope of your project.

Defining a Display

Displays, unlike Dev Ops, are a little simpler. A Display in Drupal typically refers to how queried data is organized and shown to visitors. It is usually used in connection with a native database query referred to as a View.

One View (or database query) can have several Displays sorted in different ways. For instance, a set of queried data can be output in the following ways:

  • a sortable table
  • a grid
  • as consecutive field sets
  • in a rotating banner
  • as a calendar or list of coming events
  • as points on a map

… and these are only just a few examples of the many different kinds of Displays.

The Details Around Distributions

A Distribution is a pre-developed assembly of database data, code, and files. Distributions commonly include saved content, configuration settings, Drupal core, contributed and custom modules, libraries, and a custom theme. It’s basically a pre-built Drupal site.

Most people first become acquainted with Distributions as different iterations of Drupal that are built for specific use cases or verticals, such as e-commerce or publishing. Many distributions are robust, production-ready applications that will save you tremendous work. They let you take advantage of the distribution sponsor’s subject matter expertise.

There are other kinds of distributions, such as ones developed mainly for marketing purposes to showcase what Drupal can do and how Drupal can be used. Both of these types of distributions have value, but it is important to differentiate between the two.

Distributions can be vetted in much the same way that a Drupal module or theme can be vetted. When evaluating a Distribution, I always like to ask the following questions:

  • Who are the contributors?
  • What is their experience?
  • Is the project actively maintained and are new features or versions planned?

The other primary consideration when vetting a Distribution is how much complexity and effort is required to ‘unravel’ a distribution. Many organizations have found that the more fully realized distributions are difficult to customize around their specific workflows and therefore are more expensive to change than starting fresh with a more basic version of Drupal.

If you want to know more about Distributions, I recommend looking at Drupal’s distribution project pages and this documentation page.

Aug 09 2016
Aug 09

It is amazing how often the content equation is underestimated or misunderstood whether building new properties or renewing existing sites.

The essence of any web project is the content or message to be conveyed. Understandably organizations will engage terrific creative agencies that will put tremendous effort into strategy and design. Unfortunately this often has the unintended effect of de-emphasizing existing content that may, or may not, need to be migrated to your new project. A thorough content audit early on in your planning process will help streamline your project and your budget.

Rarely is content brought over to a project wholesale without some important changes. This can be obvious like making PDF content more search engine friendly or less obvious like adding or changing metadata and reforming its underlying data structure. An audit will help determine if content migration should be included in your web development scope or handled as a separate component.

But unlike planning for strategy and design, resources are often scarce when it comes to content planning and conducting a content audit. It is likely the content planning process will be reduced to task level milestones and allocated to support staff or subject matter experts with little accommodation for the importance, difficulty or breadth of the requirements. This can lead to unforeseen and unwanted surprises during the development and user acceptance cycles of your project. 

Here are a few quick resources to get you started understanding the content planning process is Drupal.

A topic central strategy from a blog post that has only gotten more important: Understanding Content Planning: Why Taxonomy is Your New Best Friend

A great book from an accomplished Drupalist that will answer a lot of basic questions around content planning: The Drupal User's Guide by Emma Jane Hogbin Westby.

And a new series of articles about distributed content management by our very own Hank VanZile Director of Pre Sales Consulting starting with 'What is Distributed Content Management'

Aug 09 2016
Aug 09

Upheavals in the energy sector in recent years are driving a new Texas-sized need for efficiencies in all facets of business operations and are leading companies to begin mining new areas for streamlining and savings.

Houston, we have a solution.

The good news is open source technologies are opening up areas for exploration previously overlooked by many in the energy sector. In this multi-part series we’ll begin to look at how energy companies use the web and how open source internet technologies can drastically reduce acquisition costs, enable rapid prototyping, and create a potential for windfall profits.

Here’s a preview of our upcoming series on Drupal for the Energy Sector. Use the form below to sign up for our newsletter to get notified when we post new articles or sign up for our free training session on September 16 in Houston.

Acquisition Cost

Ever test drive a Lamborghini? Me neither. How about a proprietary web experience platform by one of the venders in Gartner’s Quadrants? Not happening. You wouldn’t buy a car you couldn’t test drive. Why consider purchasing a software platform you couldn’t pilot? Unless it’s open source you’re going to have to pay dearly for the privilege of any kind of test drive. Among the platforms listed in Gartner’s magic platform, Drupal is the only system you can freely pilot around your business needs.

Rapid Prototyping

Just because its free doesn’t mean you know what to do with it. Many open source systems have a huge transparent install base. You can install a simple plugin in your web browser that will tell you what Content Management System, technology or platform is being used. Drupal takes it even further with free custom developed distributions for different functional needs like ERP, localization and translation, publishing, ecommerce, event organizing, and networking. Agencies can build in various front end technologies and connect them to a Drupal backend with minimal customization.

Windfall Profits

How large is your IT department? Chances are the answer is something like, ‘Not big enough to do the job we have ahead of us.’ The nature of an open source project means you can tap more personnel than you could ever achieve a return on with a proprietary system. Drupal alone has over 3,000 developers that contributed to their latest version, Drupal 8. All of them are writing code that is highly secure and available for you to try and use for free.

Stay tuned for more on each of these and other topics in the coming days.

Jul 29 2016
Jul 29

We got a great response to our Real-Time Personalization Strategies for Government Websites session at Drupal GovCon last week. Most of the questions we received were from representatives of agencies just beginning to explore their options who wanted to know how to get started and to begin to understand how other agencies have started using personalization.

So together with other staff here at FFW we’ve begun to put together a library of personalization use cases. If you work with a government agency or quasi-public authority send us your examples so we can share our findings with your colleagues.

In the meantime we’re making our presentation slides available as a guide to personalization basics for government agencies. Once again I’d like to acknowledge my colleague Dave Sawyer for his excellent work on this topic. Feel free to contact me directly with questions at [email protected].

For those of you just tuning in, web personalization allows content to be tailored to the interests of the visitor, resulting in increased engagement and better experiences. Personalized content is essential to an effective digital communications strategy, but planning and implementing a personalization solution can be complex and cost prohibitive. 

This guide introduces the basics of web personalization and presents several simple ways for government agencies to get started with web personalization using Drupal. It includes:

    •    An overview of common personalization use cases
    •    A checklist of prerequisites for implementing personalization on a Drupal project
    •    How personalization for authenticated users differs from that of anonymous visitors
    •    Special privacy considerations
    •    Why Drupal is the best CMS to execute a personalization strategy

Click on the personalization tag for more information on this topic. You can also download the FFW eBook, The Basics of Real-Time Personalization. It has all the content shared on the blog, and more.

Jul 21 2016
Jul 21

Extending in Twig is a method by which one template can inherit content from another template, while still being able to override parts of that content. This relationship is easy to imagine if you are familiar with Drupal’s default system of template inheritance.

A theme can have multiple page templates, many node templates, even more field templates, and a plethora of block and Views template. And it is common for those templates to largely be identical, save for a snippet of markup or some logic. The advantage in extending templates is reducing this duplication, thereby simplifying architecture and easing maintenance.

Let’s say, for example, you want to change the template for a specific block, adding a wrapper div around the main content area. This might be done by copying the standard block template and giving it a name specific to your block.

Classy’s block.html.twig template
  set classes = [
    'block-' ~ configuration.provider|clean_class,
    'block-' ~ plugin_id|clean_class,
<div{{ attributes.addClass(classes) }}>
  {{ title_prefix }}
  {% if label %}
    <h2{{ title_attributes }}>{{ label }}</h2>
  {% endif %}
  {{ title_suffix }}
  {% block content %}
    {{ content }}
  {% endblock %}

Copied to block--my-special-block.html.twig
  set classes = [
    'block-' ~ configuration.provider|clean_class,
    'block-' ~ plugin_id|clean_class,
<div{{ attributes.addClass(classes) }}>
  {{ title_prefix }}
  {% if label %}
    <h2{{ title_attributes }}>{{ label }}</h2>
  {% endif %}
  {{ title_suffix }}
  {% block content %}
    <div class=”content-wrapper”>{{ content }}</div>
  {% endblock %}

This accomplishes your goal. You have a template specific to this particular block, and a wrapper div just where you need it. Following the same method, and with a complex site, you can end up with lots of different block templates (or node templates, or field templates, or … you get the idea.)

But, now you have a different problem. The majority of the template is duplicated. All the CSS classes, the outer wrapper, the markup for the block title, etc. If any of that needs to be changed, like changing all block titles from H2s to H3s, you have to update every single one of those templates.

Even if this happens infrequently enough not to be considered time consuming, it is still prone to errors. You might make a mistake in one template, miss one that needs changing, or even change one that should not be changed.

This is where {% extends %} comes in

Extending templates allows you to reference the original template, and only override the parts that are unique to the child template.

In the block example, we can create a block--my-special-block.html.twig template with this content:

{% extends "block.html.twig" %}
{% block content %}
  <div class=”content-wrapper”>{{ parent() }}</div>
{% endblock %}

That’s it. That is the whole template. Twig uses the original block.html.twig template as the main template, and only uses what we override in the more specific block--my-special-block.html.twig template.

The parent() function simply returns all of the content within the {% block %} tags in the original template. This saves us from having to duplicate that content; keeping the template simple, and future proofing it. If any of that content changes in the original template, we don’t have to update the block--my-special-block.html.twig template.

In this example, the content in the original template is fairly simple, only printing the content variable, but imagine if there was a large amount of multiline html and Twig code wrapped in those block tags.

Twig blocks, not Drupal blocks!

This overriding is done by using Twig blocks. (Terminology is fun!) The Twig block is what you see identified by the {% block %} and {% endblock %} tags. The word "content" is the identifier for the block. You can have multiple blocks in a single template.

In the block--my-special-block.html.twig template file, we can do anything we want inside the block tags. Twig will replace the original templates “block” with the one in block--my-special-block.html.twig.

What else?

Well, you have access to pretty much everything in the main template, except the printed markup. So, for example, you can modify the variables it uses.

{% extends "block.html.twig" %}
{% set attributes = attributes.addClass(‘super-special’) %}

This template will add a CSS class called "super-special" to the attributes printed in the outer wrapper of the original block template. The alternative would be to copy the content of the entire block.html.twig template just to add this class to the ‘classes’ array at the top of the file.

You can also just set a variable that will be used by the original template.

{% extends "block.html.twig" %}
{% set foo = 'yellow' %}

Imagine a series of variant field or content type templates that set variables used by the original template for classes, determining structure, etc.

You can even add Twig logic.

{% extends "block.html.twig" %}
{% block content %}
  {% if foo %}
    <div class=”content-wrapper”>{{ parent() }}</div>
  {% else %}
    {{ parent() }}
  {% endif %}
{% endblock %}

Pretty much anything you still might want to do with Twig, inside or outside of the block tags, you can still do.

Things to note

Before you jump right in, and bang your head against a wall trying to figure out why something isn’t working, there a few things to know.

  • The {% extends %} line needs to be at the top of the file.
  • When overriding markup, you can only change what is within block tags in the original template. So add {% block %} tags around anything you might want to modify.
  • You cannot print additional things outside of the overriding block tags. You will have an extends line. You can set variables, add comments, add logic, and override blocks. You cannot put other pieces of markup in the template. Only markup that is inside a block.
  • If Drupal does not extend the correct template, based on what you expect from template inheritance, you may have to explicitly state the template you want.
    Example: {% extends "@classy/block/block.html.twig" %}

Additional Resources

Jul 18 2016
Jul 18

When we said we'd introduce you to the ABC's of Drupal we didn't just mean the easy stuff. Here are three C's that will help you understand the power behind Drupal 8.

Component: In Drupal 8 the word component is often used to identify one of the libraries managed by the Symfony project used by Drupal. Visit this link for a full list. https://ffwagency.com/blog/what-symfony-components-are-going-into-drupal-8 While Twig is often cited as a Symfony component, strictly speaking it is a PHP theming engine created by the same individuals who founded and maintain the Symfony project.

Composer: Composer is a dependency manager tool for PHP, Drupal’s core scripting language. If you are familiar with a package manager it is similar but not the same. Practically speaking Composer will help you download, install and manage specific code libraries and any additional code libraries they in turn may be dependent on for a given project. It’s important to understand that Composer is project centric - it defaults to managing code and dependencies within projects (like websites) rather than globally across projects. Composer’s use in the Drupal space is growing with the adoption of Drupal 8 and has begun to be used as an alternative to .make files which have been used to help manage Drupal installs and distributions.

Console: Console is a component of the Symfony project. Most often when a Drupal developer refers to using Console they are talking about using Drupal Console, a suite of tools run from a command line interface (CLI) to generate boilerplate code and interact with a Drupal 8 installation. In 2014 FFW hired Drupal Console’s lead project developer Jesus Olivas to develop the project and contribute the tool back to the Drupal community to strengthen Drupal 8 adoption. Drupal Console is used as a learning tool, module and theming scaffolding, debugger and configuration tool for Drupal 8. For more information on Drupal console visit https://ffwagency.com/blog/drupal-console-an-overview-of-new-drupal-cli

Jul 06 2016
Jul 06

For anyone who's ever looked up a definition of a Drupal term and been left wondering what it all means, here are some practical real world explanations you can use to navigate the Drupalverse. Watch this space and use comments to send us your requests.

Aliases: URLs in Drupal often have multiple addresses or aliases. This helps avoid complex machine generated addresses and makes your pages more search engine friendly. Through a variety of methods aliases can be generated automatically according to predefined patterns and then changed or updated in bulk. It is one of Drupal’s most powerful features and is used for everything from SEO to structuring a site and its navigation.

Block: A block is essentially a container that can hold content, lists of content, code, images or text strings and can be placed into a region on a page. Blocks can be created programmatically by a Drupal module or manually. Core Drupal can be extended with contributed modules that create other containers with different names that can be used by Drupal in a similar manner as blocks. This can become confusing to understand and manage especially when more than one method is used on a site. Blocks are the primary means for managing page layout in Drupal core. Blocks can be placed in a region and then configured to be visible only under specific conditions such as a user’s role or the type of content displayed in the main content region of a given page. Once common, the use of executable code in a block in order to bring about a desired behavior on a page can introduce security risks and management overhead. Justified exceptions should be managed closely.  Other methods such as development of a custom module are preferred. The ability to add additional fields to blocks in Drupal 8 makes placing marketing automation and web analytics code in blocks more practical.

Content Type: A content type is a collection of data fields grouped together in a logical set to facilitate content entry and display. Default behaviors, such as preview, publish, save as draft or revision, are set up for each content type. Drupal core is preconfigured with two content types, Article and Basic Page. Users with appropriate permissions can create their own custom types. Think of a content type as the structure of the form you create to save multiple posts. A website about food might have a content type ‘Recipe’ that would include individual fields to collect data about ingredients, quantities, cooking time, etc. The Recipe content type could be used to create hundreds of individual Recipe records.

Jul 06 2016
Jul 06

Discovery is the part where you make it your business to find out what you don’t know you need to know. Discovery is a process, not a workshop or a questionnaire. There’s a reason why it's called Discovery. You may think you know what you're going to find but often you don’t. Your goal is to uncover any unanticipated issues or complexity and ultimately use the process to generate consensus around priorities and a project plan.

There are three fundamental steps to any really good discovery process. If you don’t fully embrace these steps and execute them with rigor you stand a good chance of missing something critical that can stall or even completely undermine your project. Rushing through discovery will almost always guarantee delays and additional costs. Many organizations will contract for discovery separately. The good news is the steps are simple. They are: think, ask, listen; rinse and repeat. Think carefully about your overall goals, your specific objectives, your resources and budgets and then formulate a thorough list of questions. Do this singularly by yourself and then invite your team members to do it with you. Broaden it to all your stakeholders. Don’t just go to your stakeholders for answers. Go to them for the questions too. Having them be part of the discovery planning will help you achieve buy-in later in the project and will support accountability.

Once you’ve got your questions go out and get your answers. Look at things from all angles and perspectives. Then begin to iterate. Rinse and repeat means that you challenge the answers you’ve been given and you seek to validate them from other angles and different sources.

There is a science to a good discovery but good discovery is also an art. Experienced technologists know what to ask and what to listen for. They know how to reform questions to get more precise and accurate information that will help generate a project scope and specifications.

These steps are the same whether you do your own discovery in-house or with help from a consultant or services organization. Make sure you have at least one person on the discovery team who has senior-level experience with the technology you expect to build out your project with whether it is Drupal or something else. Certainly take advantage of any specific methodologies, templates and/or applications that align with your organization's policies and workflows.

Jun 06 2016
Jun 06

Why spend all your time at the beach when you can be learning even more about Drupal. Here are just a few of the camps our staff will be participating in this summer. We hope to see you there.


Drupal North in Montreal June 16 - 19 is a great regional event. FFW Manager of Learning and Contributions David Hernandez is presenting Managing CSS and JavaScript files in Drupal 8 with Libraries


Join us at GovCon in Bethesda July 20-22 where we’re sponsoring a full day training with Drupal Console author and FFW Drupal 8 Solutions Engineer Jesus Olivas on Building Custom Drupal 8 features and modules.  FFW Center of Excellence Director Ray Saltini and FFW Manager of Learning and Contributions David Hernandez will be there presenting on Personalization Strategies for Government Websites and Managing CSS and JavaScript files in Drupal 8 with Libraries

NYC Camp

NYC Camp is back at the United Nations this year July 8  - 11. There’s too much learning going on to list it all here. Make sure you catch FFW Center of Excellence Director Ray Saltini’s presentation Radical Digital Transformation or Die

Twin Cities Drupal Camp

FFW Drupal 8 Solutions Engineer and Drupal Console project lead Jesus Olivas is giving a full day training at Twin Cities June 16 - 19 on Drupal 8 Module Building and presenting Improving Your Drupal 8 Development Workflow. Make sure you catch him and FFW Developer Tess Flynn who’s presenting Ride the Whale! Docker for Drupalists.

May 20 2016
May 20

Welcome to the fifth post in my series on Distributed Content Management.  In previous posts I’ve defined the concept and provided some great examples of Distributed Content Management use cases in higher education, the pharmaceutical industry and media and entertainment companies.  In today’s post I’ll wrap up my industry-specific use cases by investigating ways in which product companies can use Distributed Content Management to improve their approach to everything from internationalization of their websites to managing community contributions. 

Setting The Scene

Product websites, whether for physical or virtual products, must ultimately influence their visitors.  For direct-to-consumer products, the goal may be a direct conversion - to get the visitor to buy/download the product.  Business-to-business products often have a more complex buyer’s journey, starting with something as seemingly minimal as driving the visitor to contact the company for more information.  Within the digital sphere, companies whose products are extensible platforms or systems may be seeking not only end-users, but developers or contributors to expand on the value of their initial offerings.  In all of these scenarios, the content presented to the user must be keenly adapted to the task at hand and, with products especially, must co-exist with information available from external sources.  Carefully planning their approach to Distributed Content Management - to the point of expanding what they may consider content - is a key tool for a product company’s success.

Use Case 1: A Multi-System Approach to Product Experience Management

Many web platforms strive to be all-in-one solutions for a product’s online presence; however, savvy product companies recognize that they can build a superior web experience by integrating multiple systems and relying on their core strengths.  A common example of this for product companies is around enterprise e-commerce systems (such as Demandware, Magento, or BigCommerce).  All of these solutions provide some level of content management and layout control; however, larger organizations that make heavy use of Distributed Content Management staples such as content re-use and custom publishing workflows may find the out-of-the-box tools duplicative or not sophisticated enough for their processes. Luckily, these systems allow organizations to interact with them programmatically through APIs and many provide pre-built connectors to popular content management systems such as Drupal and WordPress.  By integrating e-commerce tools with powerful content management systems, product companies can have the best of both worlds for both their internal processes and customers’ experience.

Use Case 2: Internationalization of Product Websites

Entry-level internationalization may be achieved with a single website and automated text translation; however, as a product company’s reach expands so may the sophistication of their internationalization strategy - and that can impact their needs for Distributed Content Management.  A simple example of this may be the transition between automatic translation technology (such as Google Translate, Lingotek Inside or Translate.com’s Website Translator) and content management provided by native-speaking editors.  Native-language content production, with its cultural nuances and idiomatic expressions, can provide a far superior experience to a website’s visitors but introduces a number of elements to a company’s Distributed Content Management strategy. For example, how will translated content fit within the company’s existing publishing workflow?  How will different language teams coordinate around new pages and content?  Taking this further, companies that produce physical products often have unique product lines in different geographical regions, a reality that necessitates a decentralized management strategy with close coordination around company-wide content.

Use Case 3: Curating Other People’s Content

More so than ever before, potential customers have easy access to a flood of content about a product before they decide whether or not to use it.  For a company’s digitally-inclined customers, Amazon’s Q&A and reviews, YouTube videos and even social media interactions with a company have become key elements guiding their decision making.  Attentive product companies actively manage these external sources: answering questions on Amazon, providing high-profile bloggers and YouTube producers with review copies of products, etc., but companies interested in further differentiating themselves are beginning to recognize that the content produced on these channels should be part of their Distributed Content Management strategy.  For example, Twitter actively promotes itself as a customer service platform, citing not only its “unparalleled reach,” but the fact that its conversations can be “embedded across other media.” However, many content strategists promote this same approach for curating testimonials.  Curating and embedding tweets in which a user speaks positively about a company’s product is a great example of managing distributed content to increase potential buyers’ social trust in a product.

Use Case 4: Content For Contributors and Existing Customers

Prospective users are not the only audience for product companies.  Physical product companies, especially those making electronics, often provide access to support resources, such as frequently asked questions and downloadable product manuals. Companies that produce digital products may offer software downloads and updates or, in the case of open products, API and developer documentation.  With each of these areas comes important decision around a company’s approach to Distributed Content Management.  Will product support require registration?  If so, what external system integrations are required to share the appropriate content with the user?  Will developers be able to contribute documentation?  If so, what kind of publishing workflows will be in place in for community-contributed content?  While each new audience brings additional considerations around Distributed Content Management, it also increases the opportunities to improve a product’s digital experience and extend its reach.

What’s Next?

Now that we have sufficiently explored industry-specific use cases for Distributed Content Management, I’ll move on to discussing prerequisites for proper planning.  Thoughts or questions?  Reach out in the comments below or tweet them to me at @HankVanZile.

May 17 2016
May 17

A week of beignets, beer and learning Drupal! FFW let the good times roll at DrupalCon 2016 New Orleans. In case you missed out, here are four must watch presentations to jazz up your week.

Is size just a number?: Reflecting on community growth, mentoring, and where we spend our efforts

[embedded content]

FFW’s Dave Hernandez discusses the challenges our Drupal community faces as one of the largest open source communities in the world. From capacity to growing pains, Dave tackles potential problems such as the limited number of high-end contributors and burnout.

He also discusses ways we might shift our focus, like supporting smaller, more productive events, one-on-one mentoring programs to help nurture existing contributors, and other ways to make sure we get the most out of our limited volunteer hours and efforts.

GE Energy Connections & FFW: Delivering Business Results Beyond Clicks and Conversions 

[embedded content]

GE Energy Connections Digital Strategy Leader, Holly Bounds and FFW’s Brent Bice share stories about how Drupal not only generates traffic, conversion and increased revenue, but provides significant intrinsic value to organizations through:

  • Reduced support and maintenance
  • Improved internal collaboration
  • Increased productivity
  • And significant cost savings.

​Looking for ways to reduce support costs by 22% and save millions of dollars per year? Watch this presentation!

Writing Command Line Tools for Drupal 8 Modules

[embedded content]

FFW’s Jesus Olivas, maintainer of Drupal Console, and other panelists discuss a new collaborative effort to unify the way that command line tools should be written for Drupal 8 modules. Jesus provides a great walk through of writing a scripting interface for your Drupal 8 modules code using an object-oriented API built on top of Symfony Console components.

Going beyond the implementation of the CLI tool, they also provide guidance on best practices for decoupled module development and the latest progress and future plans for collaborative efforts between the teams to use common implementations for some of the more complex common functions, such as site installation, configuration management, and bootstrapping, and what you can do to help make the future of command line tools easier for everyone to manage.

Web Personalization for Drupal: Your Roadmap to Get Started

[embedded content]

Dave Sawyer, FFW’s leading personalization expert, and Acquia’s John Money deliver a fantastic presentation for getting started with personalizing user experiences in Drupal. In this presentation, Dave covers use cases, prerequisites and much more as he explains why Drupal is the best CMS to execute a personalization strategy.

May 04 2016
May 04

As one of the largest Drupal agencies in the world FFW is no stranger to problems of scale. With large numbers of technical staff, clients, and concurrent projects, workflow management is vitally important to our work. And to deliver projects on time, while managing resources with agility, consistency and simplicity in the tools we choose plays a huge part.

When there are no standards for the tools a team uses (OS, editor, server, php version, etc.) dealing with the toolset adds unnecessary overhead that can eat away development time. You'll quickly find that setting up projects, on-boarding developers, troubleshooting, and even training all become more difficult as you deal with larger projects, larger teams, and more complex requirements.

To help solve these problems FFW created Drude.

What is Drude?

Drude (Drupal Development Environment) is a management tool for defining and managing development environments. It brings together common development tools, minimizes configuration, and ensures environment consistancy everywhere in your continuous integration worlflow. It automatically configures each project's environment to ensure team members are using the same tools, and versions, regardless of the individual requirements for each project. Most importantly, it makes the entire process easy.

With Drude you get fully containerized environments with Docker, cross-platform support (MacOS, Windows, and Linux,) built-in tools like drush, Drupal Console, composer, and PHP Code Sniffer, plug and play services like Apache Solr, Varnish, and Memcache, and even built-in testing support using Behat and Selenium. Drude will even automatically configure virtual hosts for you, so no more editing host files and server configurations.

With all of this you also get a management tool, which is the heart of Drude. dsh is a command line tool for controlling all aspects of your project's environment. You can use it to stop and start containers, interact with the host virtual machine, use drush and console to execute commands directly against your Drupal sites, and manage the installation and updating of projects.

Let's see how this works

Download the Drude shell command

​sudo curl -L https://raw.githubusercontent.com/blinkreaction/drude/master/bin/dsh -o /usr/local/bin/dsh sudo chmod +x /usr/local/bin/dsh

You can now use the dsh command.  Use it to install prerequisites, which includes Docker, Vagrant, and VirtualBox.

dsh install prerequisites
dsh install boot2docker

These are all one-time steps for setting up Drude. Now that's done, you only need to set up individual projects. To demonstrate how this works we have Drupal 7 and 8 test projects available. Check their GitHub pages for additional setup instructions, in case the below instructions don’t work for you.


Setting up a project.

Clone the Drupal 8 test project.

git clone https://github.com/blinkreaction/drude-d8-testing.git
cd drude-d8-testing

Use the init command to initialize local settings and install the Drupal site via Drush.

dsh init

Starting containers...
Creating druded8testing_db_1
Creating druded8testing_cli_1
Creating druded8testing_web_1
Installing site...
Installation complete.
User name: admin User password: 5r58daY2vZ [ok]
Congratulations, you installed Drupal!
real 1m18.139s
user 0m0.300s
sys 0m0.174s
Open http://drupal8.drude in your browser to verify the setup.

The init script automates provisioning, which can be modified per project. It can initialize settings for provisioned services, import databases, install sites, compile Sass, revert features, enable or disable modules, run Behat tests, and many other things.

Now, simply point your browser to http://drupal8.drude

Drupal 8 first install home page

That’s it! Any time a team member wants to participate in a project all they have to do is download the project repo and run the init command. And with the environments containerized, they can be deployed anywhere.

Why publicize all this?

Clearly, we've put in a lot of work building a great tool. One that we could easily keep to ourselves. Well, at FFW we are huge supporters of open-source. As one of the main supporters of the Drupal Console project, and a major supporter of Drupal, we believe that benefiting the community as a whole benefits us exponentially in return. We encourage anyone to use this tool, provide feedback, and even contribute to the project.

Apr 21 2016
Apr 21

Drupal Console is the new CLI (Command Line Interface) for Drupal. This tool can help you to generate boilerplate code, as well as interact with, and debug Drupal 8. From the ground up, it is built to utilize the same modern PHP practices that have been adopted in Drupal 8.

Drupal Console takes advantage of the Symfony Console and other well-known third-party components like Twig, Guzzle, and Dependency Injection among others. By embracing those standard components, we’re fully participating in the PHP community, building bridges and encouraging the PHP community to join the Drupal project and allow us to reduce the isolation of Drupal.

Why is Drupal Console important?

Drupal is infamous for having a steep learning curve, complete with its own language of “Drupalisms”. While Drupal 8 simplifies and standardizes the development process, it is more technically advanced and complex than its predecessor. 

Managing the increasing complexity of Drupal 8 could be a daunting task for anyone. Drupal Console has been designed to help you manage that complexity, facilitating Drupal 8 adoption while making development and interaction more efficient and enjoyable. Drupal Console was created with one goal in mind: to allow individuals and teams to develop smarter and faster on Drupal 8. 

Drupal Console features

In this blog post, I will mention some of the most common features and commands of Drupal Console, to serve as a good introduction.

Install Drupal Console

Copy configuration files

The init command copy application configuration files to the user home directory. Modifying this configuration files is how the behavior of the application can be modified. 

drupal init


Validate system requirements

The check command will verify the system requirements and throw error messages if any required extension is missing.

Drupal check

Install Drupal 8

The easiest way to try Drupal 8 on your local machine is by executing the chain command and pass the option --file=~/.console/chain/quick-start.yml

The chain command helps you to automate command execution, allowing you to define an external YAML file containing the definition name, options, and arguments of several commands and execute that list based on the sequence defined in the file.

In this example, the chain command will download and install Drupal using SQLite, and finally, start the PHP's built- in server. Now you only need to open your browser and point it to

Drupal chain quickstart


Generate a module

The generate:module command helps you to:

  • Generate a new module, including a new directory named hello_world at modules/custom directory.
  • Creates a hello_world.info.yml file at modules/custom/hello_world directory.
Drupal generate module


Generate a service

The generate:service command helps you to: 

  • Generate a new service class and register it with the hello_world.services.yml file.
Drupal generate service

Generate a Controller

The generate:controller command helps you to:

  • Generate a new HelloController Class with a hello method at src/Controller directory.
  • Generate a route with a path to /hello/{name} at hello_world.routing.yml file.
Drupal generate controller

Generate a Configuration Form

The generate:form:config command helps you to:

  • Generate a SettingsForm.php class at src/Form directory,
  • Generate a route with path to /admin/config/hello_world/settings at hello_world.routing.yml
  • Register at the hello_world.links.menu.yml file the hello_world.settings_form route using system.admin_config_system as parent.

This command allows you to add a form structure to include form fields based on the field API. Also generates a buildForm and submitForm methods with the required code to store and retrieve form values from the configuration system.

NOTE: The parent route system.admin_config_system for the menu_link can be selected from the command interaction.

Drupal generate form config


Debug Services

The container:debug command displays the currently registered services for an application. Drupal contains several services registered out-of-the-box plus the services added by custom and contributed modules, for that reason I will use peco a simplistic interactive filtering tool to make this debug easier.

Drupal container debug

Debug Routes

The router:debug command displays the currently registered routes for an application. Similar to debugging services. In this example, I will use peco to make this debugging task easier.

Drupal router debug

Create Data

The create:nodes command creates dummy nodes for your application.

Drupal create nodes

Drupal Console provides a YAML to execute using the chain command. This file contains instructions to execute create:users, create:vocabularies, create:terms and create:nodes command using one command.

Change the application language

The settings:set command helps to change the application configuration in this example using the arguments language es we can set Spanish as the application language. After switching the default language the interface is translated.

Drupal generate controller


All of the available commands

The list command can be used to show all of the available commands. A print screen was not included because the more that 130 commands make the image huge to show on this blog post. 

For the full list of commands, you can also visit the documentation page at http://docs.drupalconsole.com/en/commands/available-commands.html 

What makes Drupal Console unique

  • Has been built to utilize the same modern PHP practices adopted by Drupal 8.
  • Generates the code and files required by Drupal 8 modules and components.
  • Facilitate Drupal 8 adoption while making development and interaction more efficient and enjoyable. 
  • Allow individuals and teams to develop smarter and faster on Drupal 8.
  • Help developers to understand Drupal 8 with the "--learning" flag.
  • Fully multilingual and translatable, just like Drupal 8 itself.

Links and resources

Apr 21 2016
Apr 21

This is the third post in my series on Distributed Content Management.  In my first post I defined the term and used a few examples while doing so.  My second post, Great Examples of Distributed Content Management In Higher Education, expanded on the first example of a large university.  In today’s post we’ll explore the second example - a global pharmaceutical company - and once again discuss some great use cases for Distributed Content Management.


Setting The Scene

Pharmaceutical companies, more than companies in many other industries, must carefully consider all elements of their content lifecycle. Providing correct, approved content to both healthcare professionals and consumers is of utmost importance and, as such, web content in the pharmaceutical industry must undergo stringent regulatory review and control.  This requires consistent management across all digital properties and, for larger companies, that can be hundreds, or potentially even thousands, of websites and channels globally.


Use Case 1: Efficient Regulatory Review With Content Publishing Workflows

At first, the idea of Distributed Content Management may seem somewhat counterintuitive to how pharmaceutical companies work.  (In previous posts we’ve used it to explore empowering content creators and overcoming bottlenecks to content publishing - challenging concepts to tout for such a regulated industry.)  However, I’ve also opined that content approval and publishing workflows must be tailored to the specific use case.  

Consider a web publishing workflow that allows medical-legal reviews to take place within a Content Management System.  In some web systems this requires a multi-tiered platform wherein a “staging” version of the website - an exact copy of the real (“production”) website on which content changes have been staged - is made available for regulatory approval before the content is made available to the public.  While this is certainly more efficient than sharing offline documents, a deeper consideration of the technologies used can increase the efficiency and further control its risks.  

Some Content Management Systems, such as Drupal, allow content approval to take place on the production website, controlling the visibility and publishing of content through user authentication and roles instead of requiring  separate “staging” websites.  By mapping the appropriate roles to regulatory affairs, pharmaceutical companies using this approach can save costly and timely deployments of new content to the production site and free up the resources required to manage multiple copies of each website.


Use Case 2: Controlled, Single-Source Content Deployment

For some pharmaceutical content, decentralized content publishing may not be an appropriately-sized solution.  Some content is not only highly-regulated but also highly reused wherever products are marketed and is therefore best suited to be updated, approved, and disseminated from a central source.  Important Safety Information and Indications, for example, are types of content that a pharmaceutical company may choose to publish only through a centralized content repository.  

By establishing policies that all content editing must occur in the content repository, with individual websites disallowed from making changes locally, companies may avoid the need to have regulatory approval workflows on each of those sites and ensure that important information is updated in a timely and error-free way across numerous sites.  Content syndication is a fascinating opportunity for organizations considering Distributed Content Management and I’ll explore some of the available technologies, such as Acquia Content Hub, in later posts.


Use Case 3: Multichannel Brand Content

Single-source content syndication also provides an opportunity for pharmaceutical companies looking to promote their consumer products across multiple channels.  Let’s use e-commerce as an example.  Many companies choose to employ standalone, all-in-one e-commerce systems such as BigCommerce, Demandware and Magento rather than integrate e-commerce stores into each of their individual brand websites.  This makes a tremendous amount of sense: these systems can provide a number of compelling features such as gift cards, coupons, centralized inventory management, and opportunities for cross-selling other products among the company’s brands.  However, because these stores are independent of the main brand website, they too need to display content such as product descriptions, use and dosing information, ingredients, etc.  

By programmatically providing that content from a content repository to the e-commerce system, pharmaceutical companies can eliminate the risk of entering information directly into the store and potentially make use of the streamlined regulatory control processes they’ve already set up for the brand sites.


Use Case 4: Content Delivery To Validated Audiences

In addition to marketing content, pharmaceutical companies maintain large amounts of HCP content - information intended for healthcare professionals.  What content is available to these professionals, how they’ll access it, and how to validate the identity of a user seeking that information

is another key consideration for a pharma  company’s Distributed Content Management strategy.  A common approach is to segregate HCP content into regional “portals” - websites that require medical professionals to create accounts and login to see the information for their country or part of the world.  To overcome the challenge of validating these accounts, companies often integrate with an Identity Provider (IdP) such as DocCheck or Cegedim that specializes in maintaining national registries of healthcare professionals.  

However, having a number of disparate system integrations dependant on which country a website is intended to serve introduces both the overhead of managing multiple bundles of code - sometimes written in entirely different programming languages - and the opportunity for error in integrating the wrong code for the intended region.  Because of this, some global pharmaceutical companies may choose to build a more centralized approach to validation and registration using an integration platform such as Mulesoft Anypoint Platform to amalgamate the different Identity Provider code bundles and provide simultaneous access them all through a dedicated Identity Management system such as Janrain.


What’s Next?

We will continue exploring use cases for distributed content management for the next few posts before moving on to discussing some prerequisites for companies looking to implement Distributed Content Management.  Thoughts or questions?  Reach out in the comments below or tweet them to me at @HankVanZile.

Apr 13 2016
Apr 13

In the first post in this series, What Is Distributed Content Management?, I defined two perspectives on that term: the distributed management of content and the management of distributed content.  While doing so, I used the example of a large university and the need to consider both aspects of Distributed Content Management as part of an effective digital strategy for higher education.  In today’s post I’ll develop that concept a bit further so we can discuss a few use cases in detail.


Setting The Scene


To ensure we’re all on the same page, imagine a large university.  For fun, let’s call it “Drupal University.”  Similar to many higher education institutions, the academic programs at Drupal University are split into multiple schools (let’s say 7) and each of those schools house a number of departments.  Some of the smaller schools may only have 3 to 5 departments, but others, such as Humanities or the Medical School, may have upwards of 25.  And let’s not forget that each of those departments is responsible for a number of different academic programs.  Toss in the requisite assortment of research labs, student organizations and administrative departments - you can see how quickly our college’s web presence gets complex!  At this scale we’re likely dealing with hundreds of different websites, all of which have requirements around content.  It’s the perfect platform for Distributed Content Management! Let’s explore a few use cases that might pop up.  Don’t worry, we’ll start with an easy one.

Distributed Content Management - Higher Education - Universities - FFW Drupal Agency



Use Case 1: Publishing Workflows For Individual Websites


For the web platform at Drupal University, this strategy is obvious.  Unless they employ an absurdly enormous central communications team, large universities simply must distribute their content production.  This doesn’t necessarily mean throwing open the gates!  Consideration of a content approval workflow is a critical part of the content strategy for any organization that employs Distributed Content Management.  Publishing workflows, whether manual or automated, must be tailored not only to the university, but to each school, department or group that’s in charge of a website.  Content to be published on the undergrad admissions websites likely requires significantly more oversight than the blog of an 8-person research lab.  The Medical School, with its 25 departments, probably has its own marketing and communications departments while a smaller school fights for the attention of centralized resources.  This is definitely a case where one size doesn’t fit all.  


Use Case 2: Sharing Content Out - Centralized Content On A Distributed Web Platform


Even the most decentralized universities have content that is centrally produced.  In some cases it may be easiest to just hyperlink to that content in its original location; however, consider, a news story about a student winning a prestigious award.  That story,  produced by the Communications Department for the News section of the college’s main website, may be reposted in its entirety in numerous strategically advantageous places: the homepage of the student’s academic program, the websites for her research lab, a site run by Admissions, another targeted at alumni.  Copying and pasting becomes a less efficient option the further content is distributed - more so when you consider the possibility of edits and possible unpublishing.  In later blog posts, I’ll discuss some of the techniques and products organizations are using to efficiently share content across numerous websites.


Use Case 3: Sharing Content In - Decentralized Websites As Points Of Origin


Another interesting use case presents itself when we consider distributed websites as the starting point for content creation.  Most universities maintain a central calendar of events, whether on a main website or in an Event Management System.  In a well-formed distributed content model, with an an appropriate CMS like Drupal, the same metadata that allows visitors to filter events - audience, department, program, etc. - can be easily used to syndicate those events to various websites.  Unfortunately, the same level of consideration is not always given to the publishing of new events.  Because central event calendars feed information to the entire college, they are often protected systems, editable only by a subset of users with appropriate permissions.  Content managers who are generally empowered to manage their own content may not have the same access to do so, or, in cases where they do have permission, find themselves needing to enter content into an entirely different system to get it published to their site.  But why should this be the case?  By extending the same technologies that allow websites to receive events from a central calendar, we can enable content managers to publish events to the calendar from within the same website they usually manage.  (The same content approval and publishing workflow considerations apply, of course.)


Use Case 4: Integrating With Controlled Content Systems


At the far end of the Distributed Content Management spectrum are systems that need to publish consistent, controlled content to websites with no possibility for discrepancies across multiple sites.  A common case of this in higher education would be a Course Catalog System (Acalog, SmartCatalog, CourseLeaf, etc.).  One of the primary jobs of these systems is to integrate with the university’s Student Information System, providing the canonical description of a course, its contents, credits, costs, etc.  If a university chooses to publish course descriptions on individual program sites, eliminating user error and neglect - mistakes made through copying and pasting, older content not being updated, etc. - is of great importance.  As such, determining a strategy for directly integrating with these systems, rather than relying on a standard approach to decentralized content management, must be an important part of a university’s content strategy.


What’s Next?

In my next post I’ll continue exploring use cases for Distributed Content Management but switch our focus to the pharmaceutical industry.  Thoughts or questions?  Reach out in the comments below or tweet them to me at @HankVanZile.

Apr 05 2016
Apr 05

We’re on a mission to bring more free live Drupal training to more people and organizations than ever before. I’m very pleased to say this quarter we’ve beat our own personal best.

Since January we’ve delivered more than $100,000 worth of free training. That's 19 free trainings in six cities and online to more than 417 registered participants. That’s a total of 72 hours of training delivery and more than 1,700 hours spent in the classroom by individuals learning Drupal. And this doesn't even include all those here at FFW that provided sessions at camps and participated in community training and sprints.

We delivered training in Princeton, New York, Albany, Dallas, Orlando and Chicago and online to participants all over the US, Europe and Asia.

What’s next?

In the coming months we’ll be back to Dallas and down to Atlanta and New Orleans for Drupalcon NA where we’ll be top level Diamond sponsors for the second year in a row. We’ll have live demonstrations at our booth of the latest versions of Drupal Console and of Drude, our new container-based Continuous Development environment for all your Drupal development needs. And we'll continue our online and face to face training in New York and add more cities.

Visit our event page for more information and please take a moment to give us your comments here. Tell us what new topics you’d like us to explore and especially where you’d like us to visit next.

Keep on Drupaling.

Mar 28 2016
Mar 28

I’m often asked why we bother with Drupal camps, conferences, meetups, etc. Being the prime sponsor of every DrupalCamp New Jersey, a repeated DrupalCon Diamond sponsor, hosting monthly coworking events in our New Jersey office, and the countless free community trainings we provide, FFW has a solid history of supporting in-person events. But, what is the point?

After all, we live in the world of tomorrow, where the internet connects us all. Our code is online, email has replaced letters, I use my laptop to make phone calls, online forums have long-term discussions, chat programs have real-time discussions. We’ve surely evolved beyond needing physical space, and wasting time and money on transportation.

Well, a funny thing happened this year at MidCamp (which FFW sponsored.) In this person’s opinion, a bunch of people started feeling a lot less bad about Drupal’s future.


For the past couple years I’ve been heavily involved in Drupal 8’s theme system. Though I feel most of my contributions are small compared to the work done by some others, I try to stay involved and as informed as possible. It is hugely important to know where things are, and where they are going.

I can testify to the amount of energy and enthusiasm that existed in Drupal’s frontend community after Drupal 8’s release. Many of the problems that plagued Drupal themers were solved, and people were looking forward to this new world of sensible theming. Things were looking bright, for once. Until…


In December, not long after Drupal 8’s release, Dries Buytaert published a blog post about decoupling Drupal’s frontend and selecting a JavaScript framework to do it with. This was met with excitement by some, including absolutely no one actually involved in Drupal’s theme system. Saying this whole discussion was deflating invokes imagery of a gradually shrinking balloon. Instead, you need to imagine a pin involved.

I won’t get into the pros and cons of decoupling, various frameworks, and what I or other people think about it. Lots of that discussion is happening all over the Drupal internet. Instead, I'll to stick to my point about events.

At DrupalCampNJ I met Preston So, an Acquia employee who has been on a literal world tour discussing decoupling Drupal. A number of other frontend contributors were there and we had a good discussion about what this all means and the different problems we need to tackle. You can find a recording of that discussion online.

I mentioned that many of us will all be at MidCamp, including a number of theme system, and base theme, maintainers, (myself included.) Sounds like a perfect opportunity to meet. Indeed, it was.


Preston presented a session on decoupling, and organized a BoF to dicsuss matters further. Towards the end of the camp there were many one-on-one and large roundtable discussions about the problems we all see in Drupal’s theme system, and how we might re-imagine it.

Much of the trepidation began to subside, and we started coming up with ideas and plans to move things forward. By Saturday, user personas were being hashed out, roadmaps were in the works, and call it Pollyanna, but I felt a lot more enthusiasm leaving Chicago than arriving.

Peoples is Peoples

As Pete once said, peoples is peoples, and so is Drupal. Regardless of how you feel about the Drupal community, other open-source communities, or even corporations, every product contains the fingerprints of the people that make it.

While technology is amazing, and capable of so many things, we still haven’t replaced the value of face-to-face interaction. I’m not sure we ever will. Online we are confusing, dismissive, quick to judgement, and impatient. In person, we are remarkably capable of finding common ground. We slow down. We empathize. We listen. We are reminded once again that we’re dealing with real people.

We are reminded while having lunch. We are reminded while sipping coffee and chatting in the hallway. We are reminded while discussing ideas over dinner with friends. We are reminded in those moments not crammed into little one hour time slots, where we can relax and breathe. And that’s why these events matter. That’s the point.

For more on the future of Drupal's frontend

If you are curious about the future of Drupal’s frontend, and even want to help, you can do so online and in person. There is a new Slack channel for everything frontend Drupal, a Google doc that summaries some of these discussions (Thanks to Chris Weber and Marc Drummond,) and we’re looking to hold a couple of events during DrupalCon New Orleans. Keep a look out for that.


Also, take a look at Marc Drummond's post-MidCamp writeup for more on the technical details surrounding the future of Drupal's frontend.

Mar 14 2016
Mar 14

Drupal 8 revolutionizes the theming experience with many significant improvements to make theming easier, and give themers the flexibility and control they've never had before. One of those major improvements is to the library management system, which controls the attaching of CSS and JavaScript files.

In this post we will cover how to create and control libraries from a theme. This will include SMACSS categorization for CSS files, dependencies, how to conditionally attach libraries, manipulating libraries that come from anywhere in a site (core, modules, or base themes,) and targeting individual files for removal or replacement. All this without needing a single line of PHP.

Creating Libraries

The scripts and stylesheets properties used in previous versions of Drupal no longer exist. In Drupal 8 we manage all of these files using libraries defined in a .libraries.yml file, added to your theme.

Each library defined in this file includes a unique name, any number of CS or JS files, dependencies, and other information needed to define the properties of the library or assets.

Here is an example of a library file:

# In mythemename.libraries.yml

# Give your library a name.
  version: "1.0.x"
    # The SMACSS category.
      # The path to the css file.
      assets/css/base.css: {}
      assets/css/print.css: { media: print }
    assets/js/myglobal.js {}
    - core/jquery

# In the following example, we add a Google font (Lato).
    base: '//fonts.googleapis.com/css?family=Lato': { external: true }

The file is in YAML format, which Drupal 8 uses for all configuration files. It should be named using the name of your theme, just like your .info.yml file. Let’s take a look at each line to get a better understanding of all the properties.


# Give your library a name.

Each library is given a custom name. This name can be anything, but must be unique to the module or theme that supplies it. This should be easy to keep track of since the libraries that belong to the same module or theme are defined in the same file. The name does not have to be unique to the entire website, because libraries are referenced using both the library name and source. For example, mythemename/my-library-name, but we’ll get to that later when we start attaching and manipulating libraries.


version: "1.0.x"

The version is completely optional. It is only used for identification purposes, along with other properties like license, remote, and a few others that we won’t go into. You may want to add a version for a library you use with multiple projects to keep track of which version is used at any given time. It is also helpful when creating a library that uses CSS or JS from an external source. For example, if you copy code for a slideshow, you may want to add the source version here to keep track of it.


  # The SMACSS category.
    # The path to the css file.
    assets/css/base.css: {}
    assets/css/print.css: { media: print }

All CSS files are included below the css: line. In this case there are two CSS files, base.css and print.css. Each is listed below a category, base and theme, respectively. These are SMACSS categories, which Drupal 8 uses for all CSS file. See the documentation page on CSS file organizaton.


SMACSS is a method for organizing files and CSS rules. You don’t have to follow it in your theming, but you do need to understand how it works and what categories exist, because it used everywhere in Drupal 8 that you encounter CSS files. If you’ve never used SMACSS before, just know that there are five categories; base, layout, component, state, and theme.

When libraries are processed and stylesheets added to a page, they are added in the order of these categories. So a file in the base category will always come before a file in the theme category. The one caveat to this is all module libraries are grouped together and then all theme libraries, so regardless of category, a theme’s stylesheets will always come after the ones supplied by modules.

Back to our example...

Additional Properties

  assets/css/print.css: { media: print }

The line below the SMACSS category is where we add the CSS file. The path, relative to the root of the theme, is used to identify the file. Following the file are a pair of curly braces where additional properties can be set. In this case, the media property is set to print. The available values for media are screen, print, or all. If no value is set, all is used.


  assets/js/myglobal.js {}

Like CSS, we add JavaScript files below the js: line, with each file on a separate line. Unlike CSS, there is no SMACSS category to worry about. But, just like CSS, you can set additional properties inside the curly braces following the file name. For example, adding minified: true will tell Drupal this file has already been minified, so don’t try to minify it again when aggregating the files.

One thing to note is Drupal 8 adds all JavaScript files to the footer of a page. If you need to have your JavaScript loaded in the header, add header: true to the library.

  header: true
    assets/js/myglobal.js {}

If the header property is set to true, any dependencies defined in the library will also get loaded in the header.


  - core/jquery

The dependencies: line is where you add any libraries your library requires. This must be other libraries already defined by your theme, some module, or Drupal core. Notice that the library is referenced using its name, and where it came from. In this case, core. (core refers to a literal core.libraries.yml file. Libraries defined by core modules will use their names; block, node, field, views, system, etc.) This is how we avoid name conflicts.

External Files

      '//fonts.googleapis.com/css?family=Lato': { external: true }

In the second example, we see how to link to external stylesheets. Simply supply the external URL for retrieving the file, and set the external property to true.

Attaching Libraries

There are three basic ways for a theme to attach libraries; in the .info.yml file, directly in a template file, and in a preprocess function. Let's go over each of those methods.


To attach assets globally so they are added to every page of the website, add them in your theme’s .info.yml file.

  - core/normalize
  - mythemename/my-library-name


A great way to attach a library conditionally is to do so directly in a template file. Drupal 8 has a special function called attach_library() just for this purpose.

{# In a Twig template file. #}

{{ attach_library('mythemename/my-library-name') }}

The advantage here is in matching the same conditions of the template file. For example, if you use this method in your node.html.twig, the CSS and JS files will only get added when a node is rendered. If you do it in your node--content-type.html.twig the files will only get added when a node of that particular content type is rendered. You can imagine the flexibility when doing this in specific field or views templates.


Lastly, libraries can be attached in preprocess.

function mythemename_preprocess_page(&$variables) {
  $variables['#attached']['library'][] = 'mythemename/my-library-name';

Here you can add whatever logic needed to match the conditions you want before adding the library to the 'library' array.

Manipulating Libraries

Since all CSS and JS files in Drupal 8 are now in libraries, themes have complete control over those files, regardless of whether they are part of the theme or not. The two main ways to manipulate libraries are with libraries-extend and libraries-override.


Libraries-extend is a property used in your theme’s info file. It attaches your library to any existing library. The real power here is that the inclusion of your library will now match the library that was extended. If there is any special logic behind when and how that library is attached, your library goes along for the ride without you having to do anything to recreate that logic yourself.

# In mythemename.info.yml

  # Classy's forums library is only included when the forums.html.twig
  # template is used. This will add my theme's 'forums' library at the same
  # time.
    - mythemename/forums

In the above example, a forums library is created as part of our example theme, and attached to Classy’s forums library. Any time Classy’s library gets attached, which is only when a forum is rendered, the example theme’s library also gets attached.


Libraries-override is an even more powerful property that can be used in your theme’s info file. It gives you complete control over any library, to manipulate in anyway you see fit.

Let’s take a look at some examples.

Remove a File

# In mythemename.info.yml

  # The library name.
    # CSS files are always labeled as such. This format is required.
      # The SMACSS category is required.
        # The path to the file. It is not a path relative to your theme.
        assets/vendor/jquery.ui/themes/base/theme.css: false

You’ll notice the structure is exactly the same as when you define a library in your .libraries.yml file. You specify the library name, SMACSS category, and original path to the CSS file. The only difference being the library name must also include the source. In this case, core is prepended to the library name, because the jquery.ui library is defined by Drupal core.

On the line with the path to the CSS file, note that this path is the same as defined by the library. It is not a path relative to your theme, or the website root. It is exactly the same as defined by the jquery.ui library. The path is used as a key to identify the CSS file, so it has to match. If you don’t know what the path is, just find the .libraries.yml that defined the library, and copy it.

Lastly, in this example we’ve added false after the file. This tells Drupal to remove that CSS file any time the library is used. When we say, “no more PHP”, this is it. Gone are the days of preprocessing or alters, doing string searches, and unsetting array elements.

Replace a File

# In mythemename.info.yml

        # Replace the System module's maintenance CSS file with a custom one.
        css/system.maintenance.css: css/maintenance.css

Here we have targeted one particular CSS file added by the System module, in a library called maintenance. Following the system.maintenance.css we supply the path to our own CSS file. This path is relative to the theme’s directory. And since we are supplying a file to an already existing library, this file does not have to be part of any other library defined by the theme.

When doing this yourself you’ll also notice that the new file gets placed in the exact same place the original file was linked in the head of a page. Whether the original file was first or seventh, the new file will be the same. This ensures the cascade of rules in all the stylesheets is not disturbed.

Replace and Remove Whole Libraries

# In mythemename.info.yml

  # Replace Classy's messages library with a custom one.

  # Remove Classy's search results library completely.
  classy/search-results: false

In this example, we are doing two things. First, replace Classy’s  messages library with one from the example theme. This will prevent any of the files used in the Classy library from getting used, and replace them with the files in the example theme’s library. Note that your theme’s library does not have to match the original library. You can have more, or fewer, files, and call them whatever you want. This just substitutes your library for the original one.

Second, the false placed after Classy’s search-results library removes it completely. This is similar to how we removed an individual CSS file in the previous example, but in this case we remove the entire library.


As you can see, given the all-in approach Drupal 8 has taken with libraries, and the power of libraries-extend and libraries-override, themers now have total control!

Feb 17 2016
Feb 17

After months of anticipation, Drupal 8 is finally here. Our offices are already buzzing with questions: who will benefit the most from D8? How can all departments utilize the many features of D8 to get the most out of this powerful new platform? And what new best practices can we follow to ensure our sites last?

If you’re currently running a site on Drupal 6 and asking yourself if you should upgrade to Drupal 8, the answer is clear. It’s time to upgrade your Drupal 6 website to a new Drupal 8 website, and here’s why:

Drupal 6 is nearing the end of its life

You may have already heard that on February 24th 2016, Drupal 6 will reach end of life and no longer be supported. What does this mean for you? 

Your organization could be vulnerable to security risks, bugs, and more. Moving forward, the Drupal community will no longer create new Drupal 6 modules, fix bugs in existing D6 modules, and write documentation around Drupal 6, and there will be no more commits on Drupal 6.x to the official tree. In the future, update status may stop working for Drupal 6 sites as well.

Good news: upgrading your Drupal 6 site to Drupal 8 is easy! Drupal 8 core provides a Migration path directly from Drupal 6 as an experimental feature, so sites can update directly to Drupal 8 using either a user interface or with Drush. See Executing an Upgrade from Drupal 6/7 to Drupal 8 for more details. The Migrate feature will be fully supported in a later minor release of Drupal 8.

Drupal 8 is secure

One of the most important effects this will have on organizations is that Drupal’s security team will no longer provide support or Security Advisories for Drupal 6. FFW (and the Drupal community as a whole) strongly encourages anyone with a Drupal 6 site to upgrade to Drupal 8 because of its many advantages and secure framework.

Drupal 8 is a mature and highly-secure CMS framework, with a global community of experts and peer review processes dedicated to maintaining security. Community members from all around the world guarantee Drupal 8 is strong enough to mitigate common vulnerabilities. Some of the largest organizations in the world trust Drupal for its stable and well-supported platform that will keep sensitive information (such as user profiles, documents, and other data) secure and private at all times. 

Drupal 8 has countless advantages

Our FFW Center for Excellence recommends upgrading from Drupal 6 to Drupal 8 because D8 offers a variety of new benefits that make the platform better than ever before. Drupal 8’s native web service integrations are mobile-driven (while Drupal itself serves as the data source), ensuring your stable D8 site looks great on any device. Drupal 8 also offers unmatched ‘future-proofing’, meaning your new Drupal 8 site is built to last. D8 is compatible with the most current versions of all major internet browsers and will remain compatible with future versions. But this is the best part: D8 is built with more widely-used coding practices than ever before, guaranteeing that the platform’s flexibility and scalability are accessible more developers and development teams than previous versions of Drupal.

By contrast, Drupal 6 is already incompatible with several prominent browsers. This shortcoming is due to outdated coding standards and markup that Drupal 6 supports. While Drupal 6 and 7 provide some core functionality with the standard installation, Drupal 8 is the first to offer unprecedented out-of-the-box capabilities that provide feature-rich websites without having to install, configure, and maintain numerous add-on modules to achieve the functionalities that matter most to your organization.

Still not convinced? Here are some more advantages to adopting Drupal 8:

Mobile-friendly, mobile-first 

All built-in themes in Drupal 8 are responsive, and administration pages are even designed for use on mobile devices. At last, data tables automatically scale according to screen size, eliminating the previous struggle for content editors working with Drupal 6, and even Drupal 7. This is a key feature for sites that report and distribute statistical data.

Easy in-place content editing

With the new editor functionality and bundled CKEditor WYSIWYG editor, Drupal 8 allows your to perform in-place content editing without ever having to load the full edit form.

More field types in core

Drupal 8 extends its signature content structuring system by including more field types in core and allowing fields to be attached to more types of content. You can also attach fields to forms to create custom contact forms.

We believe in Drupal 8

Did you know FFW launched our own website on Drupal 8? Our confidence in this new platform isn’t unprecedented; we have been involved in the development and refinement of D8 and supporting tools and modules throughout development. FFW is also currently in active development of several Drupal 8 projects with reputable clients, including a multilingual site for a publicly traded biomedical company and a new site for one of the largest open source organizations in the world.

One of our own Drupal 8 developers, Jesus Manuel Olivas, is the lead contributor to the Drupal Console project, a suite of tools that you run on a command line interface (CLI) to generate boilerplate code and interact with a Drupal 8 installation. 

We trust this platform, and we can’t wait to work with you to ensure your website is as stable, secure, and long-lasting as possible. Make sure to visit our events page to sign up for one of our free Drupal 8 trainings. Talk to us about how we can help you move from Drupal 6 to Drupal 8, and don’t hesitate to reach out with any additional questions about D8.

Feb 10 2016
Feb 10

FFW is proud to announce that we have changed the format of our training sessions. After an overwhelming positive response from our free trainings, we have decided to expand our training sessions and bring them straight to you, in person. I am pleased to announce that starting on February 12 in Dallas members of the Drupal community will have the opportunity to attend our in-person trainings at various locations throughout the year. I will also be holding trainings in Chicago, Orlando, and Atlanta as part of this year’s training schedule. The training opportunities FFW will be providing at Drupal camps is still being determined, so be sure to check your local camp.

Wondering why we’re expanding our training reach? We realized that there was a need for easily accessible training in the Drupal community and we wanted to help fulfil that need. We will still be hosting our regular online trainings throughout the year, providing even more opportunities to learn many new things about Drupal. We are constantly posting new course dates and developing new content, so I encourage you to check back often.

We are still often asked why we offer such wide variety of classes for free, and the answer is simple: FFW is proud to be a part of the Drupal community and we want to do what we can to help it grow. FFW is highly committed to helping organizations and individuals adopt Drupal successfully. At FFW, we believe great training helps create great, results-oriented websites. That's a win-win-win for you, Drupal, and FFW.

Please consider supporting the Drupal Association instead. Individual membership is only $15.

I hope to see you in an online training session, meet you in person at one of our new training locations, or at any of the other many Drupal events FFW will sponsor in 2016. Until then, please contact me if you have any questions about the FFW Center of Excellence.

Jan 27 2016
Jan 27

As more and more organizations grow their digital presence into online empires, the demand for innovation and efficiency for managing content across a number of websites has never been greater. This ranges from global associations centrally managing content and website functionality for their many local chapters and corresponding digital properties to record labels that run hundreds of artist websites on a single platform. 

If you follow the world of websites and content management, you probably know how critical multi-sites have become for organizations that face these issues. You might also know that Drupal is widely regarded as the CMS that is used to deliver the most robust multi-sites in the world. This includes massive web platforms like of the City of Copenhagen, the National Audubon Society, and Warner Music Group. In many ways, multi-sites are much like a series of roads, leading users on a journey to find connected content that seems stretched across the Internet but actually exists on a unified platform. 

With a multi-site solution, web teams effectively have a network of sites that run on a single unified platform. Each site shares the same code but has a different database. This means that content, configuration, and appearance can be vastly different, yet the code behind it all is consistent and managed centrally. This presents some huge advantages and efficiencies when it comes to managing a portfolio of websites, both for developers and content editors. 

To discuss the wide variety of benefits multi-sites can provide organizations, I have put together a series of blog posts that will delve into the benefits of multi-sites, whether a multi-site solution is right for your organization, and whether a multi-site makes sense for everyone. 

Organizing Content across Different Sites

I’d like to begin our exploration of multi-sites by taking a look at the topic of content sharing with multi-site solutions. Content sharing has been an important topic as multi-site solutions continue to evolve. Different organizations have varying approaches to organizing their content across multiple sites. FFW has worked with some organizations that have what we would consider loose relationships between content across multiple sites. In such a case, each site was managed by a web team that had their own group of editors, which required every group to be responsible for creating and managing content on individual sites. 

However, there are some cases where editors want to use content across different sites. There are several options for how organizations can choose to share content across different sites. Among these options, organizations can choose between pulling individual articles from another website or subscribing to the feed and pulling all the content appearing in that particular feed to their site automatically. 

Content Sharing with Multi-site Solutions

The main goal of multi-site and content sharing solutions is to build a system that is easier for editors to use. This should be simple, where the only action editors need to do to pull the content from its original home and display it on a different site is to copy the URL of the article they want to pull in and paste it to the backend. Everything else is automated. On a technical level, each site provides a metatag with the URL from where the article is imported. That URL is a service call that provides the content is in JSON format, which is easy for the system to parse and run the import. We also use tagging so the content editor is able to specify what tags this content should fall into. Different sites have different sets of taxonomy, and what makes sense for one site might not work for another.

A similar approach has been taken for subscribing to the feed. Each website has pages that list content by terms. When editors want to subscribe to a page, all they have to do is copy the URL of the page, paste it to special form, and specify the tags all content should fall into. 

Models for Content Sharing

When sharing content across multiple sites, organizations can choose between sharing all content or select types of content. Systems can either pull content fully (all images, texts, fields etc.) or pull the teasers only. Visitors can be redirected to the site the content is being pulled from in order to read the full version via the teasers. The decision between these two options depends on what goals the organization wants to meet and is typically made by businesses on a case-by-case basis. Most importantly, organizations must determine how comfortable they feel with content displaying on other sites in its full version, meaning they will not receive visitors on other sites.  

Another interesting situation can occur when displaying teasers.  Let’s say that content X has been created on Site 1. Site 2 is interested in a feed where article X is displayed and subscribes to it. Site 3 pulls the feed from Site 2 where content X displayed. In this situation, it’s important to note that if visitors on site 3 click on content X teaser, they are redirected to Site 1 instead of site 2 since this is where the content was originally created. This is why we always keep the original references. 

When driving visitors of one site to another, it’s also important to ask site owners if they would like to keep the references to the site where content has been seen the first time. During one of our projects, FFW implemented a special block on a site that displayed information where visitors are coming from with the link to that site (page).  This way, we could drive visitors back to original site. 

The Benefits of Multi-site Content Sharing

As you can see, multi-site content sharing has a number of advantages that can be utilized by many corporations, from universities to commercial brands and associations. We’d love to hear from you about how you’ve used multi-site content sharing to grow your business. Feel free to discuss in the comments or reach out to us with any questions.

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