Drupal Feeds

Automatically add a Table Of Contents (TOC) to your Drupal pages to make it easier to navigate long articles.

Drupal 8 is gaining traction since its beta version came out. Previously we mentioned about
modules that can optimize your website (Field image tooltips, Group) and even satisfy the
most demanding customer creating individual, customized for the requirements of the

Read more

What it was like being part of the Drupal apprenticeship scheme.

Thank you, Drupal community - I want to express my sincere thanks to everyone who helped me prepare this presentation, sharing their insights into how Drupal fits into bigger and better ways of doing business. The fact that we can all talk about this so openly while competing for business is one more sign of how special the Drupal community is. I’m so glad you all choose to “open source” some of the ways you are succeeding and help the rest of us along the way! And thank you Drupal Camp London organizers for the invitation to give a keynote address at your conference, and thanks to the audience for your presence and warm reception despite the early hour on Sunday.

Drupal isn’t enough anymore

10 years ago, just having a website was transformational. But pretty much every business has one nowadays; they're a commodity. You need something especially good looking, functional, or powerful for it to be special. Your skillset--the ability to make functional, powerful websites--was also transformational, a good base for running a business. Now that is largely a commodity, too. Competitors like Wordpress.com, Squarespace, Wix, Shopify, and others offer solid, attractive, basic websites with lots of useful functionality. And they are only getting easier to use with every release.

So don’t sell Drupal!

What's the answer? How do you stay relevant and build a sales pipeline today? Don't sell Drupal. Move up the value chain. If you simply receive instructions to put a banner here and a slideshow there--to turn someone else's plan into code and nothing more--you're not where you need to be on that chain.

Placing yourself and your business higher up the value-creation chain means offering more than writing code, more than offering to build Drupal websites. You need to offer more: business value. You might have special insights or expertise. You might be able to solve the problems of a particular industry or vertical especially well it. You could deliver value through something you build with Drupal. Drupal might be one of your weapons of choice for facilitating digital transformation, or marketing, or what have you ... and you have a choice: specialize or diversify ...

Keynote Drupal Camp London 2017 - video

Session Takeaways
  • Why hanging out the Drupal slate isn't enough anymore.
  • Questions and problems that businesses need help with today ... That you may be able to answer.
  • Examples of Drupal-based businesses delivering more value than just Drupal code.
My Thanks ...

My thanks once again to all of the following people and everyone else whose ideas and actions helped inspire me and help our community:

  • Florian Lorétan - Wunder
  • Alex Urevick-Ackelsberg - Zivtech / Probo.ci
  • Tim Deeson & Christiann Jansen - Deeson
  • Megan Sanicki - Drupal Association
  • Lukas Fischer - NetNode / OpenInbound
  • Dave Ingram And Andrea Rosi - Acquia Lift
  • Adrian Rollet & Ronald Ashri - Roomify
  • Dominique de Cooman - Dropsolid / Cooldrops
Skill Level: BeginnerIntermediateAdvanced

This is a joint statement from project lead Dries Buytaert and Megan Sanicki, Drupal Association Executive Director.

Over the last week, the Drupal community has been in a debate over the various decisions made by us in relation to long-time Drupal developer Larry Garfield. As with any such decisions, and especially due to the circumstances of this one, there has been controversy, misinformation and rumors, as well as healthy conversation and debate. Many people feel hurt, worried, and confused. The fact that this matter became very public and divisive greatly saddens all of us involved, especially as we can see the pain it has caused many.

First off, we want to apologize for not responding sooner. We had to take a pause to process the community’s reaction.  We also wanted to take the time to talk to community members to make sure all of the concerns were heard and understood. This was further complicated by the fact that we don't have a playbook for how to respond in unusual situations like this. We also want to acknowledge that our communication has not been as clear as it should be on this matter, and we are sorry for the added confusion.

We want to thank all of the community members who stepped in to help. Many spent days helping other community members by listening, hosting discussions to foster healthy, respectful conversations, and more. You have helped many people and your caring acts reminded us once again why we love to serve the community and why it is so special.

Over the last week, we talked to many people and read hundreds of posts in various channels. These are some of the things that we heard:

  • People are afraid that they will be asked to leave the community because of their beliefs or sexual lifestyles.

  • There are concerns about Drupal leadership playing "thought police" on what are and are not acceptable viewpoints to hold.

  • People want to hear more about the timeline, information gathered, and how decisions were made.

  • People don't understand why there weren’t any ramifications for those who participated in gathering information about Larry's private life.

  • People believe Dries has too much authority.

  • People believe that a decision this complex should not be made by a single individual.

And we heard much more.

We know this has been difficult for all involved. There is no quick solution to the current situation; it will take time to heal, but we want to make a start today by providing better insight into our decision-making process, answering questions with the FAQ found below, and by placing a call for improvements in our governance, conflict-resolution processes, and communication.  

Addressing community questions and concerns

One of the main concerns that has been voiced is that a long-standing member of the Drupal community was removed, based solely on his beliefs being outside the "norm". We feel this is not representative of the situation.

We want to strongly emphasize that Drupal is an open-minded and inclusive community, and we welcome people of all backgrounds. Our community’s diversity is something to cherish and celebrate as well as protect.  We apologize for any anxiety we caused you and reiterate that our decision was not based on anyone’s sexual practices.

Dries and Megan based their decisions on information from a variety of sources, including the Community Working Group and Larry himself. This information included:

(a) reports, both formal and informal
(b) some of Larry's online interactions, both on and off Drupal.org
(c) information provided by Larry during subsequent discussions to get clarity
(d) information from one or more members-only sites.
It should be strongly noted that we do not condone the manner in which this last source of information was gathered by members of our community.  

Insights from this collection of information caused us to take action, particularly given Larry's prominent leadership role in the community, which leads to a much greater impact of his words and actions.

We heard that many would like to better understand the timeline, information gathered, and how decisions were made. While the news of last week was a complete surprise to most, it is important to note that this has been a careful, and deliberate process that has been going on since October 2016. Following the Drupal community's governance, the Community Working Group attempted to provide conflict resolution. When it became clear that some of the issues raised went beyond the scope of their charter, they determined that it was appropriate for the matter to be escalated to Dries, as project lead. This was consistent with their existing policy and process.

Dries discussed the information from the Community Working Group with Megan and some board members. Dries, as project lead, made the decision about Larry’s role in the project during this discussion.  

Some have asked why Larry was removed from the community and not just from his leadership roles. The answer is that Larry had indicated on several occasions that he was drawing down his involvement in the Drupal project, and that context helped inform Dries’ decision.

Dries, with the support of the Community Working Group, had the first of what was intended to be a number of conversations to resolve any remaining concerns.

Megan was informed about Dries’ decision, and also reviewed the information provided by the Community Working Group. Based on that information, Megan made the operational decision to remove Larry’s DrupalCon session and concluded his track chair role.

Larry appealed Megan’s decision to the board, which only has oversight of the Drupal Association. They reviewed the Community Working Group information and Larry’s personal statements, met in a special Executive Session attended by all board members, and upheld Megan’s decision. Dries recused himself from this vote, so the board could make its decision independently.

After the appeal process, Larry chose to publish his own account of what happened, effectively ending the process in the middle of what we expected to be a series of constructive discussions. This resulted in several loose ends.

After Larry’s second blog post, on Tuesday, March 28th, he reached out privately to Dries to discuss how to resolve matters and find the best way forward.

We remain committed to working on closure for this situation with care and respect for everyone involved.  Dries and the Community Working Group hope to have a private discussion with Larry in the coming weeks.

Many have also expressed anger over how the information about Larry came to light, and whether there will be consequences for those who participated in gathering information about his private life. The Community Working Group is currently handling this situation through their standard process.

What needs to change

We are fortunate that we do have governance in place. We have never encountered a situation like this before, where a decision this complex had to be escalated and made. This extraordinary situation highlighted areas that we need to improve. From our own observations and what we heard from the community, we identified some specific areas of improvement (but by no means all):

  • Diversity, equality, and inclusivity issues are complex and require new perspectives and approaches, especially as we assess and improve our Code of Conduct.

  • It is not healthy or wise to escalate difficult decisions about code of conduct or community membership solely to the project lead.

  • We need to clearly define our values so that everyone knows and agrees to the context in which the community works together.

  • We need to figure out how to balance transparency with the need to maintain a safe space and provide confidentiality for individuals in order to resolve conflicts in a way that causes minimal disruption to our community.

There is a lot to address. We will launch several initiatives to find solutions to the problems above.  We want to collaborate with the community, the Drupal Association, and outside experts on these efforts. It is important that we take these steps. We value our special community and we want to make sure that it has the right structure and sound governance to remain healthy and vibrant.

We want to begin healing to start right away and that starts with us talking more with the community. We will host online meetings and a meeting at DrupalCon Baltimore on these topics where we can have a healthy dialogue. This will provide community members the opportunity to talk directly with the Community Working Group, Megan, and Dries to propose solutions to some of the governance challenges that brought us here.

Finally, we want to acknowledge this has been a very difficult and unprecedented situation. We realize not everyone will agree with our decisions, but we hope all can understand the care we took in deliberating and the intention behind our actions. We appreciate the community’s patience on this matter, and we look forward to taking these steps in collaboration with you.

----

FAQ

When did the conflict resolution process start?

  • October of 2016.

Who is responsible for what decision?

  • Dries, as project lead, made the decision about Larry’s role in the project after the Community Working Group escalated to him when they felt they could not resolve the issues surrounding this matter.

  • Executive Director of the Drupal Association Megan Sanicki made the decision to to remove Larry’s speaking and track chairmanship at DrupalCon.

  • Larry appealed the DrupalCon decision, which then went to the Drupal Association board who reviewed material provided by the Community Working Group along with Larry’s statements. They upheld Megan’s decision.  Dries recused himself from this vote.

What was the process followed for each decision?

  • The Community Working Group, which is part of Drupal’s governance structure, provided conflict resolution. When it became clear that some of the issues raised went beyond the scope of their charter, they determined that it was appropriate for the matter to be escalated to Dries. This is consistent with their existing policy and process.

  • Dries discussed the information from the Community Working Group with Megan, and some board members. Dries also met with Larry. Larry had indicated on several occasions that he was drawing down his involvement in the Drupal project. That context informed Dries' decision. It is also important to note that Dries intended to have more discussions with Larry to determine what the decision looked like, but those conversations ended when Larry chose to post publicly.

  • Megan was informed about Dries’ decision and also reviewed the information provided by the Community Working Group. Based on Dries’ decision and information learned from the Community Working Group materials, Megan made the operational decision to remove Larry’s DrupalCon session and concluded his track chair role.

  • Larry appealed Megan’s decision to the board, who only have oversight of Drupal Association. They reviewed the Community Working Group information and Larry’s personal statements and upheld Megan’s decision.  Note: Dries recused himself.

What information was used to inform the decisions?

  • (a) reports, both formal and informal, (b) some of Larry's online interactions, both on and off Drupal.org, (c) information provided by Larry during subsequent discussions to get clarity, and (d) information from one or more members-only sites. It should be strongly noted that we do not condone the manner in which this last source of information was gathered by members of our community.   

Did Dries overrule the Community Working Group?

  • No, he did not. The process is designed so that the Community Working Group can escalate issues to Dries if they cannot be resolved. This process was followed.

Is the Drupal project “against” people who practice BDSM or other non-mainstream sexual practices?

  • Absolutely not. We are an open-minded and inclusive community.

Will there be repercussions for Klaus Purer’s conduct?

  • The Community Working Group is handling this situation through their standard process.

In recent days there's been a bunch of insightful and thought provoking reflection within the Drupal community (as well as a share of bullshit). I've benefited from hearing perspectives that remind me of my biases and privileged placement as a cis white male. A comment by Melissa Anderson, someone I know and respect, had particular impact for me.

A lot of attention has focused on a particular action by Drupal project owner Dries Buytaert. But many are going deeper.

The trouble with Drupal is not so much any individual action.

The trouble is that, for all its collective trappings and thousands of contributors, Drupal is formally structured as a dictatorship.

Really? In 2017? Yes, really.

The Thing About Dictatorship

As detailed in documentation of the Drupal project structure, the self-anointed "benevolent dictator for life" not only exerts ultimate control over code but also "preserves [that is, controls] the philosophy, culture, and principles of the project."

Wow. Think about that for a minute.

The occasional overt dictate can indeed be worrisome. But I'm actually much more troubled by what's so normalized in the project that it passes without comment.

I won't repeat what I've gone on (and on!) about in previous comments and reflections on Drupal's power structure going back over a dozen years. Here's a selection:

But I will add I'm struck anew by what seems to me the unusual depth and reach of the authoritarian model in the Drupal project.

I've often heard it said, for example, that Linux, too, has a so-called "benevolent dictator for life".

True. But, contrary to Drupal, the Linux dictator doesn't individually set the terms of reference of, and appoint every member to, key community structures. (Come to think of it, isn't there something Orwellian about a so-called "Community Working Group" appointed by a dictator?) Unlike Buytaert with the Drupal Association, the Linux dictator doesn't have his name written into the bylaws of the Linux Foundation as a director with own reserved slot, nor has he served as the de facto permanent board president of the Linux Foundation since its inception. He doesn't have a seemingly permanent seat on the committee that vets every nomination to the Linux Foundation board.

And, crucially, unlike Buytaert in Drupal, he isn't a founder and key executive of the Linux company that exerts the deepest influence on the software.

Effective checks on the absolute power of the project founder? It's really hard to find any.

For thousands of people caught up in the Drupal project, what does all this mean in practice? As in many communities, boundaries often blur. Drupal can come to define not only one's work life, but also leisure activities like volunteer coding or meetup organizing, even key daily social links and interactions.

Put that together with a patriarchal model, intimately tied to capitalism and corporate power, permeating all these realms - work, leisure, friendship, community - and you get a deeply troubling degree of influence. One that, precisely because it's everywhere, may be almost invisible. In a community where it's all about personal ties and influence, power seldom needs to act overtly.

"Dictator for life". This, too, is something to think long and hard about. That's a lot of future years. For those who stay, what does it mean, this prospect of being part of a dictatorship culture most of one's life?

There's a tonne of beautiful energy in the Drupal project. There are brilliant and passionate people who care deeply about our community and are rightfully proud of our collective project.

Not thanks to the dictatorship model. In spite of it.

Is what we're seeing the beginnings of a "Drupal spring"? If so, where might it lead?

The Coming Fork

Conditions are ripe for a fork of the Drupal project. But what kind of fork?

For a software community mired in regressive power dynamics, a fork can be a positive source of renewal, allowing participants to resolve contradictions and carry forward the project's best attributes.

Or a fork can replicate the same regressive crap that prompted problems in the first place.

Worse--given the current context, a fork could reinforce and enshrine forms of cis white male privilege.

So the key question is not so much whether to fork. Rather, it seems to be: if so, how?

A cultural fork

Yes, there are deep problems with Drupal's code base, many resulting from the warping effects of corporate interests. But the primary challenge of a fork is not about code. It's about culture.

The dictatorship model in Drupal runs deep. So, no, a light makeover isn't going to cut it. A fork needs a radical cultural reset.

We need to look to voices of diversity and inclusion.

We need to create room for critical perspectives and insights that too often have been shouted down by louder voices in the project--ones that, over and over, have rushed to attack questioners of the founder's prerogatives. (I speak as someone who's repeatedly been targeted for my critical voice. And sometimes, yes, silenced.)

We need to deeply question a culture that promotes living for the cause as a positive or even a required leadership quality.

In the Backdrop fork of Drupal, I and others promoted a "project management committee" structure, replacing the single dictator with a group of lead contributors. And I do think the more diverse and inclusive Backdrop leadership team is a huge improvement over Drupal.

But, here, is it enough? Not nearly.

I personally want to look for inspiration and ideas to the platform cooperative movement, which is opening horizons for free software collectively owned by those who use and build it.

That vs. dictatorship? I know where my heart is.

Existing strengths

A fork should draw in existing progressive initiatives and structures in and around the Drupal space.

One that I'm involved with is Drutopia.

We've also got an expending number of engaged, radical organizations and cooperatives in the Drupal sphere. How do we draw them in? Or, maybe better put: how can we be open to them drawing us in?

A fork shouldn't require people to switch

Strategically, a new fork will probably have the most scope and impact if it doesn't force people to switch immediately to something new. Instead, it could work as a drop-in replacement for Drupal 8--and future Drupal versions.

For those familiar with the MySQL database, think MariaDB, the community-led fork of MySQL. If you already use MySQL, you can switch very painlessly to MariaDB--and get some great improvements for your effort. Your existing MySQL databases just work. The MariaDB project maintains compatibility by merging in changes from MySQL.

In the same way, a Drupal fork could "just work" if your site was originally built on Drupal.

Moving Forward

Crises in authoritarian systems play out in familiar ways. There will be - there already are - calls for a brand of "healing" that involves returning to the fold, reflecting sagely on lessons supposedly learned, and pledging renewed faith in the beneficent leader. Ah, I see one such post just appeared from the Drupal Association. Right on cue.

And there will be organizing on the ground. By those of us truly fed up with a corrosive patriarchal agenda, one that once again masks its power behind a false and exploitative language of inclusion.

Who are hungry for progressive change.

"If you're not testing, you're doing it wrong." I can't remember how many times I've heard those words. Each time, I'd feel a little pang of guilt, a little bit of shame that every day, I wrote code for myself and clients that wasn't tested. I'd be frustrated with the developers who repeated that mantra. Sure, it was easy to say, but hard to live up to. How do I test? What do I test? Should I test? How would I justify the costs?

As a developer who started his career writing custom code for Drupal applications, it was easy to skip testing. Drupal 7 was really quite untestable, at least in any practical sense. Drupal core itself was tested, and big modules like Views, Ctools, and Entity API had test suites too. But finding tests in other custom code or smaller modules was a rarity. Even today, with a vastly more testable code base, documentation for testing Drupal code is terse and hard to come by. It's focused on educating core contributors and module maintainers, not day-to-day developers writing modules to satisfy particular real-world needs.

I hope this series will change that for you.

I will make the case that you should be testing; that you'll save time and you'll save money, and that you won't need to "justify the cost." This series will start from first principles:

  • What is automated testing?
  • Why is automated testing a net positive?
  • How do I write my first test?
  • How do I write the one after that? (because that's really where it gets hard isn't it?)
Part Zero What is automated testing?

I define automated testing as the act of asserting that your code achieves its goals without human interaction.

Types of Automated Tests

There are many types of automated testing. Each serves a specific need and each operates at a different level of abstraction. They form something like a pyramid, your most numerous tests should be at the bottom, as you go higher up the stack, you should have fewer and fewer tests.

At the lowest level, are unit tests (and that's what this series will focus on). Unit testing is code that you write to test or "exercise" the actual custom code that you write. Unit tests isolate very small bits of functionality and assert that your code can handle all kinds of inputs correctly. You might write a unit test to assert that an add(x, y) function adds numbers correctly.

Above unit tests, are integration tests. Integration tests assert that the small bits of functionality that you tested with unit tests "integrate" together. Perhaps you wrote a suite of arithmetic functions which you unit tested individually. When those functions come together into a calculator, you might write integration tests to validate that they all work in harmony.

At the highest level are system tests. System tests assert that your application works as a cohesive whole. These "acceptance" tests are usually best expressed as the functionality your client cares about. "Can my potential customer use a calculator to estimate a mortgage payment and then call me for a quote?"

There are no definite lines of separation between these types of tests, they all fall along a continuum—it's a curve, not a step function.

It's not important to know exactly where your test falls on that curve, really, it's just important to know that:

  • You can test at different levels of abstraction.
  • You do not need to test everything at every level of abstraction.
Different Tools for Different Tests

Just as there are different types of tests, there are different tools that go along with them. As with all things in software development, there are lots of tooling choices and tradeoffs no matter what you choose. The beauty of using Drupal, however (or any framework) is that some of those choices have already been made for you either officially or by convention in the community.

At the lowest level, is unit testing. The standard adopted by Drupal 8 is PHPUnit. PHPUnit is a suite of command line tools and base classes that make writing tests easier. Drupal has extended some of the PHPUnit classes with some extra features that make testing code written specifically for Drupal easier. The Drupal class used for unit testing is called UnitTestCase. We're going to take a deep dive into this, and all the Drupal testing classes and tools later in the series.

At the integration test level, Drupal uses a mix of PHPUnit and Simpletest, but is migrating all of its Simpletest based code to extensions of PHPUnit tests that can achieve the same things. In Drupal, the class primarily used for this kind of testing is called KernelTestBase.

At the system test level the lines begin to become somewhat blurred. Drupal calls these “Functional” tests and there are two classes for them. WebTestCase and BrowserTestBase classes can do quite a bit, and are the standard for testing Drupal Core and contributed modules. They work well for contributed modules and Drupal core because they don’t need to test the specifics of a real-world Drupal application and all the configuration and customization that implies.

The Drupal community has largely settled on Behat as the standard for testing real-world Drupal applications. Behat works by starting a "headless" browser that can emulate a real user by doing things like clicking links and filling out forms. These kinds of tests let you test the configuration of your Drupal site holistically—your theme, javascript and custom code—which ensures that everything works well together.

I hope this post has given you a sense of what automated testing is and some basic terminology that we can share in the next part of this series: “Why Automated Testing will Save You Time and Treasure.”

Start:  2017-04-04 12:00 - 2017-04-06 12:00 UTC Organizers:  catch cilefen xjm Event type:  Online meeting (eg. IRC meeting)

This Wednesday, April 05 is the release window for Drupal 8.3.0, the next scheduled minor release of Drupal 8. There will be no Drupal 7 bugfix release this month.

To ensure a reliable release window for the minor release, there will be a Drupal 8.3.x commit freeze from 12:00 UTC Tuesday to 12:00 UTC Thursday. Now is a good time to update your development/staging servers to the latest 8.3.x-dev code and help us catch any regressions in advance. If you do find any regressions, please report them in the issue queue. Thanks!

To see all of the latest changes that will be included in the release, see the 8.3.x commit log.

Other upcoming core release windows after this week include:

  • Wednesday, April 19 (security release window)
  • Wednesday, May 03 (patch release window)

For more information on Drupal core release windows, see the documentation on release timing and security releases, as well as the Drupal core release cycle overview.

Drupal Dev Days Seville 2017 documentation christophe Sat, 01/04/2017 - 17:38

Just bookmarking here the amazing documentation that was produced during the Dev Days.

MidCamp 2017 was a huge success! Thank you to everyone who came, helped, supported, spoke and attended!

MidCamp 2018 is confirmed for March 8th through March 11th, 2018 back here at the DePaul University Lincoln Park Student Center!

Come and join us next year!

Stay connected:

MidCamp is one of my favorite Drupal events—it hits the sweet spot (at least for me) in terms of diversity, topics, and camp size. I was ecstatic when one of my session submissions was accepted, and just finished presenting Developing for Drupal 8 with Drupal VM.

You can see slides from the presentation here: Drupal VM for Drupal 8 Development, but without the full video there are a lot of gaps (especially on slides where there's just a giant emoji!). Luckily, Kevin Thull of Blue Drop Shop is hard at work recording all the sessions and posting them to YouTube. He's already processed the video from my session, and it's available below:

We are very happy to announce that after several months of combined work with Concern Worldwide and Apple we now support Apple Pay via desktop, iPhone, iPad and Apple Watch @ Concern.net!

This was a fascinating endeavour for our team with many requirements spanning both hardware and software.

We now have tools in place for Concern.net donation forms to enable existing donors to make a donation, or increase their regular donations by following a marketing link and press a single button on the form before using their fingerprint to authenticate payment.

There is a famous saying that “The best GUI is no GUI” This ideal is now a tangible possibility.

Stay tuned for further developments as to how you can donate without fuss to one of the world’s leading charities.

Our many thanks to all the teams at SystemSeed, Concern and Apple that helped facilitate this work.

Please consider making the world a brighter place for those in need by going to Concern.net and donating via Apple Pay or any other method today.

Third & Grove goes to DrupalCon Baltimore antonella Mon, 04/03/2017 - 05:59

The original purpose of the Features module was to “bundle reusable functionality”. The classic example was a “Photo Gallery” feature that could be created once and then used on multiple sites.

In Drupal 7, Features was also burdened with managing and deploying site configuration. This burden was removed in Drupal 8 when configuration management became part of Core, allowing Features to return to its original purpose.

But, as the primary maintainer of the Features module, I sadly admit that:

“Features does not actually accomplish the goal of creating truly reusable functionality.”

Let’s look more closely the classic “Photo Gallery” example. Export your Gallery content type, your Image field storage and instance, your View and Image Style into a Feature module. You can copy this module to another site and install it to create a Gallery. But what happens if your other site already has an Image field you want to share? What happens when the namespace used for the features on your new site is different from the namespace of your original site? What happens if you want to add the gallery to an existing content type, such as a Blog?

The problem with configuration in Drupal is that it is full of machine names: content types, fields, views, dependencies, etc. You are supposed to prepend a unique namespace to these machine names to prevent conflicts with other modules and project, but that means you are stuck with that namespace when trying to reuse functionality. When you make a copy of the feature module and change all of the machine names, it becomes difficult to update the original feature with any improvements that might be made on the new project.

Basically, your Feature is not actually a reusable component.

Feature Templates

Towards the end of Open Atrium development in Drupal 7, we started using an architecture that allowed reusable functionality to be layered across multiple content types. The Related Content feature added Paragraph bundles but had no opinion about which content type you added these paragraphs to. This was accomplished using the Features Template module in D7, which allowed you to create a template of configuration and use it to create multiple instances of that same configuration across multiple content types. Until now, there was no way to reuse configuration like that in Drupal 8.

Introducing: Config Actions

The new Config Actions module helps to solve this problem and provides a replacement for both the Features Template and Features Override modules for Drupal 8. Config Actions is a plugin-driven module that simply does the following:

  • Load configuration from a source

  • Transform the config data and perform optional string replacements.

  • Save the new data to a destination

These actions are read from YAML files stored within your custom module config/actions folder. When your module is enabled, each action is executed, allowing you to easily manipulate configuration data without writing any code. If you want to write code, you can use the Config Actions API to easily manipulate configuration within your own update hooks and other functions.

Creating templates

Let’s take the “Photo Gallery” example and build a template that can be used by Config Actions:

  1. Use Features to export the configuration (content type, fields, views, etc) into a custom module (custom_gallery).

  2. Move the YAML files from the config/install folder into a config/templates folder.

  3. Edit the YAML files and replace the hard-coded machine names with variables, such as %field_name% and %content_type%.

  4. Create a Config Actions YAML file that loads configuration from these template files, performs string replacement for the variables, then saves the configuration to the active database store.

One of the edited feature configuration template files (field.storage.node.image.yml) would look something like this:

  1. langcode: en
  2. status: true
  3. dependencies:
  4. module:
  5. - file
  6. - image
  7. - node
  8. id: node.field_%field_name%
  9. field_name: field_%field_name%
  10. entity_type: node
  11. type: image
  12. ...

The resulting Config Action rule looks like this:

  1. replace:
  2. "%field_name%": "my_image"
  3. "%content_type%": "my_gallery"
  4. actions:
  5. field_storage:
  6. # name of yml file in config/templates folder
  7. source: "field.storage.node.image.yml"
  8. dest: "field.storage.node.%field_name%"
  9. field_instance:
  10. source: "field.field.node.gallery.image.yml"
  11. dest: "field.field.node.%content_type%.%field_name%"
  12.  
  13. content_type:
  14. source: "node.type.gallery.yml"
  15. dest: "node.type.%content_type%"
  16.  
  17. view:
  18. source: "views.view.gallery.yml"
  19. dest: "views.view.%content_type%"
  20.  
  21. ...

Not only does Config Actions perform string replacements within the actual YAML configuration template files, but it also replaces these variables within the action rule itself, allowing you to specify a dynamic destination to save the config.

Enabling the above module will do the same thing as enabling the original Gallery feature, but instead of creating a “gallery” content type, it will create a “my_gallery” type, and instead of a “image” field it will create a “my_image” field, etc.

Reusing a Template

By itself, this isn’t much different from the original feature. The power comes from reusing this template in a different module.

In your “myclient” project, you can create a new custom module (myclient_gallery) that contains this simple Config Action file:

  1. replace:
  2. "%field_name%": "myclient_image"
  3. "%content_type%": "myclient_gallery"
  4. plugin: include
  5.  
  6. module: custom_gallery

This will cause Config Actions to include and execute the actions from the custom_gallery module created above, but will use the new string replacements to create a content type of “myclient_gallery” with a field of “myclient_image”.

The “custom_gallery” module we created above has become a reusable component, or template, that we can directly use in our own client projects. We can control the exact machine names being used, reuse fields that might already exist in our project, and customize the gallery however we need for our new client without needing to fork the original component code.

If our new client project makes improvements to the core gallery component, the patches to the custom_gallery template module can be submitted and merged, improving the component for future client projects.

Overriding Configuration

Running actions is similar to importing configuration or reverting a Feature: the action plugins manipulate the config data and save it to the active database store. Any additional imports or actions will overwrite the transformed config data. These are not “live” (runtime) overrides, like overriding config in your settings.php file in D7 or using the Config Override module in D8. The configuration stored in the database by Config Actions is the active config on the site, and is available to be edited and used in the Drupal UI just like any Feature or other imported config.

For example, here is a simple “override” action:

  1. source: node.type.article
  2. value:
  3. description: "My custom description of the article content type"
  4. help: "My custom help of the article content type"

When the destination is not specified, the source is used.  The “value” option provides new config data that is merged with any existing data. This action rule just changes the description and help text for the “article” content type. Simple and easy, no Feature needed.

Config Action Plugins

Plugins exist for changing config, deleting config, adding new data to config, and you can easily create your own plugins as needed.

The Source and Destination options also use plugins. Plugins exist for loading and saving config data from YAML files, from the active database store, or from simple arrays, and you can create your own plugins as needed.

For example, the above “override” action could be rewritten like this:

  1. source: [
  2. description: "My custom description of the article content type"
  3. help: "My custom help of the article content type"
  4. ]
  5. dest: node.type.article

This specifies the configuration data directly in the source array and is merged with the destination in the active database store.

Conclusion

Config Actions addresses many different use-cases for advanced configuration management, from templates to overrides. You can use it to collect all of your site help/description text into one place, or to create a library of reusable content components that you can use to easily build and audit your content model.  Developers will appreciate the easy API that allows configuration to be manipulated from code or via Drush commands. I look forward to seeing all the the different problems that people are able to solve using this module.

To learn more about Config Actions, read the extensive documentation, or come to my Birds of a Feather session at DrupalCon Baltimore to talk more about advanced configuration management topics.

 

Pattern Lab is many wonderful things: a style guide, a component inventory, a prototyping system, and the embodiment of a design philosophy, all wrapped inside a fundamentally simple tool – a static site generator. It has greatly improved Phase2’s approach to how we build, theme, and design websites. Let’s talk about what Pattern Lab is, how we use it in our process by integrating it into the theme of a CMS like Drupal or WordPress, and the resulting change in our development workflow from linear to parallel.

Note: We’ll be discussing this topic in our webinar on June 16th. Register here!

What is Pattern Lab?

Pattern Lab allows us to easily create modular pieces of HTML for styling & scripting. We call these modular pieces of HTML components – you may have already heard of the iconic atomsmolecules, and organisms. Pattern Lab provides an easy-to-use interface to navigate around this component inventory.

Pattern Lab also does much more: it fills the role of a style guide by showing us colors, fonts, and font sizes selected by the design process and demonstrates common UI elements like buttons, forms, and icons along with the code needed to use them. That part is important: it’s the distinction between “this is what we’re going to build” and “this is what has been built and here’s how to use it.” Pattern Lab provides a handbook to guide the rest of your complex CMS.

We can also prototype with Pattern Lab because it supports “partials.” Partials allow our components to contain other components, giving us modular components. This lets us reuse our work in different contexts by not repeating ourselves, ensuring consistency of our design across a wide set of pages and viewports, and reducing the number of bugs and visual inconsistencies experienced when each page contains unique design elements. It supports either low fidelity “gray-boxing” or high fidelity “it looks like the finished site” prototyping. You can see an example of this by looking at the “Templates” and “Pages” in Pattern Lab below.

To summarize, Pattern Lab is a style guide, a component inventory, and a prototyping environment where we can see our designs in the medium they are destined for: the browser! Now, let’s talk about the old way of doing things before we discuss how we implement this tool, and the difference the new way makes.

The Old Way

Generally speaking (and greatly simplifying), the old process involved several linear steps that effectively block subsequent steps: the goal of each step is to create a deliverable that is a required resource for the next step to start. The main point I want to make is that in order for the front-end developers to implement the designs they need HTML, so they have to wait for the back-end developer to implement the functionality that creates the HTML.

Front-end developers just need HTML. We don’t need the HTML required for the complex logic of a CMS in order to style it. We just need HTML to style and script so we can create our deliverables: the CSS & JavaScript.

To reiterate this point: front-end devs just need HTML, wherever it comes from.

Now that we’ve set the stage and shown the problem, let’s take a look at the way we implement Pattern Lab and how that helps improve this process.

Integrating Pattern Lab and the CMS Theme

Instead of keeping our Pattern Lab site (which contains our prototype and style guide) separate from the CMS, we keep them together. Pattern Lab is just a simple static site generator that takes HTML shorthand and turns it into HTML longhand. We just put the Pattern Lab folder inside the theme right here (for a Drupal site): /sites/all/themes/theme-name/pattern-lab/. Now it’s next to other fundamental assets like CSS, JavaScript, Images, and Fonts. Sharing these assets between Pattern Lab and our CMS is a huge step forward in improving our process.

Folder Structure

theme-name/ css/ style.css js/ script.js pattern-lab/ source/ # (HTML Shorthand) public/ # (HTML Longhand - a.k.a The Pattern Lab Site) templates/ *.tpl.php # (All our CMS template files)

1

2

3

4

5

6

7

8

9

10

theme-name/

css/

style.css

js/

script.js

pattern-lab/

source/ # (HTML Shorthand)

public/ # (HTML Longhand - a.k.a The Pattern Lab Site)

templates/

*.tpl.php # (All our CMS template files)

Sharing CSS & JS Assets

With Pattern Lab inside our CMS theme folder, all we really need to do to “integrate” these two is include this HTML tag in Pattern Lab to use the CSS that our CMS theme is using:

1

<link href="../../../../css/style.css" rel="stylesheet" media="all">

And then include this HTML tag to use the CMS theme’s JavaScript:

1

src="../../../../js/script.js">

How This Helps

All a web page needs is HTML for its content, CSS for styling that content, and JavaScript for any interaction behavior. We’ve now got two ways to make HTML: programming the CMS (which takes a lot of time) to be able to let non-technical content editors create and edit content that generates the HTML, or using Pattern Lab to write “HTML shorthand” much, much quicker. Both of those environments are linked to the same CSS and JavaScript, effectively sharing the styling and interaction behavior to both our CMS and Pattern Lab.

Now, most of the time we’re not working with our clients just to make style guides and prototypes; we’re making complex CMS platforms that scale in some really big ways. Why would we want to waste time creating the HTML twice? Well, sites this big take time to build right. Remember that the front-end developers are usually waiting for the back-end developers to program in the functionality of the CMS, which ends up creating the HTML, which the front-end developers style by writing CSS & JS.

All we need is some HTML to work with so we know our CSS and JS is working right. We don’t care if it’s editable to content editors at this point, we just want it to look like the comps! Now that front-end devs have an environment in Pattern Lab with real HTML to style and script, we can bring the comps to life in the browser with the added benefit of CSS & JS being immediately available to the CMS theme. We are effectively un-blocked, free to work outside the constraints of a back-end bottleneck. This shift from a linear process to one where back-end and front-end development can happen concurrently in a parallel process is a major step forward. Obvious benefits include speed, less re-work, clarity of progress, and a much earlier grasp on UI/UX issues.

The New Workflow

With our style guide sharing CSS & JS with our CMS theme, we can pull up Pattern Lab pages exposing every button – and every size and color button variation – and write the CSS needed to style these buttons, then open up our CMS and see all the buttons styled exactly the way we want. We can get an exhaustive list of each text field, select box, radio button and more to style and have the results again propagate across the CMS’s pages. Especially when armed with a knowledge of the HTML that our CMS will most likely output, we can style components even before their functionality exists in the CMS!

As the back-end functionality is programmed into the CMS, HTML classes used in the Pattern Lab prototype are simply applied to the generated HTML to trigger the styling. It doesn’t matter too much if back-end or front-end start on a component first, as this process works in either direction! In fact, design can even be part of the fun! As designers create static comps, the front-end devs implement them in Pattern Lab, creating the CSS available in the CMS as well. Then, the Pattern Lab site acts to the designers as a resource that contains the summation of all design decisions reflected in a realistic environment: the browser. The designers can get the most up-to-date version of components, like the header for their next comp, by simply screen shooting it and pulling it into their app of choice. This frees the designers from the minutia of ensuring consistent spacing and typography across all comps, allowing them to focus on the specific design problem they’re attempting to solve.

When designers, front-end developers, and back-end developers are iteratively working on a solution together, and each discipline contributes their wisdom, vision, and guidance to the others, a very clear picture of the best solution crystallizes and late surprises can often be avoided.

This parallel process brings many advantages:

  • Front-end can start earlier – often before a CMS and its environment is even ready!
  • Easy HTML changes = quick iteration.
  • Back-end has front-end reference guide for markup and classes desired.
  • Pattern Lab acts as an asset library for designers.
  • Project managers and stakeholders have an overview of progress on front-end components without being encumbered by missing functionality or lack of navigation in the CMS.
  • The progress of each discipline is immediately viewable to members of other disciplines. This prevents any one discipline from going down the wrong path too far, and it also allows the result of progress from each discipline to aid and inform the other disciplines.
  • Shared vocabulary of components and no more fractured vocabulary (is it the primary button or the main button?). Pattern Lab gives it a label and menu item. We can all finally know what a Media Block objectively is now.

Conclusion

By decoupling the creation of a design system based in CSS and JavaScript (styling) from the process of altering the HTML that our CMS is generating (theming), we’re able to remove the biggest blocker most projects experience: dependence on the CMS for CSS & JS to be written. We avoid this bottleneck by creating a nimble environment to build HTML that allows us to craft the delieverables of our design system: CSS & JS. We’re doing this in a way that provides these assets instantly to the CMS so the CMS can take advantage of them on the fly while the site is being built concurrently, iteratively, and collaboratively.

Helpful Links

DrupalCon 2017 may be over, but we’re still feeling the impact. Last week 20+ Phase2 team members and over 3,000 sponsors, attendees, and speakers converged on Baltimore for 5 days of Drupal.

In case you weren’t able to join us in person, here is a recap:

 

Impact At The Phase2 Booth

At this year’s conference, we focused on highlighting the impact digital technology, and specifically Drupal, has and can have on the world around us. We also drew attention to the fact that technology would be nothing without the incredible vision and talent of the people who fuel it.

Phase2’s booth was designed to showcase our event theme: “Vision + Technology: The Impact Is Infinite.”

We believe, and are energized by the fact, that digital technology allows one person to reach billions, with the simple stroke of a key.

And we know that the impact doesn’t end there...

When a vision is combined with technology, we have the power to set something into motion, the outcome of which is not entirely known. Actions build upon one another and inspire reactions, putting transformation entirely within reach - the impact of which is infinite.

We took our impact message and created a one-of-a-kind, interactive voting installation in the Phase2 booth. The voting station empowered DrupalCon attendees to come together and offer  their input by voting on important community issues.

DrupalCon attendees voted by completing the following sentences:

  • I want to live in a word where ______ doesn’t need an initiative, it’s just a given.

  • With _________, anything is impossible.

  • The impact of _______ is endless.

  • If we focused more on ________ what we can achieve is infinite.

With the words:

  • Privacy & Security

  • Accessibility

  • Community

  • Education

  • Diversity

Each vote deposited a corresponding color of sand in a plexiglass container. Voting data was displayed visually in real time as each person’s vote contributed to a unique piece of sand art.

 

The Results of the Vote

The final results are in and DrupalCon attendees voted to make an impact on “education”. In response to the vote, Phase2 will make a donation to The Digital Harbor Foundation, a local Baltimore youth tech education nonprofit. We were thrilled by the participation in our booth and inspired by the beauty of the final sand art and how it really was a great visual representation of  what we can achieve as a community!

 

 

Impacting the Drupal Thought Leadership

Phase2 was represented in six DrupalCon sessions and we were excited to invite some amazing clients on stage with us, including Pinterest, Turner (NBA), Score and Weight Watchers. Here’s the full session lineup - feel free to check out the video of each session:
 

One great Phase2 moment involved our Director of Engineering, Tobby Hagler, and his Dungeons & Dragons themed session. As a major D&D fan, Tobby has submitted this talk to DrupalCon multiple times over the years, and this year it was finally accepted! To commemorate his perseverance and the awesome subject matter we created a D&D themed t-shirt that everyone from Phase2 wore in support.

 

Caitlin Loos and Chris Bloom spoke on the success of Phase2’s BuilDesign Internship Program and offered some insightful strategic and tactical advice to agencies that are looking to build their own junior talent program. Watch the session here.  

 

 

The Impact is Infinite

We’re back from DrupalCon Baltimore exhausted, but exhilarated by the creativity and talent of the Drupal Community. We are reminded of the impact our collective talents can have on our lives and the world around us. It was an amazing week with team members, partners, clients and friends and we’re already looking forward to DrupalCon next year!

 

 

 

Goal: Getting PHP Sessions into Redis

One of several performance-related goals for NBA.com was to get the production database to a read-only state. This included moving cache, the Dependency Injection container, and the key-value database table to Redis.  99% of all sessions were for logged-in users, which use a separate, internal instance of Drupal; but there are edge cases where anonymous users can still trigger a PHP session that gets saved to the database.

For all it’s cool integrations with Symfony and its attempts at making everything pluggable or extendable, PHP session handling in Drupal 8 is still somewhat lacking. Drupal 8 core extends Symfony’s session handling in a way that makes a lot of assumptions, including one that developers won’t want to use any other native session handler, such as the file system or a key/value store like Redis or Memcached.

Session Handlers in Symfony and Drupal

PHP has some native session handling that’s baked in, and for basic PHP applications in simple environments, this is fine. Generally speaking, it works by storing session data in files in a temporary location on the host machine and setting a cookie header so that subsequent HTTP requests can reference the same session. However, since the default behavior doesn’t scale for everyone or meet every project’s needs, PHP offers the ability to easily swap out native session handlers. One can even create a user-defined session handler, thanks to PHP 5’s SessionHandler class.

The SessionHandler class defines some basic methods to allow a developer to create, destroy, and write session data. This class can be extended, and then ini_set('session.save_handler', TYPE) (where “TYPE” can be any of the known save handers, such as “file” or “pdo”) and ini_set('session.save_handler', PATH) (where “PATH” can be any writeable file system path or stream) can be used to tell PHP to use this extended class for handling sessions. In essence, this is what Symfony does, by extending this into a collection of NativeSessionHandler classes. This allows Symfony developers to easily choose PDO, file, or even memcached session storage by defining session handler methods for each storage mechanism.

Symfony-based applications can normally just choose which PHP session handling is desired through simple configuration. This is well-documented at Symfony Session Management and Configuring Sessions and Save Handlers. It’s even possible to create custom session handlers by extending the NativeSessionHandler, and using ini_set() inside the class’ constructor. There is no default Redis session handler in Symfony, but there are plenty of examples out there on the Internet, such as http://athlan.pl/symfony2-redis-session-handler/

Drupal 8 extends this even further with its own SessionManager class. This SessionManager class is a custom NativeSessionHandler (PHP allows “user” as one of the session.save_handler types). As part of the SessionManager class, several optimizations have been carried over from Drupal 7, including session migration and a few other things to prevent anonymous users from saving an empty session to the database. Because of these optimizations, however, we don’t want to simply ignore this class; however, the NativeSessionHandler service has the database connection injected into it as a dependency. This means future attempts to simply extend Drupal’s NativeSessionHandler service class will result in vestigial dependency injection.

Implementation

Now that we understand a little more about the underpinnings of session handling in PHP, Symfony, and Drupal 8, I needed to determine how to tell Drupal to use Redis for full session management. Several important goals included:

  • Keep all of Drupal 7 and 8’s optimizations made to session handling (which originated in Pressflow).

  • Don’t patch anything; leave Drupal core as intact as possible, but not rely on the core behavior of using the database for session storage.

  • Leverage the Redis module for connection configuration and API.

Just Override the Core Session Service?

One option that was considered was to simply override the Drupal core service. In core.services.yml the session_manager service is defined as using the Drupal\Core\Session\SessionManager class. In theory, a simple way to change Drupal’s database-oriented session handling would be to just replace the class. In this way, we would simply pretend the SessionManager class didn’t exist, and we would be able to use our CustomRedisSessionManager class, which we would write from scratch.

However, there are a few flaws in this plan:

  • We would have to reimplement all session handler methods, even if nothing differed from Drupal’s core class methods, such as session_destroy().

  • If Drupal core changed to include new or modified session handling, we would likely have to reimplement these changes in our custom code. Being off of the upgrade path or not being included in any future security fixes would be a Bad Thing™.

For more information about the proper way to override a code service in Drupal 8, see https://www.drupal.org/node/2306083

Enter: Service Decoration

For the purpose of this blog post, I will briefly introduce service decorators; but for a more general, in-depth look, a good resource to learn about Service Decorators is Mike Potter’s blog post, Using Symfony Service Decorators in Drupal 8. This is what I used as the basis for my decision to decorate the existing core session_handler service rather than overriding it or extending it.

What is a Service Decorator?

Service decoration is a common pattern in OOP that lets developers separate the modification of a service or class from the thing they’re modifying. In a simple way, we can think of a service decorator as a diff to an existing class. It’s a way to say, “hey, still use that other service, but filter my changes on top of it.”

Decorating the Session Manager Service

Symfony paves the way for services in Drupal 8, and carries with it several other design patterns, including service decorators. To decorate an existing service, you simply define a new service, and use the `decorates` key in your `MODULE.service.yml` file.

For the Redis Sessions module, here is `redis_sessions.service.yml`:

  1. services:
  2. # Decorate the core session_manager service to use our extended class.
  3. redis_sessions.session_manager:
  4. class: Drupal\redis_sessions\RedisSessionsSessionManager
  5. decorates: session_manager
  6. decoration_priority: -10
  7. arguments: ['@redis_sessions.session_manager.inner',
  8. '@request_stack', '@database', '@session_manager.metadata_bag',
  9. '@session_configuration', '@session_handler']

The `decorates` key tells Symfony and Drupal that we don’t want use this as a separate service; instead, continue to use the core session_manager service, and decorate it with our own class. The `decoration_priority` simply adds weight (or negative weight, in this case) to tell Drupal to use our service above other services that also might try and decorate or override the session_manager class.

The `arguments` key injects the same dependencies as well as the original session_manager service as a sort of top-level argument. In this way, we can still use the session_manager as the service that handles PHP sessions, and it will have all of its necessary dependencies injected into it directly by our service class. This will also inject that service into our class in case we need to reference any session_manager methods, and treat them as a _parent class method.

For the same module, here is the `RedisSessionsSessionManager.php` class constructor:

  1. public function __construct(SessionManager $session_manager,
  2. RequestStack $request_stack, Connection $connection, MetadataBag
  3. $metadata_bag, SessionConfigurationInterface $session_configuration,
  4. $handler = NULL) {
  5. $this->innerService = $session_manager;
  6. parent::__construct($request_stack, $connection, $metadata_bag,
  7. $session_configuration, $handler);
  8.  
  9. $save_path = $this->getSavePath();
  10. if (ClientFactory::hasClient()) {
  11. if (!empty($save_path)) {
  12. ini_set('session.save_path', $save_path);
  13. ini_set('session.save_handler', 'redis');
  14. $this->redis = ClientFactory::getClient();
  15. }
  16. else {
  17. throw new \Exception("Redis Sessions has not been configured. See
  18. 'CONFIGURATION' in README.md in the redis_sessions module for instructions.");
  19. }
  20. }
  21. else {
  22. throw new \Exception("Redis client is not found. Is Redis module
  23. enabled and configured?");
  24. }
  25. }

In RedisSessionsSessionManager.php, we define the `RedisSessionsSessionManager` class, which will decoration Drupal core’s `SessionManager` class. Two things to note in our constructor is that:

  1. We set $this->innerService = $session_manager; to be able to reference the core session_manager service as an inner service.

  2. We check that the module has the necessary connection configuration to a Redis instance, and if so, we’ll use ini_set to tell PHP to use our Redis-based `session.save_path` and `session.save_handler` settings.

Everything Else is Simple

In our RedisSessionsSessionManager class, there’s just a few things we want to change from the core SessionManager class. Namely, these will be some Drupal-specific optimizations to keep anonymous users from creating PHP sessions that will be written to Redis (originally, the database), and session migration for users that have successfully logged in (and may have some valuable session data worth keeping).

We also have to some extra things to make using Redis as a session handler easier. There are a few new methods that Redis Sessions will use to make looking up session data easier. Since Redis is essentially just a memory-based key-value store, we can’t easily look up session data by a Drupal user’s ID. Well, we can, but it’s an expensive operation, and that would negate the performance benefits of storing session data in Redis instead of the database.

With these custom methods aside, everything else just relies on PHP’s native session handling. We’ve told PHP to use the base Redis PHP class as the handler, which is just part of having Redis support compiled in PHP. We’ve told PHP where to save the session data; in this case, a TCP stream to our redis instance configured for the Redis module.

Bonus

As of the writing of this blog post, I’ve begun the process of releasing Redis Sessions as a submodule of the Redis module. This can help serve as both a practical example of creating a service decorator as well as helping high-traffic sites that also wish to serve content from a read-only database. For those that would like to help test the module, here is the patch to add Redis Sessions submodule to the Redis module.

Want to read more about Drupal 8 architecture solutions and how to evaluate each solution based on your business objectives? Download our whitepaper here

 

Columbia University is taking proactive steps to ensure its predominantly Drupal-based digital properties are offering the best possible experience to site visitors. Using Acquia’s Lightning distribution as a base, the CUIT team has begun to roll out a new platform on Drupal 8.

Columbia University Information Technology (CUIT) provides Columbia students, faculty, and staff with central computing and communications services. I caught up with Ian Mieville, Director of Web Services at Columbia University, to talk about how Columbia uses Drupal to support the university’s web services -- and how Drupal 8 is improving those services.

 

How does CUIT support Columbia University?

CUIT is the centralized IT department for Columbia University. We’re in charge of the university’s security and asset management, technology infrastructure, enterprise systems, as well as custom development and application work. We develop, support, and host about 300+ websites and web applications, which are all almost exclusively on the Drupal framework.

 

What were your goals for Columbia University’s new Drupal 8 platform?

The first goal was to synchronize the user experience of most CU sites. We discovered a real inconsistency of experience site-to-site -- not only with regards to design, but also usability. Users had to constantly reorient themselves every time they went to a new CU site, even if it was related to the one they just left.

So we aimed to create a standard UX where key components (search, events, news, people directories, course directories, etc.) were consistent with a single usable pattern and design. This would allow site maintainers to focus on what’s really important to them (content and information), without worrying about the technical details of digital property management. As an incentive to adopt the new standard model, we’d make this service available for free to our CU clients.

On the back-end, we found it highly inefficient to keep recreating the wheel every time we launched a new site. So our second goal was to standardize things like content types and integration patterns, and provision a single code base. This would mean our time at CUIT could be better spent doing more complex work.

 

What was your strategy to accomplish these goals?

In conjunction with our partners, we decided to develop three models of a distribution, to serve as blueprints for standardization.

The first was the Research Model, designed for use by Columbia’s labs and research institutes. The blueprint design focused on research projects, peer-reviewed journal publications, and the people running and working in the labs. It’s meant to give faculty members a platform for publishing their research, in addition to marketing to post-doc applicants.

Second, the Administrative Model will support departments like HR, Finance, and the International Student and Scholars Group. As an administrative unit, these departments exist to offer some service to Columbia’s community, so the model for their sites will give them a way to forefront popular services and organize them by personas, so as to better serve the target audience.

Finally, the Academic Model allows academic departments to showcase their course selection, faculty members, research initiatives, etc. It is formatted to be both a recruiting and informational tool for prospective and current students. This model is still being developed at the moment.

 

You designed these models on Drupal 8, using Acquia’s Lightning distribution as a base. Why Lightning?

We chose Lightning because it fit into what we were thinking already. As a distribution, it is well-suited for site maintainers and people who manage content. From the back-end, it had the tools to support that use case. And because it’s supported by Acquia, we knew we’d get timely updates. Most importantly, it was a recommendation from Phase2 Software Architect Mike Potter, who worked on this project with us early on.

 

What do other universities stand to gain from using Drupal 8/Lightning?

There’s a lot to gain from Lightning specifically and Drupal 8 in general. Drupal 8 makes it easier for us to control functionality and integration points, and support Columbia digital properties as a product and a platform.

That being said, we had a very good understanding of what Drupal 8 was offering and what we could do within those parameters. So do your research. There are a lot of contributed modules that still aren’t over to Drupal 8 yet. Choosing Drupal 8 should depend on what you want to do, and your development team’s ability to support customizations and write custom modules.

 

Any other advice for universities investing in digital transformation?

Your digital strategy depends on how centralized the university is. Columbia is very decentralized digitally, but other universities may have a central CMS where every department hangs off that main site -- I can’t speak to that.

Having said that, you should partner with those people on the other side of the IT site, ie your public affairs group. In doing that, we were able to present a more uniform front. It also makes it easier to convince departments to adopt the standard, as it’s a direct recommendation for the central administration.

With Drupal 8, there’s a little bit of a learning curve. Here at CU, we separate our front-end and back-end developers, so each of those teams learned those functions in Drupal for us. My recommendation is, if at all possible, to dedicate team members to different pieces of the Drupal ecosystem to ensure a high level of expertise in both front-end and back-end.

 

Why did you select Phase2 as a technology partner?

I previously worked with Phase2 (several times!) when I was at the College Board. When we started initiating this project at Columbia, we needed a certain level of expertise in Drupal, which I knew from experience Phase2 had. We also had other ongoing IT work, so having support from Phase2 allowed our team not to be overrun with the platform design.

It was all very seemless; we were happy to work with Chauncey, Daniel, and Mike on the project. They were really great developers and added a lot of value to the overall project.

Thanks for taking the time to chat, Ian!

I’m afraid of the Webform module's issue queue. I see the Webform 8,x-5.x module's usage stats growing and with it, duplicate bug reports are increasing. The webform_update_8025() update hook is going to haunt me for months. Now I’m afraid to write any update hook that touches an existing field definition. I’ve realized that it is time to push back on the Webform module's issue queue before it’s too late.

Hear me out: I’m not looking for a fight - just a solution to a very simple problem. People don't know how to write proper bug reports and feature requests, and they don't like to read the issue queue handbook. The solution could be equally simple, which would be to require them write good tickets.

Plenty of documentation and videos about writing good issues exist. My goal is to make it easier for people to write complete and useful tickets so I can better assist them.

Help us Help you

For now, I have three goals for improving the Webform issue queue process:

  • Provide easy-to-use bug and features templates.
  • Encourage users to employ these bug and feature templates.
  • Show users how to create a good issue.

Provide bug and feature templates

GitHub allows a maintainer to create an issue template and pull request for their repository. I have decided to do the same thing for the Webform module. Drupal.org does not really support issue templates, however I can recommend that people use them by prepopulating the issues' body field

Prepopulate the "Create...Read More

Cog, introduced in a previous post, was built as a toolset for satisfying the needs of enterprise clients by Acquia's Professional Service Front-end Team. It's used as a basic starting point for a new project and includes tools for reinforcing front-end best practices. In this blog post we will introduce you to some of the tools included in Cog.

Tags: acquia drupal planet

Pages