Oct 25 2018
Oct 25

Hello everyone and welcome to another Daily Dose of Drupal, today we are on episode #210. Wow, it's been over three years since I last posted a video, and a lot of things have changed over the last three years, but a lot of things have stayed the same too... after all, you can still follow me on Twitter at smthomas3.

So I'm going to keep this episode short and sweet, but I do have some big news. I'm going to start posting Drupal 8 content, a lot of it. I've been stuck in the Drupal 7 world for a long time, and I just really haven't got the time to put out any new Drupal 8 content. But that's all going to change. So I am going to start posting Drupal 8 content on an almost daily basis going forward. I'm really going to keep doing it until I run out of things to say, and I do have a tendency to ramble on... so we might be here awhile.

So the next big announcement is that everything on CodeKarate.com going forward, and all the stuff I did in the past is all going to be free. Yep, you heard it here first! Just head on over to CodeKarate.com, enter your email, and you will get access to all my ebooks, all the stuff you used to have to pay for. Really I just got to the point where I didn't want to have to save my "best stuff" behind a paywall. I thought it would be better to just post all my best stuff on YouTube and on my website for free. Now what I am asking is if you do find value in what I am posting, head on over to my Patreon page. If you can afford a few dollars a month, it's going to help me to keep posting more and more of this Drupal 8 content. We all know when you get started with Drupal, it can be a little bit intimidating, it can be a lot to learn.

The goal here with Code Karate and the Daily Dose of Drupal is to put out as much Drupal 8 content as possible and try to organize it in a way that someone just getting started with Drupal can understand. So the goal is to keep it free, if you do find value please head over to the Patreon page and maybe just throw in a couple dollars a month, that would be awesome. Also, if you do that, there is a chance you can get a sticker, you can get your own Code Karate t-shirt, and some other cool things for helping me out that you can get by heading over to the Patreon page.

So with this first video, I wanted to mention those few things, but I also wanted to get the discussion going. What are you struggling with in Drupal 8. What's the content or videos that you want to see produced. The goal here is that I'm going to start with doing what I have done a lot in the past which is post videos on Modules and how to use them. But I also want to get into more in-depth topics such as Module development, site building, configuration management, building out Drupal API's to use with either Javascript frameworks or mobile apps, theme building, theme development, any of those types of difficult and in-depth concepts I want to get into that first. I am going to start with the modules and then lead into some of that.

But if you have things with you are struggling with or you would like to see, let me know and hopefuly I can get some feedback from everyone then prioritize what the community in general is really having trouble with. Thanks for checking out Code Karate, thanks for watching this video, and go ahead and buckle your seatbelt because Code Karate is back. We'll see you next time.

Oct 25 2018
Oct 25

Audi’s implementation of Continuous Delivery into its marketing has had an astronomical impact on its competitive advantage. For instance, when Audi released its new A3 model along with all other new releases, it wanted to communicate the new features, convey the options, and assist people in understanding the differences among body types, engines and things like that. Continuous Delivery turned out to be the definitive solution. It helped in refining the messaging and optimising it on the fly to make sure that the people are understanding what the automaker is trying to communicate.

vehicles on a cargo ship with wake of the ship in the background

Continuous Delivery (CD) is a quintessential methodology which makes the management and delivery of projects in big enterprises like Audi more efficient. When it comes to Drupal-based projects, Continuous Delivery can bring efficacy to the governance of projects. It can lead to better team collaboration and on-demand software delivery.

Read more on Continous Integration with Drupal

Building and Deploying using Continuous Delivery

A graphical representation showing white parabolic curves on a blue graph and text on itSource: Atlassian

For many organisations, shipping takes a colossal amount of effort. If your team is still living with manual testing preparing for releases and manual or semi-scripted deploys for carrying out releases, it can be toilsome. No wonder software development is moving towards continuity. In the continuous paradigm, quality products are released in a frequent and predictable manner to the customers thereby reducing the risk factor.

In 2010, Jez Humble and David Farley released a book called Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.

In this book, they argued that “software that’s been successfully integrated into a mainline code stream still isn’t a software that’s out in production doing its job”. That is, no matter how fast you assemble your product, it does not really matter if it is just going to be stored in a warehouse for months.

Continuous Delivery is the software development practice for building software in such a way that it can be released to production at any time.

Continuous Delivery refers to the software development practice for building software in such a way that it can be released to production at any time. So, if your software is deployable throughout its lifecycle, you are doing Continuous Delivery. In this, the team gives more priority to keeping the software deployable than working on new features. This ensures that anybody can get quick and automated feedback on the production readiness of their systems whenever alterations are done. 

Thus, Continuous Delivery enables push-button deployments of any software version to any environment on demand.

How does Continuously Delivery work?

Flowchart showing box and circles to illustrate the workflow of continuous delivery, continuous integration, and continuous deploymentSource: Amazon Web Services

For achieving Continuous Delivery, you need to continuously integrate the software built by the development team, build executables and run automated tests on those executables for detecting problems.

Then, the executables are required to be pushed into increasingly production-like environments to make sure that the software is in working condition when pushed to production. This is done by implementing a deployment pipeline that provides visibility into the production readiness of your applications. It gives feedback on every alteration to your system and allows team members to perform self-service deployments into their environments.

Continuous Delivery requires a close, collaborative working relationship between the team members which is often referred to as DevOps Culture. It also needs extensive automation of all possible parts of the delivery process using a deployment pipeline.

Continuous Delivery vs Continuous Integration vs Continuous Deployment

Continuous Delivery is often confused with Continuous Deployment.

In Continuous Deployment, every alteration goes through the pipeline and are automatically pushed into production which results in many production deployments every day.

In Continuous Delivery, you are able to do frequent deployment and if the certain businesses demand a slower rate of deployment, you may choose not to perform the frequent deployment. So, for performing Continuous Deployment, you must be doing Continuous Delivery.

Continuous Delivery builds on Continuous Integration and deals with the final stages that are required for production deployment.

So, where does Continuous Integration come into the picture? It allows you to integrate, build, and test code within the development environment. Continuous Delivery builds on this and deals with the final stages that are required for production deployment.

Benefits of Continuous Delivery

The major benefits of Continuous Delivery are:

  • Minimised Risk: As you are deploying smaller alterations, there’s reduced deployment risk and it is easier to fix whenever a problem occurs.
  • Trackable progress: By tracking work done, you can get a believable progress. If developers declaring a work to be “done”, it is less believable. But if it is deployed into a production environment, you actually see the progress right there.
  • Rapid feedback: One of the pivotal challenges of any software development is that you can wind up building something that is not useful. So, earlier you get the working software in front of real users with higher frequency, faster you get the feedback for finding out how valuable it really is.

Continuous Delivery with Drupal

Drupal Community has been a great catalyst for digital innovation. To make software development and deployment better with Drupal, the community has always leveraged technological innovations.

[embedded content]

A session held at DrupalCon Amsterdam had an objective of bringing enterprise Continuous Delivery practices to Drupal with a comprehensive walkthrough of open-sourced CD platform called ‘Go’. The ‘Go’ project started off as ‘Cruise Control’ in 2001 rooted in the first principle of the Agile Manifesto: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

It outlined principles of CD practice, exhibited how easy it is to get a Drupal build up and running in Go and illustrated the merits of delivering in a pipeline. It involved setting up of a delivery pipeline. Then, configuring of build materials, build stages, build artefacts, jobs and tasks were done. Furthermore, it drilled down to familiar Drush commands and implemented the basic principles of the CD.

Basically, the build configuration was shown that deploys Drupal sites using Phing, Drush and other tools with the possibility of calling out to Jenkins as another way for managing tasks. Multiple steps of testing and approval were shown with a separate path for content staging as separate from code thereby deploying a complex Drupal site.

Homepage of Go platform with a flowchart explaining Continuous Delivery practice and ‘Simplify Continuous Delivery’ written in bold letters on the top on a pink background

Later, it emphasised on testing and previewing on production before cutting over a release, zero downtime releases, secure and simple rollback options, and making the release a business decision rather than a technical decision.

Moreover, it showed that Go’s trusted artefacts can take the ambiguities out fo the build with spectacular support for administering dependencies between different projects.

This session is very useful for the developers who use Drush and have some understanding of DevOps and knows about all-in-code delivery. Even those who undertake less technical roles like QA(Quality Assurance), BA(Business Analyst) and product owner will find it beneficial as the CD practice is all about the interaction of the team as well as the tools and techniques. 

How the future of continuous delivery looks like?

A report on Markets and Markets stated that the Continuous Delivery Market was valued at USD 1.44 Billion in 2017 and would reach USD 3.85 Billion by 2023 at a Compound Annual Growth Rate (CAGR) of 18.5% during the forecast period of 2018-2023.

Open source Continuous Deliver projects and tools will dominate the commercial CD tools segment
Bar graphs in dark blue and light blue colours showing automation market size in USD Billion, by segment, global, 2016-2020

Another report on Mordor Intelligence states that the market for Continuous Delivery is seeing a tremendous rise. It is due to the adoption of Artificial Intelligence (AI) and Machine Learning, rapid deployment of connected infrastructure and the proliferation of automated digital devices. But open source CD projects and tools will dominate the commercial CD tools segment.

The North American region is projected to have the largest growth in demand during the forecast period (2028-2023) because of the early adoption of cloud computing and IoT by the United States. The continuous evolution of new technologies (as shown above) have been the prime factor behind large-scale investments in the CD segment. Retail, healthcare, communications and manufacturing application in North America are going to see a massive growth rate in the forecast period.


On-demand software delivery and enhanced team collaboration is a sort of combination that every major enterprise can benefit from. Continuous Delivery is one such mechanism that can help software development projects to be production-ready always. And this can work in favour of projects involving Drupal development and deployment.

Opensense Labs has been steadfast in its goals of offering marvellous digital experience with its suite of services.

Contact us at [email protected] to know how can continuous delivery be implemented for your business in Drupal-based projects.

Oct 25 2018
Oct 25

Mateu, Gabe and I just released the first RC of JSON API 2, so time for an update!

It’s been three months since the previous “state of JSON API” blog post, where we explained why JSON API didn’t get into Drupal 8.6 core.

What happened since then? In a nutshell:

  • We’re now much closer to getting JSON API into Drupal core!
  • JSON API 2.0-beta1, 2.0-beta2 and 2.0-rc1 were released
  • Those three releases span 84 fixed issues. (Not counting support requests.)
  • includes are now 3 times faster, 4xx responses are now cached!
  • Fixed all spec compliance issues mentioned previously
  • Zero known bugs (the only two open bugs are core bugs)
  • Only 10 remaining tasks (most of which are for test coverage in obscure cases)
  • ~75% of the open issues are feature requests!
  • ~200 sites using the beta!
  • Also new: JSON API Extras 2.10, works with JSON API 1.x & 2.x!
  • Two important features are >80% done: file uploads & revisions (they will ship in a release after 2.0)

So … now is the time to update to 2.0-RC1!

JSON API spec v1.1

We’ve also helped shape the upcoming 1.1 update to the JSON API spec, which we especially care about because it allows a JSON API server to use “profiles” to communicate support for capabilities outside the scope of the spec.


Now that we’ve reached a major milestone, I thought it’d be interesting to do a small retrospective using the project page’s sparklines:

JSON API project statistics, annotated with green vertical lines for the start of 2018 and the time of the previous blog post. The first green line indicates the start of 2018. Long-time Drupal & JSON API contributor Gabe Sullice joined Acquia’s Office of the CTO two weeks before 2018 started. He was hired specifically to help push forward the API-First initiative. Upon joining, he immediately started contributing to the JSON API module, and I joined him shortly thereafter. (Yes, Acquia is putting its money where its mouth is.)
The response rate for this module has always been very good, thanks to original maintainer Mateu “e0ipso” Aguiló Bosch working on it quite a lot in his sparse free time. (And some company time — thanks Lullabot!) But there’s of course a limit to how much of your free time you can contribute to open source.

  • The primary objective for Gabe and I for most of 2018 has been to get JSON API ready to move into Drupal core. We scrutinized every area of the existing JSON API module, filed lots of issues, minimized the API surface, maximized spec compliance (hence also minimizing Drupalisms), minimized potential for regressions to occur, and so on. This explains the significantly elevated rate of the new issues sparkline. It also explains why the open bugs sparkline first increased.
  • This being our primary objective also explains the response rate sparkline being at 100% nearly continously. It also explains the plummeted average first response time: it went from days to hours! This surely benefited the sites using JSON API: bug fixes happened much faster.
  • By the end of June, we managed to make the 1.x branch maximally stable and mature in the 1.22 release (shortly before the second green vertical line) — hence the “open bugs” sparkline decreased). The remaining problems required BC breaks — usually minor ones, but BC breaks nonetheless! The version of JSON API that ends up in core needs to be as future proof as possible: BC breaks are not acceptable in core. Hence the need for a 2.x branch.

Surely the increased development rate has helped JSON API reached a strong level of stability and maturity faster, and I believe this is also reflected in its adoption: a 50–70 percent increase since the end of 2017!

From 1 to 3 maintainers

This was the first time I’ve worked so closely and so actively on a small codebase in an open-source setting. I’ve learned some things.

Some of you might understandably think that Gabe and I steamrolled this module. But Mateu is still very actively involved, and every significant change still requires his blessing. Funded contributions have accelerated this module’s development, but neither Acquia nor Lullabot ever put any pressure on how it should evolve. It’s always been the module maintainers, through debate (and sometimes heartfelt concessions), who have moved this module forward.

The “participants” sparkline being at a slightly higher level than before (with more consistency!) speaks for itself. Probably more importantly: if you’re wondering how the original maintainer Mateu feels about this, I’ll be perfectly honest: it’s been frustrating at times for him — but so it’s been for Gabe and I — for everybody! Differences in availability, opinion, priorities (and private life circumstances!) all have effects. When we disagree, we meet face to face to chat about it openly.

In the end I still think it’s worth it though: Mateu has deeper ties to concrete complex projects, I have deeper ties to Drupal core requirements, and Gabe sits in between those extremes. Our discussions and disagreements force us to build consensus, which makes for a better, more balanced end result! And that’s what open source is all about: meeting the needs of more people better :)

API-first Drupal with multiple consumers @DrupalConNA :D pic.twitter.com/GhgY8O5SSa

— Gábor Hojtsy (@gaborhojtsy) April 11, 2018

Thanks to Mateu & Gabe for their feedback while writing this!

Oct 25 2018
Oct 25

The Drupal community is relentlessly working towards achieving the goal of easy usability with each version. 

Not only has Drupal granted its users the ability to integrate futuristic technologies but also provided the marketers with compelling digital solutions. 

On September 5, 2018, Drupal 8.6 was released. And started the wave of enthusiasm and whispers among the stakeholders. 

A road in the background and a sign board with drupal 8.6 ahead signboard

Here's how much it has succeeded in living up to the expectations and what is to be expected from Drupal 8.7 release due in January 2019.

Drupal 8.6 is released. And this what you should be excited about! 

The Drupal core team releases new (minor) versions every six months. These contain bug fixes, security patches, or both.

  • Drupal Installation is Boring. Not Anymore. 

That’s true. My first experience was as blank as the fresh installed Drupal 8.3. “What am I supposed to do with this?”, I thought. 

WordPress, on the other hand, had something to fiddle with, at least. 

Version 8.6 brings with it Umami

A demo food magazine website to demonstrate features of Drupal core, Umami gives you dummy content to explore the CMS. Although released with 8.5, Umami is now part of the core under the out-of-the-box initiative. 

desktop version of a website with photos of food and cutlery

The goal is to add sample content presented in a well-designed theme, displayed as a food magazine. 

Using recipes and feature articles this will make Drupal look much better right from the start and help evaluators explore core Drupal concepts like content types, fields, blocks, views, taxonomy, quite easily. 

Upgrade to Drupal 8 with Complete Migration Guide

“This minor release provides new improvements and functionality without breaking backward compatibility (BC) for public APIs.”

  • Migrate With Ease

While not all Migration challenges are covered. Here are two of the important migration challenges addressed. 

  1. Backward compatibility
  2. ID Conflict with Node translation

You can read more about Drupal 8 migration challenges

When launched, Drupal 8 didn’t provide any sort of backward compatibility in modules and hence they were to be rebuilt in Drupal 8. 

However, this is solved with version 8.6. In fact, this is the first release of Drupal 8 to offer a fully supported migration path from Drupal 7. Several changes were needed to Migrate APIs to make this possible.

The most important migration module - Migrate - is not only, stable but adds up the ability to re-run migrations to pick up new content that was not available previously.

Another conflict with the multilingual website related to conflicting Node ids. Translations in Drupal 8 are stored in a completely different way than in Drupal 7 and Drupal 6. 

When migrating node data from Drupal 6/7 to Drupal 8, a lot of data would point to things that no longer existed.

The Drupal Release Cycle

Starting with Drupal 8.0.0, Drupal core releases moved to a new release cycle schedule, and begin using the semantic versioning numbering system. 

A release Window is decided for the site administrators (in advance) to look up for the days for a possible bug fix, security release, and minor feature releases. 

For any change in release date, a public service announcement is issued before the release.

First Wednesday of every month is fixed for    Bugfix release window for Drupal 8.5.x and 7.x
Third Wednesday of every month is fixed for security release window for Drupal 8.5.x and 7.x

  • Improved Editorial UI with Media Library

As an editor, you always want a seamless experience when editing. Be it with browsing blogs, or media that has been uploaded to the website.

The Media Library provides a views-based browser for previously uploaded media. 

With the new version, you can add media to content via a media field, either by selecting from existing media or by uploading new media (including basic bulk upload support).

  • Building a Custom Layout is a No-Brainer Anymore

Choosing a custom layout no more requires you to write down long lists of codes. But this is not the only thing that makes layout interesting. The layout feature applies to much more than just content types. 

seven blocks arranged

Which implies that it can be used for media, contact forms, taxonomy, users, and more. 

Layouts allow you to build one of the individual fieldable entities which are completely customizable.

As a marketer, it won’t take much time for you to implement new ideas into a landing page. No more do you require adding contrib modules like Display Suits or Stacks for the job. 

The Layout helps to create one or more page sections and to choose from predefined options within them.

Seeing all the different issues and contributors in the release notes is a good reminder that many small contributions add up to big results. 

Drupal 8.7 - The Roadmap

  1. Streamlined bulk-upload form - An improved media bulk upload experience which exposes all fields on a single form.
  2. Media Metadata improvements - A simple and intuitive tool to configure the metadata-to-drupal-fields mappings on media entities.
  3. Faster Upload - Drupal 8 will officially support PHP 7 and drop support for PHP 5.5 and 5.6 with 8.7 release. PHP 7 is much lighter and faster than its previous versions, which means your site becomes quicker to load. 
  4. Bring migrate_source_csv to the core - The imported content remains in the CSV files and there is a code to read it and create the relevant entries. Having migrate_source_csv in core would allow the developers to remove that code and use migrate instead. This is important because the contenta CMS uses this for migrations.
  5. WYSIWYG integration - Ability to embed media into the content from the WYSIWYG editor. This will allow content creators to select from media library or create one by uploading an image without requiring any new APIs. 
  6. Editorial workflow config moving from content_moderation into a standard profile. This would help in smoother content staging. 

Drupal 8 to Drupal 9 Upgrade. What to Expect?

Over time, maintenance of backward compatibility would become more intricate. Thus, the point will be reached when too much of deprecated code is there in Drupal 8. At that time, deprecated systems will be removed and released as Drupal 9.

So, Drupal 9.0 should be almost similar to the last release of Drupal 8 excluding the deprecated code. Upgrading from Drupal’s latest version to Drupal 9.0.0 should be as streamlined as the upgrading of minor versions of Drupal 8 (eg. Drupal 8.5 to Drupal 8.6). Therefore, Drupal 9 offers a clean slate to innovate more swiftly.

Here’s What Content Editors Want...

Let me be a little selfish here. Yes, Drupal 8.6 looks really good to me and I look forward to working around that editor soon (because that is what concerns me, directly).  

As a content editor, I have numerous times faced issues which leave me frustrated. 

Improved media bulk upload, smart alt texts for code snippets, and meta information is something I actually look forward to. 

Uploading video (non-youtube content) can sometimes be a headache. 

There is still scope for major improvements to Drupal’s content workflow, preview and staging capabilities. It will be done by improving aspects of the Entity API in the core.

Future Important Dates

8.7.0 Feature Freeze: January 2019
8.7.0 Release: March 19, 2019

With all the mentioned features, I believe, the community is successful in making Drupal more intuitive and easy to use.  We provide upgrade assistance, connect with us, drop a mail at [email protected] for a faster upgrade. 

Oct 25 2018
Oct 25

Last week we organised a Drupal meetup in Maribor (the second largest town in Slovenia, where Agiledrop has the second office) in cooperation with Student Council of Faculty of Electrical Engineering and Computer Science in Maribor. As a member of Drupal Slovenia, we organised two presentations and sponsored a reception with networking after the event.

Are you interested what those two lecturers were about?

Bostjan Kovac: "Introduction to Drupal for Beginners"

Bostjan Kovac, Drupal veteran and Development director at Agiledrop, summed up everything Drupal was and what it is today. Drupal, like any technological phenomenon, began in the room of a student, who wanted to change the world. Initially was thought of as a system for setting up forums, but today it is used by companies and organisations around the world, to build digital experiences for their users and customers. It’s an open source system, based on PHP programming language. It is easily accessible to anyone who wants to develop complex solutions in a simple way.

Mitja Krope: “Simplify Drupal Projects with Distribution”

Mitja Krope, TDX product developer and head of the Agiledrops office in Maribor, revealed that when we decide to set up a new website in the Drupal, we choose between two options:

  • installing Drupal from scratch,
  • installing Drupal using a distribution.

Drupal does not have a large set of functions in its core. However, it is a development framework that can be modified and upgraded unlimitedly. But how to avoid wasting time by configuring and developing the same functionality on different projects all over again? An alternative to this is using a distribution, but none of the existing ones met our requirements. That's why we, at Agiledrop, developed our own. We’ve developed a distribution that allows us to save up to 100 hours of initial development in every project we are working on and bridge the gap between the user experience and the editors. We named the project Tailored Digital Experiences or shorter TDX, and we published it as an open source project, which can be used by everyone. The TDX distribution allows us to build pre-installed components quickly and offers flexibility in setting up complex content types.

Thanks to both lecturers for such interesting presentations, thanks to the Faculty of Electrical Engineering and Computer Science for an invitation and hosting, and last but not least to a large number of event attendees. There is another event happening in Maribor this week, a free Drupal course, and we can’t wait.   

Oct 25 2018
Oct 25

Last week we organised a Drupal meetup in Maribor (the second largest town in Slovenia, where Agiledrop has the second office) in cooperation with Student Council of Faculty of Electrical Engineering and Computer Science in Maribor. As a member of Drupal Slovenia, we organised two presentations and sponsored a reception with networking after the event. The event was well received, as attended by more than 50 people, mostly students of the faculty interested in starting their career in web development and Drupal.

Are you interested what those two lecturers were about?

Bostjan Kovac: "Introduction to Drupal for Beginners"

Bostjan Kovac, Drupal veteran and Development director at Agiledrop, summed up everything Drupal was and what it is today. Drupal, like any technological phenomenon, began in the room of a student, who wanted to change the world. Initially was thought of as a system for setting up forums, but today it is used by companies and organisations around the world, to build digital experiences for their users and customers. It’s an open source system, based on PHP programming language. It is easily accessible to anyone who wants to develop complex solutions in a simple way.

Mitja Krope: “Simplify Drupal Projects with Distribution”

Mitja Krope, TDX product developer and head of the Agiledrops office in Maribor, revealed that when we decide to set up a new website in the Drupal, we choose between two options:

  • installing Drupal from scratch,
  • installing Drupal using a distribution.

Drupal does not have a large set of functions in its core. However, it is a development framework that can be modified and upgraded unlimitedly. But how to avoid wasting time by configuring and developing the same functionality on different projects all over again? An alternative to this is using a distribution, but none of the existing ones met our requirements. That's why we, at Agiledrop, developed our own. We’ve developed a distribution that allows us to save up to 100 hours of initial development in every project we are working on and bridge the gap between the user experience and the editors. We named the project Tailored Digital Experiences or shorter TDX, and we published it as an open source project, which can be used by everyone. The TDX distribution allows us to build pre-installed components quickly and offers flexibility in setting up complex content types.

Thanks to both lecturers for such interesting presentations, thanks to the Faculty of Electrical Engineering and Computer Science for an invitation and hosting, and last but not least to a large number of event attendees. There is another event happening in Maribor this week, a free Drupal course, and we can’t wait.   

Oct 24 2018
Oct 24

 Drupal Module Spotlight: Paragraphs

I really don’t like WYSIWYG editors. I know that I’m not alone, most developers and site builders feel this way too. Content creators always request a wysiwyg, but I am convinced that it is more of a necessary evil and they secretly dislike wysiwygs too. You all know what wysiwygs (What You See Is What You Get) are right? They are those nifty fields that allow you to format text with links, bolding, alignment, and other neat things. They also can have the ability to add tables, iframes, flash code, and other problematic HTML elements. With Drupal we have been able to move things out of a single wysiwyg body field into more discrete purpose-built fields that match the shape of the content being created and this has helped solve a lot of issues, but still didn’t cancel out the need for a versatile body field that a wysiwyg can provide.

Content creators yearn for the flexibility of creating a page that matches their vision for how they want the layout. Front-end developers and designers want to be able to rigidly style a site that always looks good, and that clashes with the unexpected markup that a WYSIWYG can produce. These differing priorities can resulting in a real mess of a page. It’s been a struggle as old as the CMS itself.

Solutions of the Past

As I mentioned above, the Drupal solution to runaway WYSIWYG markup is purpose-built fields to catch all specific sections of content that you can.Instead of allowing the whole page to be created in one WYSIWYG field, we would have a field for an image, a summary, some various highlight sections, etc. One problem still remains, content creators want to be creative and have various patterns of content depending on what they are writing about. This includes images floating in every which-way, videos in the middle of an article, quote blocks, content in columns, and the list goes on. You can’t just build a bunch of types of fields for this problem. In the past, I tried using Field Collections and custom form alters to build a user interface that allowed them to select and only see the relevant fields, but this still proved to be too rigid.

The Modern Solution

Enter Paragraphs, the Drupal contributed module that can ultimately solve this problem. I started using Paragraphs with Drupal 7 back around 2014 and it really changed the way I thought about editing and creating content on a Drupal site.

With Paragraphs you can define little entities of fields much like the Field Collection module but less static. The difference is that you can access all or some of the different paragraph entity types from a single field on your content type. This single Paragraph content field will replace your body content wysiwyg field entirely. The Paragraph content field will allow you to endlessly add in different paragraph types and provides a method to reorder after creation. Working with your content creators, you can determine an unlimited number of content patterns that they would like to use. For example, you can create paragraphs with the fields required to make a slideshow, embedded video block, accordion content, or another that is an entity reference field to related articles, and one more that is simply a text area field. With this toolkit of content patterns your content creators can build content in any array of patterns they wish.

Paragraphs will satisfy the creative control that the editors of your site desire and will make them finally admit that they too hate that weird little wysiwyg field. When the situation arises that they want to do something new, it’s just a small revision to create a new paragraph type. Your frontend developers and designers will also be happy that they can strictly control the visual aspects of the individual Paragraphs with specific template files and targeted SASS styling.

Extending the Concept

An overlooked but very powerful use of Paragraphs is using it without any fields at all. Let's say that you want to add a newsletter signup form in the middle of your article. Simply define a paragraph called Newsletter signup then with a bit of custom code write a signup form, you could even have it automatically pass the signup source of the article in a hidden field. Next, all the article writer needs to do is drop the Newsletter signup Paragraph wherever they want it to appear within the article content. Another example of a field-less paragraph that we have used in the past is an about the author section. There are no fields needed, just add the paragraph and write code to look up the article’s author and write a template file to display a bit of author info with a headshot, simple as that.

I could write on and on about the possibilities and use cases for paragraphs, but you should really just download it and give it a test drive. It’s like introducing a mini block system into an individual article of content. If you are planning a new build or have an existing Drupal site, don’t hesitate to add Paragraphs. Your content creators and editors will love you for it.

Oct 24 2018
Oct 24

Award Program Showcases Outstanding Examples of Digital Experience Delivery

Vienna, VA – October 24, 2018 – Mobomo today announced it was selected along with NOAA Fisheries as the winner of the 2018 Acquia Engage Awards for the Leader of the Pack: Public Sector. The Acquia Engage Awards recognize the world-class digital experiences that organizations are building with the Acquia Platform.

In late 2016, NOAA Fisheries partnered with Mobomo to restructure and redesign their digital presence. Before the start of the project, NOAA Fisheries worked with Foresee to help gather insight on their current users. They wanted to address poor site navigation, one of the biggest complaints. They had concerns over their new site structure and wanted to test proposed designs and suggest improvements. Also, the NOAA Fisheries organization had siloed information, websites and even servers within multiple distinct offices. The Mobomo team was and (is currently) tasked with the project of consolidating information into one main site to help NOAA Fisheries communicate more effectively with all worldwide stakeholders, such as commercial and recreational fishermen, fishing councils, scientists and the public. Developing a mobile-friendly, responsive platform is of the utmost importance to the NOAA Fisheries organization. By utilizing Acquia, we are able to develop and integrate lots of pertinent information from separate internal systems with a beautifully designed interface.

“It has been a great pleasure for Mobomo to develop and deploy a beautiful and functional website to support NOAA fisheries managing this strategic resource. Whether supporting the work to help Alaskan Native American sustainable fish stocks, providing a Drupal-based UI to help fishing council oversight of the public discussion of legislation, or helping commercial fishermen obtain and manage their licenses, is honored help NOAA Fisheries execute its mission.” – Shawn MacFarland, CTO of Mobomo 

More than 100 submissions were received from Acquia customers and partners, from which 15 were selected as winners. Nominations that demonstrated an advanced level functionality, integration, performance (results and key performance indicators), and overall user experience advanced to the finalist round, where an outside panel of experts selected the winning projects.

“This year’s Acquia Engage Award nominees show what’s possible when open technology and boundless ambition come together to create world-class customer experiences. They’re making every customer interaction more meaningful with powerful, personalized experiences that span the web, mobile devices, voice assistants, and more,” said Joe Wykes, senior vice president, global channels at Acquia. “We congratulate Mobomo and NOAA Fisheries and all of the finalists and winners. This year’s cohort of winners demonstrated unprecedented evidence of ROI and business value from our partners and our customers alike, and we’re proud to recognize your achievement.”

“Each winning project demonstrates digital transformation in action, and provides a look at how these brands and organizations are trying to solve the most critical challenges facing digital teams today,” said Matt Heinz, president of Heinz Marketing and one of three Acquia Engage Award jurors. Sheryl Kingstone of 451 Research and Sam Decker of Decker Marketing also served on the jury.

About Mobomo

Mobomo builds elegant solutions to complex problems. We do it fast, and we do it at a planetary scale. As a premier provider of mobile, web, and cloud applications to large enterprises, federal agencies, napkin-stage startups, and nonprofits, Mobomo combines leading-edge technology with human-centered design and strategy to craft next-generation digital experiences.

About Acquia

Acquia provides a cloud platform and data-driven journey technology to build, manage and activate digital experiences at scale. Thousands of organizations rely on Acquia’s digital factory to power customer experiences at every channel and touchpoint. Acquia liberates its customers by giving them the freedom to build tomorrow on their terms.

For more information visit www.acquia.com or call +1 617 588 9600.


All logos, company and product names are trademarks or registered trademarks of their respective owners.

Oct 24 2018
Oct 24

In order to move the needle on business outcomes, methods must be backed with real, actionable insights and data. For Extension, this meant developing a deep understanding of their users’ behavior and motivations.

First, we defined key audience segments and generated personas and user journeys. Then, we validated the way that each segment interacts with the site through menu testing and in-person usability testing. This user research gave us direct and applicable insights which established the foundation for what kinds of features prospective students need and expect from the site.

Oct 24 2018
Oct 24

Your browser does not support the audio element. TEN7-Podcast-Ep-042-DrupalCorn.mp3

It is our pleasure to welcome Tess Flynn to the TEN7 podcast to discuss attending the 2018 DrupalCorn and presenting "Dr. Upal Is In, Health Check Your Site". Tess is TEN7's DevOps engineer.

Here's what we're discussing in this podcast:

  • DrupalCorn2018
  • DrupalSnow
  • Camp scheduling
  • What it takes
  • Unconference the conference
  • Substantive keynotes
  • Dr. Upal is now in
  • The good health of your website is important
  • It takes humans and tools
  • Every website is a bit like a person, it’s a story
  • Docker-based Battle Royale
  • Auditing the theme
  • Mental health and tech
  • Drupal 8 migration
  • A camp with two lunches
  • Loaded baked potatoes and corn
  • Cornhole
  • Catching Jack the Ripper
  • Onto DrupalCamp Ottawa


IVAN STEGIC: Hey Everyone! You’re listening to the TEN7 Podcast, where we get together every fortnight, and sometimes more often, to talk about technology, business and the humans in it. I am your host Ivan Stegic. In this episode of the Podcast, we’re talking to Tess Flynn, about DrupalCorn 2018, that happened at the end of September, in Des Moines, Iowa. Tess, welcome back to the podcast.


IVAN: So, DrupalCorn. I love that it’s not DrupalCamp Iowa.

TESS: (laughing) That’s one thing that I always appreciated with it. They have a sense of humor to match their camp.

IVAN: (laughing) It’s just great. I think we have to come up with something for TC Drupal and I don’t think we can top DrupalCorn.

TESS: I still miss the Cherry logo that we had years, and years, and years ago. Although the snow globe one’s pretty good.

IVAN: So, DrupalSnow, maybe? 

TESS: (laughing) That would be an interesting thing to do, like a one-day event, in the middle of winter. (laughing)

IVAN: (laughing) We’ll see how many people come out to that, huh?

TESS: BOFs and sledding. (laughing)

IVAN: (laughing) That would be fun. That’d actually be fun, actually. So, let’s see, DrupalCorn, this year it was at the Center for Higher Education in Des Moines. Is that on campus somewhere? I’m not familiar with where that is.

TESS: So, it was in the business school, that got bought out. There’s a bit of a story about this. It used to be, I think, an independent business school, and then it got bought out, and brought into the university system, and, yeah, there’s a bit of an interesting story behind that, but that one’s not mine to tell.

IVAN: (laughing) Ok, so, on some sort of a former business school campus, and from what I could tell, the format was exactly the same format that we’ve had at DrupalCamp Twin Cities. So, training on a Thursday, session and keynotes, Friday, Saturday, and then contribution day on a Sunday. That’s a lot of programming for a camp.

TESS: It is!

IVAN: Yea, it is. Do you think it’s overkill?

TESS: I think that it’s up to the camps to really determine if that scales for their audience. And, I did participate in the closing session, for DrupalCorn, which was mostly for camp organizers and volunteers, but I was in the same room, and I decided, oh, I’ll just stay around and how it goes, because they were inviting anyone who wanted to stay for it. And, it sounded like they had lots of people attending the training sessions, that they had no problem filling those out. And, the first two days, seemed perfectly fine. It didn’t seem like there was a massive drop off in individuals or people at either one of those.

IVAN: And, that closing session, was that on a Saturday?

TESS: That was on the Saturday.

IVAN: Ok. I mean, it takes a lot of time, and a lot of money, to plan and execute such an extensive program, and I am always amazed that camps do this, and that it’s all volunteer based, it’s not for profit, people give of their own time. It’s amazing! It’s just amazing!

TESS: Well, DrupalCorn serves a lot of different camps in the Greater Midwestern area in the United States. There were lots of people from Kansas, which just surprised me. I was like, “why are there so many people from Kansas here?” And, “why don’t I see those same people at Twin Cities Drupal camp?” And, a lot of it comes down to, “well, it’s closer.”

IVAN: Yea, it’s closer. Like, you would have to drive twice as far, to the Twin Cities, or fly. So, that does make a difference. Was the size of the camp, kind of what you would expect, 200 or so people? Was it any bigger or smaller, this year?

TESS: It felt like it was a bit smaller this year, mostly because they took last year off, for various reasons. And, there was actually an interesting discussion about, if camps should do that more often, that we could talk about.

IVAN: You mean, take a year off?

TESS: Mm hmm.

IVAN: Yeah, so, was that part of the closing session? Where was that discussion?

TESS: That was part of the closing session.

IVAN: So, what were the thoughts around it?

TESS: So, the reason why they decided not to have one last year is there were some people who were starting families, and had vacations, or had other things that were just happening, and they just couldn’t get their core organizational group together, in order to do that. So, it seemed like it made more sense to just, not have the camp that year. And, at first it was really disappointing, because I remember talking to one of the organizers at Baltimore, and being like, “aw, there’s going to be no DrupalCorn this year, it’s one of my favorite camps.” But, since then, I thought, this is actually not a bad idea, because, I’ve gone to DrupalCorn for the previous two, if not three, years. Then they had the year off, then they had this year, and, one thing that I was kind of surprised by, is that, compared to the last DrupalCorn, there was more energy at this one. There was more focus. There was more drive. There was more enthusiasm. I think that actually is something to be said about taking a year off, occasionally. It lets your organizers rest, so that the next year they can really go at it. And, I’ve been thinking a lot about Twin Cities DrupalCamp, because DrupalCon Minneapolis is in 2020. Should we even have a camp in 2019? That’s a tricky one.

IVAN: Yeah, that is a tricky one. It feels like we’ve been evaluating whether or not, not just whether or not the camp’s going to happen, but, what the format of the camp might be, as well. And, I was at the Twin Cities Open Source CMS Unconference, whew, mouthfull (laughing), this weekend, and, it just struck me that, having an Unconference like format for a camp, makes it so much easier to organize, and to put together people that are kind of basically there to learn, just like what the camp is for. And, I wonder if it isn’t, not just taking a year off, but maybe there's an Unconference like event, might be a thing to consider as well.

TESS: Yeah, and I think those concepts can actually play well with each other, because people who like the Unconference format, might not be the same people who normally run a traditionally and conventionally-focused camp. In which case, why not just do a slightly different Drupal event that year, for the area? That might work too, then you can compare and contrast later.

IVAN: Yeah, that might be a good idea for us. It’s interesting how all of this has evolved in the community, and how Drupal compares with local camps, and WordPress, and other communities. It’s just fascinating that all of this happens the way it does. So, I want to ask about the keynotes. So, I want to ask about the keynotes. There were two keynotes – Tiffany Farris from Palentir.net keynoted, and I think the title of her keynote was, “Learning at Work,” and that was on Friday, and then, Matt Westgate from Lullabot, keynoted, and I love the title of his keynote, “How to Fall in Love with Drupal Again.” What are your take-aways from the two keynotes, maybe either as a whole, or individually? I assume you went to them?

TESS: I did go to them, but, both nights, the previous night I had terrible insomnia problems, I was just not getting used to the hotel bed, and, so, I was real dreary and I couldn’t quite remember, and my nose was already, like on the screen, working on my module project, anyways. So, I actually had a hard time remembering almost anything about those talks right now.

IVAN: Oh, no!

TESS: The caffeine just didn’t kick in yet. (laughing)

IVAN: Well, I would then recommend users who are listening, or listeners, to look at the recordings on the DrupalCorn.org website, because I’m pretty sure that Kevin Thull was there, recording every single session, and most likely, the keynote is included there.

TESS: Yeah, I believe that, I did talk to him after the first day, and there was one keynote session that just didn’t record for other reasons, and the next day, there was 100% capture.

IVAN: Wow! It’s just amazing what he does for the community, isn’t it?

TESS: I always have a special place in my heart for the AV guy. (laughing)

IVAN: (laughing) Yes, absolutely. So, the schedule at DrupalCorn wasn’t just sessions, right? Wasn’t just pre-prepared sessions. There were BOFs (Birds Of a Feather) listed there as well. Did you go to any of them?

TESS: I did not. I didn’t find any of them that were that interesting. I found a lot more sessions, which were interesting, so I really wanted to go to a lot of those, and I do remember that on the first day I was there, Friday, even skipped out on an entire session period, and took over an empty BOF room, just so that I could decompress and go over my talk before giving it in the next period.

IVAN: It was probably a good thing. So, let’s talk about your session. So, you presented "Dr. Upal is in, health check your site". Can you tell us a little bit about your session, and maybe what you were hoping the outcomes of the session would be?

TESS: So, really, the session is about trying to instruct people, how to perform a technical audit of your Drupal site. A lot of the time, people who have Drupal sites, who are individual organizations, or are freelancers, might not necessarily know how to really inventory a site. There’s a variety of different circumstances. Like, you’re looking at doing an upgrade, but you don’t know what all your site has in it; you’re a new employee and you don’t know how to quite wrap your head around the site; the site was just dropped in your lap, and now it’s your problem, and you need to figure out what to do with it. So how do we really get a good sense of what a site is doing? How it’s working? Is it healthy or not? Does it have problems or not? Does it have things that will become problems in a short amount of time? What tools can we use to examine those, and how can we perceive all of this, and make it so that we know how to proceed, to get our sites back onto a track towards being healthy.

IVAN: So, the health of your website is really important, and that’s exactly what your talk sounds to be about. You talk about some tools during the session, but you also point out that there is human interaction that needs to be done to evaluate the site itself. Right? It’s not just about running tools.

TESS: Yeah, no one tool or even the entire toolbox of tools, is going to be able to tell if your site is healthy or not. Every site is a bit like a person, it’s a story. You need to figure out where it begins, how it's changed, what its plot is, what it’s twists and turns are, what characters are involved in its development, and then kind of get that whole sense of what that story is, so you could see where it’s going in the future.

IVAN: I love that idea of your site being a story. It’s kind of a live, breathing thing, that doesn’t change. Or people think that it isn’t a live breathing thing that doesn’t change, but it is, and people add content, and submit forms, and things get out of whack sometimes, so it’s not exactly the same as when you launch it. And, I love the idea that it needs a doctor, just like a human does, as well. That’s a great idea to think about. So, your session went well. I know you usually bring swag, and you give that kind of stuff out. That’s awesome. Now, there were some sessions in the schedule that caught my eye, that I thought were really interesting, that I wished I could’ve gone to, if I had gone to the camp. One was Wilbur's Docker-based Battle Royale, which is a great name for a session. The other one was, a guy by the name of Andy Olson, and he had a talk called “Audit your Theme.” Now, I know you’ve seen Wilbur’s talk, probably at TC Drupal, did you by any chance go to the other one?

TESS: I did go to the Audit your Theme one, because that was really quite interesting. Theming is not my particular specialty, and I actually really don’t know how to approach that entire discipline, of auditing a theme, and this gave me a lot of framing, for how to look at that and what to look at, and that was really, really fascinating.

IVAN: So, were there tools involved in that presentation as well, or was it kind of, a mixture of tools and human interaction? What was the, kind of the crux of that session?

TESS: So, there was a combination of tools and human interaction. We had several different tools, like we had some linters, we had some other performance analysis tools, and other CSS compiling efficiency check tools that I had, quite frankly, never even heard of, or conceived that they existed, but as soon as they were revealed to me, I was like, “of course, they would have something like that. Why didn’t I think about that until now?” And, it was really just an eye-opening experience.

IVAN: So, those were kind of two that caught my eye. What sessions did you go to that were interesting outside of Andy’s?

TESS: Oh man, I’d have to bring up a schedule, because a lot of that just got swapped out of my cache already. (laughing) Let’s see. I went to the gulp session, but the caffeine still had not kicked in yet, so that was just, I don’t remember anything at all from that. And, then that’s where I skipped a period, because I needed to practice.

IVAN: So, there were four tracks?

TESS: Yeah, there were several different tracks. I went to the Mental Health and Tech one. It is a very similar presentation to one that’s been going around, at a variety of camps and cons, but it’s really nice to see an update on that. I think he’s doing good work bringing that talk, repeatedly, to our community. I went to the Legos session, "Building your Legos, a Practitioner’s Guide to Building Reusable Components". There’s a module that’s called Legos. And, I didn’t know about this, and it was actually a fascinating counterpoint to paragraphs only sites. I thought that it was kind of fascinating, but at the same time I was like, “ahh, I have some concerns.” I think actually during the course of that talk, there was some mention about how you can’t get certain paragraphs to display with different view modes, and I know that we’ve done that before at TEN7, using a module-only solution, so. That was an interesting problem. (laughing)

IVAN: I would guess you maybe went to the Migrating Drupal 8 entities talk?

TESS: I did go to that one, and I felt kind of bad after that, because I went to it, knowing that, “ok, let’s see how this guy handles this", because unfortunately I know way too much about migration stuff. I have joked on Twitter that at some point, when you become a Drupal 8 migration expert, you start sounding a bit like a babbling prophet (laughing), instead of a developer. Talking about plug-ins and pipelines, and transformation and ETLs, like, I don’t know what any of this means any more (laughing).

IVAN: (laughing) Well, you certainly are our migrations expert at TEN7, so, I wouldn’t have it any other way.

TESS: It was generally a good talk. What was most impressive is, he smashed an awful lot of content, into a very narrow talk. I considered writing a talk about doing migrations before, because I have a blog series on this, but I decided that it was just way too much to squish in to even a 50-minute talk. It was just going to be like a fire hose, and it was a fire hose in this talk, and I believe he did a really good job of it. He used a different technique for importing paragraphs than I’m used to, so I actually put that forward at the end of the talk as an alternative.

IVAN: Very good. Now, were the sessions at DrupalCorn all the same length, or were there shorter ones and longer ones?

TESS: I think that they were all the same length this year. The big thing that was different this year, was that there was two different lunch periods, which was interesting.

IVAN: Oh, lunch one, lunch two?

TESS: Yeah.

IVAN: Really!

TESS: Lunch is actually one of the things I like the most about DrupalCorn, (laughing) mostly because, one thing that I really tended to like about DrupalCorn is that, because it’s in Iowa, there’s not much in Iowa. Even when you’re in Des Moines, it’s not the same as even being in Minneapolis, it’s definitely a smaller metropolis, and as a result, one thing that’s really kind of nice about DrupalCorn is that it has a generally, very familial vibe. You don’t feel like you’re going to a camp, you feel like you’re going to a dinner, with friends and relatives, and you’re all going to have a good time. And, that’s what it often feels like, and I really enjoy that particular feeling.

IVAN: So, basically, they had two lunches available through an extended period of time, over the course of two sessions. So, you basically don’t have one hour where there are no sessions going on. There are sessions going on throughout the day, and you choose when to take your lunch.

TESS: And you got to bring the lunches in with you to the sessions.

IVAN: Oh, you did! So, there wasn’t a lunchroom, or a common space?

TESS: Not really! There was plenty of places to sit down. There was a kind of common space, but there wasn’t many people using it. In this particular venue, they actually did have a café, that you could sit down and actually eat lunch in, and that’s where lunch was actually being served. And, some people did that, but some people also just, filled up their plates and headed off to the next session, and just sat down, and quietly munched while the session was being given.

IVAN: So, was it like a buffet style lunch?

TESS: Yeah, it usually is with DrupalCorn. One of the lunches is the traditional loaded baked potato.

IVAN: Ooh, that sounds good!

TESS: Oh, it is good! It is very good!

IVAN: Was there any corn? I guess that’s a question I have to ask.

TESS: This year, I think there wasn’t. (laughing) I could’ve just missed it. I remember the first lunch I went to, they nearly ran out by the time I was in line, because I showed up late.

IVAN: So, all in all, a good camp, kind of similar, regional camp would be Twin Cities  DrupalCamp. It feels like it’s the same amount of time, 4 days, about the same number of tracks, 3 or 4, BOFs, lunch, and good people. Any social activities in the evenings?

TESS: Yea, there was a speaker dinner on Thursday night, before the regular sessions were given, and that was wonderful. That was right in town, and it was a welcome respite from being in a car for four and a half hours. (laughing)

IVAN: Oh, my goodness! I’m sure. So, you got to mingle and meet with all the people that were giving sessions. I’m sure some familiar faces there too?

TESS: Mm hmm. And, then, the following night there was another dinner/cornhole event, that was in kind of a, it’s hard to describe what it was, it’s not really a sports bar, it felt like a rented bar/restaurant space. It’s hard to describe, but they had really, really good burgers.

IVAN: Really? So, forgive me for not understanding what cornhole is. Maybe you can give me a description.

TESS: So, first of all, imagine a board that is at an incline of, let’s say, ten to fifteen degrees off from the ground, and about three-quarters of the way up from the edge that is touching the ground, to the top of the board, is a hole, and the rest of the board is very highly glossily painted, so that it’s kind of slippery.


TESS: Now, you stand away from that board, at the other end of the playfield, a distance of approximately, sorry my eyes are calibrated to meters, so let’s just say 4-5 meters away, and what your job is, you have a beanbag, and you need to toss the beanbag so that it goes into the hole. And that sounds really simple, except that there’s a bit of technique to it. You can’t just toss it, and have it land directly in the hole, it’s best to kind of, put a bit of, either you have to undershoot it, but with force so it goes up the board, and down into the hole, or overshoot it, with just enough force so that once it lands, gravity will actually carry it back down into the hole, because you almost never could throw it directly in.

IVAN: So, this sounds like a game that you would play in bars, and maybe you’d get much better, or much worse, depending on how much beer you’ve had.

TESS: (laughing) That’s generally the idea, yes. I was introduced to this at the first DrupalCorn I went to, and that was a lot of fun. That camp was particularly a lot of fun, because it was in a school, and they had all of, every event, every lunch, every before event and after event, was actually in the same location, so that really made it feel very comfy, like you were just coming home to have some fun, and that was great.

IVAN: That’s awesome. And, so that was the social events Friday night. Saturday and then contribution on Sunday. Nothing on Saturday night then?

TESS: I think there was something on Saturday night, but at that point, I was kind of fried, because I’m kind of an introvert, and I just decided that, “I think I had enough,” and instead kind of staged my own little introverts game night at the hotel lobby and we got pizza, and played a card game where you’re trying to catch Jack the Ripper. It was actually a lot of fun.

IVAN: Oh my! So, there were games as well, at DrupalCorn? Awesome.

TESS: Mm hmm. I think the previous night there was also some board games after the cornhole event, but I was too fried after that too.

IVAN: Sounds like a great camp. I’m glad that you were able to go and report back to us, and I know you’re going to DrupalCamp Ottawa next week.

TESS: Oh yeah, first time going to Canada. Going to be interesting.

IVAN: Well, why don’t you remember as much as you can about the camp, and we’ll have you back on the Podcast to give us a kind of a review of that camp as well.

TESS: I will try my best.

IVAN: Well, thanks so much for spending your time with me, talking about DrupalCorn.

TESS: Mm hmm.

IVAN: You’ve been listening to the TEN7 Podcast. Find us online at ten7.com/podcast. And if you have a second, do send us a message. We love hearing from you. Our email address is [email protected]. Until next time, this is Ivan Stegic. Thank you for listening.

Oct 24 2018
Oct 24


Related blog posts

A day doesn't go by that someone isn't asking a question in Slack #migration about how to troubleshoot a specific problem with a tricky migration. Almost universally, these problems be demystified by using Xdebug and putting breakpoints in two spots in Core's MigrateExecutable. First is in the ::import() method where it rewinds the source and then processes it. The second place I regularly put a breakpoint is in ::processRow(). Or if I already know which process plugin is breaking, I might put a breakpoint in it directly. For example, the sub_process or migration_lookup process plugins tend to be complicated and a common place for me to drop a breakpoint.

Try it out. Put some breakpoints in these places. See how a row of data is processed. You'll learn a lot and the mystery of migrations will disappear.

Are you looking for help with a Drupal migration or upgrade? Regardless of the site or data complexity, MTech can help you move from a proprietary CMS or upgrade to the latest version–Drupal 8.

Write us about your project, and we’ll get back to you within 48 hours.

Oct 24 2018
Oct 24

The Research and Development team at BBC (British Broadcasting Corporation) have been working on IP production for a number of years building a model for end-to-end broadcasting that will allow a live studio to run entirely on IP networks. During this period, several software applications and libraries have been built in order to prototype techniques, develop their understanding further and implement emerging standards. To do all these, they leverage Continuous Integration along with a number of tools to aid with Continuous Delivery of their software. Why is Continuous Integration a preferred option for large organisations like BBC?

Illustration showing three pillars and several people exchanging things, working on a laptop, holding a chart while discussing and having a conversation

A software development methodology like Continuous Integration (CI) can be of paramount importance for an efficient software delivery. Drupal-based projects can gain a lot with the implementation of CI leading to better teamwork and effective software development processes.

Predates many of the Agile’s ancestors

CI is older than many of the ancestors of agile development methodology. Grady Booch, an American software engineer, gave birth to the term ‘Continuous Integration’ through the Booch Method (a method used in object-oriented analysis and design) in 1991.
Booch, in his book called Object-Oriented Analysis and Design with Applications, states that:
The needs of the micro process dictate that many more internal releases to the development team will be accomplished, with only a few executable releases turned over to external parties. These internal releases represent a sort of continuous integration of the system, and exist to force closure of the micro process.

Principles of Continuous Integration

Flowchart showing box, circles, and arrows to depict workflowSource: Amazon Web Services

A software development methodology like Continuous Integration allows members of the team integrate their work frequently. It involves each of the team members integrating at least daily thereby leading to multiple integrations every day. Each of the integrations is checked by an automated build (that includes the test) for detecting integration errors faster.

“Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.” — Martin Fowler, Chief Scientist, ThoughtWorks

Developers can frequently commit to a shared repository with the help of a version control system such as Git. They can choose to run local unit tests on their code before each commit as a mark of added verification layer before integrating. A CI service automatically builds and runs unit tests on the new code alterations for immediate identification of any errors.

With Continuous Delivery, code alterations are automatically built, tested and pushed to production. Continuous Delivery expands upon Continuous Integration by deploying all code alterations to a test environment and/or production environment after the build stage.

Key practices that form an effective Continuous Integration

  • Single source repository: A decent source code management system should be in place.
  • Build automation: Automated environments for builds are a common feature of systems that ensure that you can build and launch your system using a single command.
  • Self-testing: Automated tests in the build process can help in catching bugs swiftly and efficaciously.
  • Daily commits: By committing to the mainline every day, developers can correctly build their code including passing the build tests.
  • Integration machine: Regular builds should be happening on an integration machine and the commit should be considered done only if this integration build succeeds.
  • Immediate fix of broken builds: The integral part of doing a continuous build is that if the mainline build fails, it should be immediately fixed.
  • Rapid feedback: It is of consummate importance to keep the build fast and provide rapid feedbacks.
  • Test environment: Always test in a clone of the production environment.
  • Finding the latest executable: Anyone involved in a software project should get the latest executable easily and be able to run it for demos or exploratory testing.
  • See the state of the system: Everyone should be able to see what’s happening with the system and the alterations that have been made to it.
  • Deployment automation: You should have scripts that will let you deploy the application into any environment easily.

Continuous Integration Workflow

  • At first, developers check out code into their private workspaces
  • When performed, commit the alterations to the repository.
  • The CI server monitors the repository and checks out alterations when they occur.
  • The CI server builds the system, runs unit and integration tests, releases deployable artefacts for testing
  • The CI server assigns a build label to the version of the code which was just built by it and informs the team of the successful build
  • The CI server alerts the team members if the build or tests fail
  • The team members immediately fix the issue
  • The team continues to integrate and test throughout the project

Responsibilities of the team members

  • Check in frequently
  • Do not check in broken code, untested code or when the build is broken
  • Do no go home after checking in until the system builds

Continuous Integration tools

A development team uses CI software tools for automating parts of the application build and constructing a document trail. The following are examples of CI pipeline automation tools:

  • CircleCI is a continuous integration platform. When connected to a Drupal site, alterations made in version control in code repository such as GitHub alert CircleCI to start the build of the application and execute predefined testing suite.
  • Travis CI is similar to CircleCI which integrates with GitHub, Bitbucket, and other applications. It creates application builds and runs testing suites when code alterations are pushed.
  • Jenkins is an open source automation server installed and handled by the user unlike platform services like CircleCI and Travis CI. It is extendable with plugins and works well with Git. It lets you do a wide range of configurations and customisation.
  • The open source GitLab repository and platform can run unit and integration tests on several machines and can split builds to work over numerous machines for decreasing execution times.
  • JetBrains TeamCity is an integration and management server for enabling developers to test code before they commit alterations to a codebase. It features Build Grids which allow developers to run several tests and builds for different platforms and environments.

Merits of Continuous integration

Illustration showing a number of small circles over the circumference of a larger circle to explain Continuous IntegrationSource: Apiumhub

Eliminates the blind spot

Deferred integration is troublesome as it is an arduous task to predict how long it will take to do a project or even worse how far are you through the process. So much so that you are putting yourself in a blind spot at one of the critical parts of a project. One of the most significant merits of Continuous Integration is minimised risk. With CI, there is no long integration and it completely eliminates the blind spot. You will know where you are, what is working and what is not, and the outstanding bugs that you have in your system.

Easy bug detection

CI does not entirely remove bugs but makes it easier to detect it faster. Projects with CI tend to have dramatically fewer bugs both in production and in process. The degree of this merit is directly proportional to how good your test suite is.

Frequent deployment

CI promotes frequent deployment which lets your users get new features more rapidly, to provide more rapid feedback on those features and collaborate more in the development cycle.

Continuous Integration for Drupal

DrupalCon Dublin 2016 had a presentation which showed how you can leverage the Jenkins 2 pipelines for implementing Continuous Integration/Deployment/Delivery for the Drupal site while taking care of the principles like Infrastructure as Code, Configuration as Code, DRY (Don’t Repeat Yourself) and Open/Closed principle (from SOLID principles).

[embedded content]


The process that was followed in the presentation required pushing a commit into self-hosted (Gitlab) or private Github repo. It involved building the doc root from the various sources, deployment procedures, auto-tests on servers and everything was done in the same pipeline configured as separate stages.
It showed the auto-generation of deploy pipelines for each branch/state like development, staging or production configured. It utilised different approaches for governing code structure such as Composer-based workflow and ‘all-code-in-repo’ solution in the same doc root. Auto-checking that code was delivered to the server prior to the start of drush deploy procedures and testing.

The project team can have their own deploy scripts

Universal deploy script was used that will be useful for any project. Additional project-specific deploy scripts - DRY (or override) basic deploy script - was leveraged which could be useful when you delegate this part of the responsibility to the different team. You can control what drush commands or command options can be used for certain projects, that is, the project team can have their own deploy scripts.
Configuration as a code on both the Jenkins side and the Drupal side was performed. On the Jenkins side, all Jenkins jobs (pipelines) was stored as code in Git and regenerated in case of code alterations with the assistance of Job DSL. On the Drupal side, every configuration alteration was performed in code and then processed on Production servers during code deploys.
It showed auto-creation of URLs and databases on hosting platform based on multisite setup. It displayed automated backups before code deploys, copied whole sites inside doc root or between different doc roots with one click and added custom actions for offering additional functionality specific to the projects.

Market trends

The Forrester Wave™: Continuous Integration Tools, Q3 2017 delineated the 10 providers that matter most and how they stack up.

Infographic showing a quarter of a circle inside a box and several smaller circles inside it to depict Continuous Integration tools

A report on Markets and Markets stated that the CI tools market size is expected to grow from USD 483.7 million in 2018 to USD 1139.3 million by 2023 at a Compound Annual Growth Rate (CAGR) of 18.7% during the forecast period.

A study by Data Bridge Market Research states that major players operating in the global continuous integration (CI) tools market are Atlassian (Australia), IBM (US), Microsoft (US), Micro Focus (UK), CA Technologies (US), Cloudbees (US), AWS (US), Puppet (Oregon), Red Hat(US), CA Technologies (US), Oracle (US), Micro Focus (UK), SmartBear (US), Jetbrains (Czech Republic), CircleCI (US), Shippable (US), Electric Cloud (US), V-Soft Technologies (South Africa), BuildKite (Australia), TravisCI (Germany), AutoRABIT (US), AppVeyor (Canada), Drone.io (US), Rendered Text (Serbia), Bitrise (Hungary), Nevercode (UK), and PHPCI (Belgium) are among others.


Software development can be drastically improved with the incorporation of Continuous Integration resulting in better team collaboration, reduced risk, and faster delivery. Drupal-based projects can reap the merits of CI tools. With Drupal being a huge perpetrator of digital innovation, implementing Continuous Integration in Drupal projects is viable.

OpenSense Labs has a pool of Drupal experts who have been a force to reckon with when it comes to enabling digital transformation dreams of enterprises with its suite of services.

Contact us at [email protected] to know how can you leverage continuous integration for Drupal projects.

Oct 24 2018
Oct 24

We are honored to have been chosen as the only company from Jordan to be featured in Clutch’s 2018 Leading B2B firms in Africa and Asia list. Clutch is one of the world’s leading B2B networking platforms.

The list features 200 identified companies based on in-depth evaluation of 12 qualitative and quantitative factors.

Leading up to this award; we look back at 2018 and recognize the moments that enabled us to earn this recognition:

Drupal Community Recognition

Only one person managed to contribute more than Rajab Natshah towards the open-source community of Drupal.

Representing both Vardot and the Jordan Open Source Association; senior software engineer and good friend Rajab’s valuable contributions were recognized and appreciated by the Drupal open-source community.

Vardot has always valued the feedback of the open-source community and we shall continue to work hard towards advancing the principles of open-source and Drupal technology.

We are very proud of Rajab for putting Jordan on the open-source Drupal community map in 2018 make sure to follow him on Twitter!

Contribution by Country to Drupal in 2018

 Source: Dries Buytaert

Masterful Expertise

Sustaining a reputation as a leading enterprise solutions providers and digital experience platform builders is a never-ending endeavor that relies on a team with a passionate drive to be the best.

2018 has been particularly eventful for Omar Alahmed who became a full-fledged Drupal 8 Grand Master back in July.

Acquia Certified Site Builder (Drupal 8)

  • Muath Khraisat
  • Ahmad Halah
  • Omar Alahmed
  • Yasmeen Abuerrub
  • Rajab Natshah
  • Mahmoud Zayed
  • Sally Nader

Acquia Certified Developers (Drupal 8)

  • Muath Khraisat
  • Omar Alahmed
  • Mahmoud Zayed
  • Rajab Natshah

Acquia Certified Back-End Specialist (Drupal 8)

Acquia Certified Front-End Specialist (Drupal 8)

  • Omar Alahmed
  • Mahmoud Zayed

It’s still early days, this list may yet expand before years’ end.

The First Drupal 8 Back End Developer in MENA

Success Stories

Working on new, interesting and rewarding projects with great clients was a blessing in 2018 as we get to be part of the development of great ideas and products.

Here’s a selection of our favorites:

The platform is quickly becoming the premier e-learning community for the Arab speaking market.

It's never too late to brush up on your knowledge or learn something new. Join a growing community of 80,000+ members.

A unique product that enables users to tell their life story or memoirs in a seamless manner.

The Life Writer

Thanks to Drupal modules, The application features full cross-device optimization, secure e-commerce capabilities and the ability to dictate text via speech smoothly.

After building their official digital platform; we were honored to be selected again by the United Nations Relief and Works Agency (UNRWA) to develop their official donation platform.

To learn more about how you can improve the lives of people who need your help, don’t hesitate to visit the platform here.

UNRWA Donation

Access to quality education is a universal right. Working with the Queen Rania Foundation on their latest education enablement initiative; the Queen Rania Award for Education Entrepreneurship is a project dear to our hearts.

If you are an entrepreneur or educator that has an idea to advance education in any manner; check here if your idea qualifies!

You still have 2 weeks before the deadline for submission arrives.

Queen Rania Award

The Middle East has seen more than it's fair share of hate and social injustice; which makes the Meshkat community initiative a positive step forward in rebuilding social cohesion within future generations.

Meshkat Community (مجتمع مِشكاة) is an initiative launched by PeaceGeeks in Jordan in 2017 which strengthens community cohesion and constructive dialogue in the Middle East North Africa (MENA) region by building the skills, networks, knowledge, and action of citizens. 


The list is too long to mention but the effort to deliver is ongoing. We are currently working on awesome projects with the Saudi Research and Marketing Group (SRMG), Al Bawaba News, Queen Rania Foundation, United Nations Ops (UNOPS), ProEquest, Amman Stock Exchange and ICARDA.

New Accounts and Partnerships

Varbase Evolution

Thanks to the valued feedback from the open-source community we were able to sustain frequent releases that enhance the performance of Varbase. Varbase is the ultimate CMS starter kit for Drupal projects.

During 2018; more developers and project teams adopted Varbase as their go-to solution to build effective digital experiences. Vardot is constantly maintaining and improving upon Varbase to guarantee that it delivers on the promise of enhancing Drupal project delivery by automating best practices and modules available.

Download Varbase

Expanding Our Horizons

Success is collaborative. As such, we are always seeking to grow bigger and better by collaborating with organizations that match our passion for excellence.

Strategic partnerships are only strategic if they are the right partnerships, forged in a bid to achieve larger and common objectives. 

Vardot is pleased to have built relationships with Naseej and Boston Consulting Group in 2018. A relationship that will reap bigger rewards for all involved.

In the end; the real reason why we are where we are today is our team.

Congrats to all the team members that enriched our expertise, knowledge and enhanced our ability to deliver to our clients even more.

Well done, Vardotters.
You earned this.

Official Clutch Release: Leading B2B Companies in Greater Asia and Africa Announced for 2018

Oct 24 2018
Oct 24

Why Preston So' new book on decoupled Drupal will give Drupal more reach and credibility among developers building decoupled architectures.

The cover of the Decoupled Drupal book

Drupal has evolved significantly over the course of its long history. When I first built the Drupal project eighteen years ago, it was a message board for my friends that I worked on in my spare time. Today, Drupal runs two percent of all websites on the internet with the support of an open-source community that includes hundreds of thousands of people from all over the world.

Today, Drupal is going through another transition as its capabilities and applicability continue to expand beyond traditional websites. Drupal now powers digital signage on university campuses, in-flight entertainment systems on commercial flights, interactive kiosks on cruise liners, and even pushes live updates to the countdown clocks in the New York subway system. It doesn't stop there. More and more, digital experiences are starting to encompass virtual reality, augmented reality, chatbots, voice-driven interfaces and Internet of Things applications. All of this is great for Drupal, as it expands its market opportunity and long-term relevance.

Several years ago, I began to emphasize the importance of an API-first approach for Drupal as part of the then-young phenomenon of decoupled Drupal. Now, Drupal developers can count on JSON API, GraphQL and CouchDB, in addition to a range of surrounding tools for developing the decoupled applications described above. These decoupled Drupal advancements represent a pivotal point in Drupal's history.

Decoupled Drupal sitesA few examples of organizations that use decoupled Drupal.

Speaking of important milestones in Drupal's history, I remember the first Drupal book ever published in 2005. At the time, good information on Drupal was hard to find. The first Drupal book helped make the project more accessible to new developers and provided both credibility and reach in the market. Similarly today, decoupled Drupal is still relatively new, and up-to-date literature on the topic can be hard to find. In fact, many people don't even know that Drupal supports decoupled architectures. This is why I'm so excited about the upcoming publication of a new book entitled Decoupled Drupal in Practice, written by Preston So. It will give decoupled Drupal more reach and credibility.

When Preston asked me to write the foreword for the book, I jumped at the chance because I believe his book will be an important next step in the advancement of decoupled Drupal. I've also been working with Preston So for a long time. Preston is currently Director of Research and Innovation at Acquia and a globally respected expert on decoupled Drupal. Preston has been involved in the Drupal community since 2007, and I first worked with him directly in 2012 on the Spark initiative to improve Drupal's editorial user experience. Preston has been researching, writing and speaking on the topic of decoupled Drupal since 2015, and had a big impact on my thinking on decoupled Drupal, on Drupal's adoption of React, and on decoupled Drupal architectures in the Drupal community overall.

To show the value that this book offers, you can read exclusive excerpts of three chapters from Decoupled Drupal in Practice on the Acquia blog and at the Acquia Developer Center. It is available for preorder today on Amazon, and I encourage my readers to pick up a copy!

Congratulations on your book, Preston!

October 24, 2018

2 min read time

Oct 24 2018
Oct 24

Before beginning with the What and Why of Composer, let’s understand the difference between “Upgrade” and “Update”.

Drupal8MAin Image

Upgrading a Drupal website means migrating it to a new major version. For instance, moving from Drupal 6 to Drupal 7, or from Drupal 7 to Drupal 8. However, updating a website means moving it from one minor version to another. For instance, switching from Drupal 8.5.3 to Drupal 8.5.6.

Why Composer?

Are you familiar with Composer?

Composer is used as a dependency manager in PHP. It helps declare and manage libraries on which your project depends or the modules that your website is made of. You can easily manage core dependencies such as Symfony components and certain packages.

The first thing you need to do is ask yourself a question — Why do I require Composer when I can update the Drupal core and modules simply by downloading these from the Drupal website?

This is because updating your Drupal-powered website by downloading the modules from Drupal’s official website is not simple. The reasons:

  • A number of modules and themes cannot run the application without a third-party library. Managing the third-party library individually after installing the modules is a tedious task.
  • Some modules and packages need to be compatible with a certain PHP or Drupal version. This may lead to some version-related issues while upgrading the Drupal core and modules, which you need to find manually.
  • Some packages and modules may collide with each other when you run the composer update on the CLI. To fix the issue, you may need to review the composer.json file.

How to update Drupal core and modules using Composer?

Before beginning with updating your Drupal core and modules, you must learn about Composer. You can either refer to the documentation on Drupal’s official website or go for online tutorials.

The first step is to install Composer on your development machine to easily execute any Composer commands. It enables you to execute the installer directly from the command line.

The next step is to set up the website project template with Composer.

How to take a backup of the database and files before the update?

  • Take a backup of the database dump using drush sql-dump.
  • For backup of code and files, you can use drush archive-dump. It helps you take a backup in a single directory in Drush 8. However, if you upgrade the system or server using Drush 9, the command would not work, in which case you can use the tar command.

What Drupal core and packages are available to update?

  • Before you begin with updating your Drupal core and packages, verify which versions are available for update. Run the command Composer outdated in the command line interface, which provides a full package list, including the Symfony components, necessary for Drupal 8.


  • If you simply want to verify which Drupal core version is available for update, run the command Composer outdated drupal/*. It provides a list of all core versions that need an update.


How to update Drupal 8 core?

  • Begin with reading the core release notes to learn which issues are fixed in the release. It will help you understand which versions and packages need an update.
  • Use the command drush sset system.maintenance_mode 1 to activate the maintenance code. Clear the caches using drush cr.
  • Update the Drupal core and its dependencies, by running the Composer commands—Composer update Drupal/core –with-dependencies


  • To update any pending database, run the command drush updb and clear the cache using the drush cr command.
  • On the reports->available updates page, you can verify if the Drupal website is updated or not.
  • For error reporting and website testing, review the reports->status page.
  • Using drush sset system.maintenance_mode 0, deactivate the maintenance mode. Then, run the command drush cr to clear the cache.

How to update modules?

  • The best way to update modules on your Drupal 8 website is by using Composer. This is because Composer downloads the modules along with related dependencies needed to run the application.
  • The Composer command require “drupal/<modulename>:<version> is recommended to install a single module, where you can specify the module name and version. For instance, the command Composer require “drupal/social_auth_google:^2.0” helps download the Social auth login module’s latest 8.x.-2.0 release.
  • Social Auth Google module can be run using the third-party library League Google Provider for OAuth 2.0. Composer downloads the correct version of SDK, which is compatible with your module.
  • Finally, you can verify the League folder in the vendor directory.

This is how Composer makes it substantially easy to update Drupal 8 core and modules if you understand the basics of the technology.

Want to know more about our Drupal services? Contact us.

Oct 24 2018
Oct 24

At weKnow, we've been using Gatsby with Drupal for projects lately as our decouple strategy.

We decided to use the same approach for our personal blog sites, and the latest version of this blog was launched using GatsbyJS. What does this mean, We are no longer using Drupal?

Yes, for this site we are no longer using the Drupal theme layer, Twig, theme preprocessing, and the always loved/hated render array. All the frontend was done using ReactJS a modern JS framework.

And no, because Drupal is still used as the backend taking advantage of the JSON-API contributed module.

Why GastbyJS for the frontend?

  • Taking advantage of bleeding edge architecture to deliver a performant website.
  • Turn a content-driven website into a blazing-fast application by pulling data from Drupal and building a site using flat-files.
  • Deploy a site directly to CDN saving headaches and hosting costs.
  • Write all the frontend code using reusable components and a modern framework as React.

How fast is GatsbyJS?

Well after running an audit using lighthouse we obtain the following results.

lighthouse audit

No custom performance tasks are done yet, this is the out-of-the-box performance result by building the site using GatsbyJS.

Why Drupal as the backend?

  • Take advantage of Drupal content model capabilities, creating content types, adding fields, and configuration entities to manage site settings, media management among others.
  • Take advantage of Drupal as a Content Management System, add, edit, draft, publish and schedule content.
  • Take advantage of the acquired knowledge during several years of using the platform.

What were the challenges?

  • Make sure Drupal JSON-API returns markdown to take advantage of the gatsby-transformer-remark plugin.
  • Make sure inline images within markdown are processed using the gatsby-transformer-sharp plugin .
  • Deploy site to a CDN.
  • Execute build and deploy the site on demand and/or programmatically after updating data on Drupal.

Gatsby is taking the world by storm and the JAMstack is here to stay. Join me at my BADCamp session How to keep Drupal relevant in the Git-based and API-driven CMS era, to learn what can we do to keep Drupal relevant and this new era to find out how we solve all those challenges and to learn more about this topic and understand how to decouple the "Content Management" from the “Production Environment".

Oct 24 2018
Oct 24

Today I found another instance where I decided to use Illuminate Collections within my Drupal 8 code; whilst I was debugging an issue where a Drupal Commerce promotion was incorrectly being applied to an order.

No adjustments were showing in the Drupal UI for that order, so after some initial investigation and finding that $order->getAdjustments() was empty, I determined that I would need to get the adjustments from each order item within the order.

If the order were an array, this is how it would be structured in this situation:

$order = [
  'id' => 1,
  'items' => [
      'id' => 1,
      'adjustments' => [
        ['name' => 'Adjustment 1'], 
        ['name' => 'Adjustment 2'], 
        ['name' => 'Adjustment 3'],
      'id' => 2,
      'adjustments' => [
        ['name' => 'Adjustment 4'],
      'id' => 3,
      'adjustments' => [
        ['name' => 'Adjustment 5'], 
        ['name' => 'Adjustment 6'],

Getting the order items

I started by using $order->getItems() to load the order’s items, converted them into a Collection, and used the Collection’s pipe() method and the dump() function provided by the Devel module to output the order items.

  ->pipe(function (Collection $collection) {

Get the order item adjustments

Now we have a Collection of order items, for each item we need to get it’s adjustments. We can do this with map(), then call getAdjustments() on the order item.

This would return a Collection of arrays, with each array containing it’s own adjustments, so we can use flatten() to collapse all the adjustments into one single-dimensional array.

  ->map(function (OrderItem $order_item) {
    return $order_item->getAdjustments();

There are a couple of refactors that we can do here though:

  • Use flatMap() to comine the flatten() and map() methods.
  • Use higher order messages to delegate straight to the getAdjustments() method on the order, rather than having to create a closure and call the method within it.


In this scenario, each order item had three adjustments - the correct promotion, the incorrect one and the standard VAT addition. I wasn’t concerned about the VAT adjustment for debugging, so I used filter() to remove it based on the result of the adjustment’s getSourceId() method.

  ->filter(function (Adjustment $adjustment) {
    return $adjustment->getSourceId() != 'vat';


Now I have just the relevant adjustments, I want to be able to load each one to load it and check it’s conditions. To do this, I need just the source IDs.

Again, I can use a higher order message to directly call getSourceId() on the adjustment and return it’s value to map().

  ->filter(function (Adjustment $adjustment) {
    return $adjustment->getSourceId() != 'vat';

This returns a Collection containing just the relevant promotion IDs being applied to the order that I can use for debugging.

Now just to find out why the incorrect promotion was applying!

Oct 23 2018
Oct 23

This time I'll share some lessons learned on trying to optizime Apache Solr configuration from my n00b perspective.

First of all, I want to emphasize how cool and ridicilously easy it is to setup Apache Solr and get it up and running on a Drupal 8 site. This is was a real plug & play pleasure! :-)

Installation and basic configuration

But ok, I have to admit that I have "cheated" a little bit on the Solr installation itself. I have never done this and never tried to. Because this project is hosted on platform.sh, where you only need a handful of lines in two yml config files - where you just mention that you want to use Solr, what version and how you want to name the cores and endpoints - but the rest is done for you. This and your Solr configuration files is committed with your Git repository and platform.sh is doing the rest for you.

The second important factor in this plug & play game is the Search API Solr Search module for Drupal. The configuration is usability as its best. You don't have to know anything about Solr to get a basic setup up and running. You can define your Search API server config like you'll do it for the database backend, and afterwards you get download the zipped config files that you only have to copy into the appropriate directory on the Solr server. This and all other steps are well documented. In our case, I only had to add these files to our Git repository into the .platform/solr-conf/6.x directory and push the commit to trigger another build. This is f***ing amazing! (to quote Mike Skinner :D).

Playing around with synonyms

I was very happy about the first step to get this up and running so quickly. Then of course I decided to have a closer look at the configuration in order to tweak it a little bit. One big advantage of using Solr over a normal database backend is that you are able to define synonyms. In our example, we have an Austrian based online shop having a lot of terms used in the product catalogue that are more common in Germany than in Austria. Eg in Austria nobody would say "Rollbandmaß" to a tape measure, but rather "Rollmeter". We also call it a "Kübel", what Germans call "Eimer". This is the perfect use case for the solr.SynonymFilterFactory. And as the search_api_solr module already ships with the synonym filter factory in mind, all you have to do is to fill the synonyms.txt (or the synonyms_LANGCODE.txt for a specific language).... at least theoretically. I filled a few examples, and it seemed to work at first glance. On the next time, I wanted to sit down and add more entries, I struggled and I didn't have a clue why.

Debugging Solr

I needed a deeper inside what went wrong, so I needed to debug Solr but had no idea how - especially since I had problems on my Windows computer to open up a SSH tunnel to the site. So I asked on the platform.sh Slack channel, how I could debug Solr. Only a few moments later, Larry Garfield pointed me that I could workaround my tunnel problem by adding a route to the Solr core temporarily in my staging environment. This helped me lot, at least it got me a few steps further ahead on my journey. So big shout out to Larry Garfield for this :)

I was a little bit overwhelmed with the Solr admin UI though. I had a little insight into what is indexed, etc. But I still had no clue, how to best debug what is going on with my synonyms. I found my help on DrupalChat, where Markus Kalkbrenner gave me the missing links I needed. He's also the mastermind of the search_api_solr module, so another big shout goes to Markus Kalkbrenner (and to Fritz and Paul, whose tracks I thought would be the right musical accompaniment for this journey :D).

So I've verified the existence of the synonyms file in the "files" section, and afterwards used the analysis tool to see exactly what happens on index and query time. The analysis tool is quite easy to use. On the left-hand side you type in the value that gets indexed and which field type you are using, e.g. you type in the title of your product like it is entered in your Drupal database (eg "Rollbandmaß") and use "text_de" as field type. On the right side, you type in the search term you want to analyze, eg. "Rollmeter".

Pitfall number 1: the order of the filters matters!

Now I suddenly saw, what was going on. The indexing process is configured so that in the end various terms get indexed, all of them in lowercase. At query time, there's also a lower-case filter used, alongside the synonym filter and others. The shipped configuration however is defining the lower-case filter to be run before the synomyns filter. You can still define the synonyms filter to ignore case, but it always returns the values, how you define it. As I entered the words in the synonym file in correct German grammar, which means that nouns are starting with an upper-case letter, I didn't get any search results in the end. Because Solr was looking for an upper-cased word in a lower-cased index!

I had two possiblities then: either switch the order of the filters or enter all synonyms in lower-case. I've decided to do the latter, but that's just a matter of taste.

Solr synonyms filter and the expand attribute

There are two different syntax rules, how you can define synonyms for Solr:

  1. term => replacement
  2. term1, term2, term3

The first example is rather clear to read: everything on the left side gets replaced by term(s) on the right side. So you could e.g. correct mis-spellings, like "Flise" and correct it by "Fliese".

The comma separated syntax is treated differently. It depends on whether or not you define the synonyms filter to expand search terms. If you decide to expand, than all terms are treated equally. So, if you enter "term1", then "term2" and "term3" will also be searched for. If you do not expand, then it will only be searched for "term1". So "term2" and "term3" will get replaced by "term1". That's a huge difference.

In the default configuration of search_api_solr, the synonyms filter is configured to be expanded. But this leads us directly to....

Pitfall number 2: the data type of the XML attributes in Solr filter configuration matters

The search_api_solr module is generating bool attribute values in XML configuration files for Solr 6.x by default with integer values, like this: <filter class="solr.SynonymFilterFactory" synonyms="synonyms_de.txt" expand="1" ignoreCase="1"/>. But I observed that on our Solr 6.6.5 instance at least the "expand" attribute gets ignored this way. So I changed it to <filter class="solr.SynonymFilterFactory" synonyms="synonyms_de.txt" expand="true" ignoreCase="true"/> and it worked like a charm! Markus told me that this was changing a lot in the past, but should be stable now since Solr 6.4. So I opened up an issue on the Search API Solr Search issue queue. In the meantime you should ensure and test that your desired settings work as expected.

Excursus: defining the Solr configuration the right way

Here's a thing Markus mentioned to me, I first didn't recognize: although you could do it, you normally shouldn't directly manipulate the exported Solr configuration files. Instead there's an admin UI in the Drupal module for that. Advanced users can also directly edit the Drupal configuration files of course. This way, the information on the Drupal side is always in sync with that what happens on the Solr side, and whenever you export the Solr config files, you get the correct config without risking to lose any modifications. The only exception: if you are concerned by the issue mentioned above and it isn't fixed already, or at least a working patch available, then you have to do this smaller modifications directly in the Solr configuration files. But in general, it's advised to adjust everything on the Drupal side first!

Oct 23 2018
Oct 23

Congratulations to Victoria Spagnolo (quietone) for winning the Open Source Contributor award at this years New Zealand Open Source Awards for contributions to the Drupal Project and Drupal Migrate.

As someone that has made regular use of the Migrate module and the IRC and Slack channels Victoria's contributions to the modules and willingness to answer questions and engage with those of us needing advice and help is very much appreciated.  It's nice to see that being recognised in this way.

Oct 23 2018
Oct 23

PHP 5.6 will officially be no longer supported through security fixes on December 31, 2018. This software has not been actively developed for a number of years, but people have been slow to jump on the bandwagon. Beginning in the new year, no bug fixes will be released for this version of PHP. This opens the door for a dramatic increase in security risks if you are not beginning the new year on a version of PHP 7. PHP 7 was released back in December 2015 and PHP 7.2 is the latest version that you can update to. PHP did skip over 6; so don’t even try searching for it.

Drupal 8.6 is the final Drupal version that will support PHP 5.6. Many other CMS’s will be dropping their support for PHP 5.6 in their latest versions as well. Simply because it is supported in that version does not mean that you will be safe from the security bugs; you will still need to upgrade your PHP version before December 31, 2018. In addition to the security risks, you have already been missing out on many improvements that have been made to PHP.

What Should You Do About This?

You are probably thinking “Upgrade, I get it.” It may actually be more complicated than that and you will need to refactor. 90-95% of your code should be fine. The version your CMS is may affect the complexity of your conversion. Most major CMS’s will handle PHP 7 right out of the box in their most recent versions.

By upgrading to a version of PHP 7, you will see a variety of performance improvements; the most dramatic being speed. The engine behind PHP, Zend Technologies, ran performance tests on a variety of PHP applications to compare the performance of PHP 7 vs PHP 5.6. These tests compared requests per second across the two versions. This relates to the speed at which code is executed, and how fast queries to the database and server are returned. These tests showed that PHP 7 runs twice as fast and you will see additional improvements in memory consumption.

How Can Mobomo Help?

Mobomo’s team is highly experienced, not only in assisting with your conversion, but with the review of your code to ensure your environment is PHP 7 ready.  Our team of experts will review your code and uncover the exact amount of code that needs to be converted. There are a good number of factors that could come into play and affect your timeline. The more customizations and smaller plugins that your site contains, the more complex your code review and your eventual conversion could be. Overall, depending on the complexity of the code, your timeline could vary but this would take a maximum of 3 weeks.

Important Things to Know:

  1. How many contributed modules does your site contain?
  2. How many custom modules does your site contain?
  3. What does your environment look like?
Oct 23 2018
Oct 23

A full rebuild of a website can be a time consuming and expensive process. Upcycling is an incremental approach to relaunching existing websites. This blog will explain more about what upcycling is and why it might be the right choice for your website

Why upcycle?

Most websites will be rebuilt every three to six years to keep up with online trends, because of technical debt, or simply to refresh their appearance. At Amazee Labs, we have helped many clients transition from their legacy web systems onto Drupal 8 but not everyone is ready to do the move all at once. This is where upcycling can come into play.

As upcycling is intended to be an incremental approach it might not be suitable for every use case or every client. Upcycling de-prioritizes the “one-big-bang-launch-wow-effect” and allows us to partner with our clients to meet one primary goal: reduce time to market for big website improvements and maximising the value of time spent.

When to upcycle?

If you have a well-established web system that has been operational for several years, and you aren’t ready to spend the time and money to do a full rebuild, upcycling might be the answer.

Upcycling Process

As you can see, upcycling can be performed at any stage of an existing web project. Depending on the size of the upcycling project, we might transition from the maintenance and extension mode back to implementation. Alternatively you might do a smaller upcycling project within the maintenance & extension cycle. Large upcycling projects will often mean moving all the way back into a conceptual consulting & discovery mode before we start implementing new features or functionality.

What to upcycle?

We’ve designed an upcycling questionnaire to guide the conversation with the customer with regards to different aspects of the website. Although these are common areas for upcycling, we use this questionnaire as a starting point to discuss what will be the best fit for each project.  

Upcycling Areas

For each of these upcycling areas, we have a set of questions to validate the potential and& need for upcycling. For example, when we talk about designwith regards to design we would ask if the look and feel of the website is perceived as outdated or if there are any inconsistencies within the current design implementation.

If we identify an area that could benefit from upcycling a potential for upcycling in such area is identified, we will provide a set of recommended steps for improvement. In this case that might be a design refresh, establishing a design system, or rebuilding the frontend.

We also provide upcycling case studies to show our clients what is possible with upcycling, and help build on their ideas to improve their website without starting from scratch,

How to upcycle?

Upcycling demands that we are in a position to split things up.

An example is Sonova.com. The main website has been running on Drupal 7 since 2014. Last year, we started relaunching individual country pages using Drupal 8. These new pages allow the content managers on the client’s side to benefit from the better editorial features of Drupal 8 early on without needing to wait for a relaunch of the entire website. Gradually we keep relaunching country page by country page on Drupal 8.

Upcycling Sonova Drupal 7

Sonova Country Page Version in Drupal 7

Upcycling Sonova Drupal 8

Sonova Country Page Version in Drupal 8

The next step in upcycling this site will be a relaunch of the main website on Drupal 8. When we are ready for that step we can build upon the incremental steps we started for the country pages.

As well as the additional editorial features, we also worked with the client to choose a different Drupal theme. . This means sites running on Drupal 7 feature a different design than the sites running on Drupal 8. So instead of merely optimizing for consistency across all country pages, together with the client, we chose to allow to innovate and bring newer design versions to the local markets without waiting for the relaunch of the whole site.

How does upcycling relate to decoupling?

If your site has some complex backend logic that you don’t want to rebuild but you are eager to relaunch the frontend, upcycling could be the solution. Usually, we would relaunch the frontend within Drupal’s theme layer. But in certain cases, it makes sense to relaunch the frontend as a decoupled site and then integrate the existing backend. We recently did this for a customer that wanted to get started with Drupal 8 but had some complex Drupal 7 Backend logic that needed to be maintained.

On the other hand, if the backend really needs an overhaul and you want to keep the existing frontend without rebuilding it, upcycling could work for that too, after decoupling the backend.

Decoupling your architecture will enable you to upcycle individual parts and bring value to the end user faster but it also comes at a price of added complexity. In the end, it’s important to compare the advantages and disadvantages

Pros of upcycling Cons of upcycling

Get the most out of your existing website infrastructure

Benefit from user experience, design or frontend performance improvements without the need to wait for a big relaunch

See your investments as quickly as possible

Potentially added complexity when maintaining two systems at once.

Potentially inconsistencies in the appearance if sections are upgraded separately.

Partly you need to invest into a legacy platform rather than spending everything on the new one

More details on upcycling can be found in this presentation.

What’s your experience & challenges when it comes to upcycling? Do you have an existing project that you would like to improve? Let us know in the comments or reach out via the contact form.

Oct 23 2018
Oct 23

Drupal Modules: The One Percent — Termcase (video tutorial)

[embedded content]

Episode 49

Here is where we bring awareness to Drupal modules running on less than 1% of reporting sites. Today we'll investigate Termcase, a module which formats the capitalization of your taxonomy terms.

Oct 23 2018
Oct 23

In the video below we will show you how to create an interactive and informative content based on a couple of xls files and a handful of images using just CKEditor wysiwyg.

ckeditor to content screenshot

Our goal is to create a demo article with info on emperor pinguins, containing an interactive chart, a map and a gallery. For that we are using just functionality provided by VisualN modules pack (with a couple of generic dependencies).

[embedded content]

* Actually opening and closing dialog window before embedding a drawing is not really required - drawings can be embedded at saving clicking 'Save and embed' or updating the list clicking 'Update list' and then the 'Embed' button. Though there is a Drupal core issue that should be fixed.

The structure of xls files is as follows (the last screenshot also represents images used):

Excel file containing colonies demo data Excel file containing colonies demo coordinates Images for colonies demo gallery pinguin colonies demo datapinguin colonies demo coordinatespinguin colonies demo gallery

Each xls file contains a plain data table. The first row is used for data keys. Generally it can contain any keys - remapping is shown in the video. Actually remapping is required only for the first demo_data.xls file, since data_coords.xls keys already coincide with those used by LeafletMapBasic drawer.

The configuration steps and other details are subject for upcoming articles series.

All the drawers used in the video are provided with the VisualN contrib module. You can also see them in action based on generated sample data at https://visualnxpress.com. Feel free to subscribe for updates. Also it serves as an example of using different resource types (i.e. generated data instead of xls file) with the same drawer showing how flexible and resource-type agnostic drawers are.

Coming up series:

  1. Getting started
  2. Creating visualization styles
  3. Creating drawing (entity) types
  4. Configuring VisualN Embed integration with CKEditor
  5. Using VisualN Excel module for Excel files support
  6. etc.
Oct 23 2018
Oct 23

By Veronica WheelockMarketing | October 23, 2018

By Veronica WheelockMarketing | October 23, 2018

Autumn is in the air… and part of the weKnow team is heading to BADCamp18, each one of them excited to share experiences, our team culture and contribute to strengthening ties among the members of the Drupal community.

BADCamp 2018

This is a very special BADCamp edition as it sets a milestone in weKnow’s journey. Back in 2011, this was one of the first Drupal events that we attended in the USA. This year we increased the number to 8 attendants and we proudly became one of the event’s sponsors.

BADCamp is simply the biggest DrupalCamp in the world, reporting 1,300 attendees in 2017 and featuring Summits, Sessions and training in benefit of the open source community. The event will be held at UC Berkeley from October 24th to 27th, 2018.

WeKnow’s team at BADCamp is backed and led by our CTO Jesús Manuel Olivas, one of the co-maintainers of the Drupal Console. He will be speaking on the hottest topics of the event: Decoupled Drupal, APIs, React and GatsbyJS, don't miss his session How to keep Drupal relevant in the Git-based and API-driven CMS era.

Sponsoring an event like this is the best way we found to support countless developers from all around who believe in the strong values of a collaborative and open source community.

This is weKnow’s full roster for BADCamp 18:

BADCamp 2018 weKnow Team
  1. Jesús Manuel Olivas / CTO at weKnow Inc.
  2. Omar Aguirre / Products Division & DevOps
  3. Jorge Valdez / Drupal Full Stack Developer
  4. Joseph Zamora / Drupal Frontend Developer
  5. Miguel Castillo / Drupal Backend Developer
  6. Harold Juarez / Drupal Full Stack Drupal Developer
  7. Manuel Santibañez / Drupal Full Stack Drupal Developer
  8. Heissen Lopez / Drupal Frontend Developer

We hope to meet you there!

Big or Complex Project,
Not Enough Devs?

We help development teams meet their deadlines by seamlessly integrating our highly skilled developers.

Oct 23 2018
Oct 23

Sometimes you may need to import data from a CSV file into Drupal.

We've spoken with OSTraining users who need to import from another CMS, and uses who need to import from a business spreadsheet.

There is no easy way do this import using the Drupal 8 core. To import your data from a CSV file, you need to install and enable the Content Import module.

In this tutorial, I'll walk you through the process of importing data with Content Import.

In this example, we'll import data into a "Customer" content type. This Customer content type will have the following five fields:

Field Name Field Description Field Type Title

The name of the customer / this is the default Drupal title field for each content type

Plain text Body Customer information Long text Contract Date The date when the contract with the customer was signed In the mm/dd/yy format Customer Picture The picture of the customer Image Discount This field indicates if the customer qualifies for an extra discount at the end of the year Boolean (Yes/No)

Step #1. Create the Customer content type

After creating the Customer content type and adding fields, you will have the following starting point:

Starting point

There are some details that you have to take into account to run this process without complications:

  • The date field has to be set as Date and time (this is related to the Unix timestamp. You can read more about this here).

Setting the Date Type

  • When creating the Customer Picture image field, configure the file directory for the images as [MACHINENAMEOFYOURCONTENTTYPE/images] You’ll upload your images to this directory with the help of the IMCE module or some kind of FTP software

Configure the file directory for the images

  • Set the On and Off labels in your Discount boolean field to Yes and No respectively

Set the On and Off labels

Step #2. Prepare your spreadsheet for import

You can use the spreadsheet application of your liking for this. I’m using Google Spreadsheets. The langcode column is mandatory

Importing to Drupal from Google Spreadsheets

  • Save your spreadsheet as a Comma Separated Values file. Once you do, your file will have a .csv file extension.

Save file in CSV format

Step #3. Upload the profile pictures to the specified directory

With the IMCE module:

  • Go to yoursite/imce in order to open the IMCE browser
  • Create the /customer folder inside the public directory
  • Create the /images sub-folder inside the /customer folder
  • Upload the profile pictures to this folder by clicking the Upload button on the top (/customer/images folder in our case)

New folder

Upload button

Uploaded profile pictures

Step #4. Import your content from the CSV file

  • Click Configuration > Content Authoring > Content Import

You will see a screen with two options.

  • Select the Customer option for the Select Content Type
  • Click on the Upload File button
  • Select the CSV file on your hard drive
  • Click Import

Click Import

Congratulations! If you followed along with my instructions, you should now see the Content screen of your Drupal installation with your newly imported content. 

Troubleshooting Your Drupal CSV Import

While importing content, you may run into the following error on the white page:

"The website encountered an unexpected error. Please try again later."

To deal with this error, please do the following:

  • In your Drupal site root go to modules > contentimport > src > form
  • Open the contentImport.php file in your text or code editor
  • Find the following two lines (around line 275):

$dateTime = \DateTime::createFromFormat('Y-m-d h:i:s', $data[$keyIndex[$fieldNames[$f]]]);
$newDateString = $dateTime->format('Y-m-d\Th:i:s');

Replace them with the following two lines:

$dateTimeStamp = strtotime($data[$keyIndex[$fieldNames[$f]]]);
$newDateString = date('Y-m-d\TH:i:s', $dateTimeStamp);

You’ll find more information about this error here.

I hope you enjoyed this tutorial.

If you want to learn more Drupal, join OSTraining now. You'll get access to a vast library of Drupal training videos, plus the best-selling"Drupal 8 Explained" book!

About the author

Jorge lived in Ecuador and Germany. Now he is back to his homeland Colombia. He spends his time translating from English and German to Spanish. He enjoys playing with Drupal and other Open Source Content Management Systems and technologies.
Oct 22 2018
Oct 22

NASA’s Jet Propulsion Laboratory (JPL) needed to automate an internal document approval process where any given launch of the workflow could:

  • Have unique and a varying number of approvers.
  • Abort the approval process immediately upon a single approver rejecting, even if other approvers have approved or have yet to view the document.
  • Re-route rejected documents to the initiator of the approval process.
  • Upon all assigned approvers approving the document, route the document to completion, notifying stakeholders in the process.

Using Drupal and Nextide’s Maestro workflow module, JPL was able to prototype a base workflow template to automate their process.  However, the missing element was the ability to implement a workflow that allows for on-the-fly selection of approvers, the number of approvers and managing the acceptance and rejection of the document.


The Issue

Maestro supports the ability to assign a single unique instance of a task to one or more users dynamically.  In this scenario a single task would be created with multiple users assigned to it, however, the first person to complete the task would complete it for everyone assigned. This produces a “one task, one user completes” scenario regardless of how many people were assigned to the task. JPL’s requirement was the need to assign a multiple number of unique instances of the same approval task to a set of users and continue the workflow past the multiple-assignee stage when all tasks are approved or a single task is rejected. 

In a standard workflow template, the workflow administrator would logically build the template accounting for the tasks required and who is assigned to those tasks. 

Figure 1 - Typical Workflow Approval TemplateFigure 1 - Typical Approval Workflow Template

To illustrate the problem, Figure 1 shows a simple (and non-functional!) approval workflow template with four approvers.  The template is like most other simple approval processes, however, JPL’s issue was that you never know how many approvers will be assigned to any given document.  In the shaded area of Figure 1, you see four tasks: Approval 1 through 4.  This is optimal if you always have four approvers.  JPL required a dynamic number of approvers, each with their own task.  What if there were five approvers required?  What if there were three?  Ten?  The issue for this use-case is that dynamic assignments and rigid templates are not the answer.

The Solution

Our solution was to get Maestro to spawn a variable number of sub-approval processes as required by the initiator.  The parent process was able to spawn as many child approval processes as required, and each child was able to signal its completion, accepted or rejected status to the parent.

Figure 2 - Our Solution TemplateFigure 2 - Simplified Workflow Solution Template

Figure 2 is an over-simplified representation of the workflow for JPL.  The workflow template shows the parent process which is responsible for spawning the n-number of approval sub-flows and waiting for the sub-approval flows to be approved or rejected before continuing on.

Figure 3 - JPL Data FlowFigure 3 - JPL Data Flow

Figure 3 illustrates how the parent process and the child communicate with each other using the Maestro API.  The parent is able to spawn sub-flows, while the sub-flows are able to communicate their approval status back to the parent.  The “Wait” task in the parent process is able to detect if all sub-flows are complete or if a sub-flow has signalled a rejection.

The Outcome

The workflows were put into production, successfully automating an internal business approval process for JPL.  The shuffling of paper, sending manual emails to people, and the complete lack of visibility of where processes stall has been eliminated.  Using our workflow as a base, JPL has automated a number of other internal processes.  Letting Drupal manage the content and Maestro manage the business process has proven to be a success.

Need Automation?

Do you have manual processes that are slowing your business down? Do you still have untapped areas for business improvements?

Oct 22 2018
Oct 22

We made many important improvements to Drupal Commerce over the summer, including an improved promotions UI, BOGO offers, and product category conditions in the 2.8 release and full list price support with the 2.9 release. After a long sprint to the finish, we’ve now finally released 2.10, one of our largest releases to date that resolves 39 issues and feature requests.

Product administration improvements

Six years ago we released the first stable version of Commerce Kickstart 2.x and the new (at the time) Inline Entity Form module, which allowed us to manage multiple product variations from a single product page form for the first time. Since then, Inline Entity Form has become a popular Drupal module and a recommended way to manage products in Drupal 7. When we started developing Commerce 2.x for Drupal 8, we ported over Inline Entity Form and the previous approach to managing products, but now we’re ready to take another step forward to advance the usability and performance of product management.

As of the 2.10 release, product variations are managed on their own tab of the product page form. This follows the same UI pattern we established for coupons within the promotions UI.

Product variations shown on their own tab.

Moving variations to their own tab allows us to extend the UI in future releases, specifically to add bulk operations for tasks such as price updates, image replacement, and even the creation of a full set of variations. We foresee other modules adding their own elements to the tab, like the Commerce Pricelist module adding a “Prices” dropbutton item to provide quick access to every price for a variation on multiple price lists.

Having variations on a separate tab would be a bit much for products that always only have a single variation, so we’ve made sure to accommodate that use case in the new version. Each product type’s settings form includes an “Allow each product to have multiple variations.” option that when disabled reverts to the inline editing experience for products of that type.

Inline product editing for single variations.

Query access filtering

If you create a new role for your merchant and only give it the “Book: View products” permission, you’d expect users with that role to be able to book products but no others. In Drupal 7, our solution for this was a generic query access API in Drupal Commerce itself that filtered entity loading queries based on user permissions.

To achieve this same result in Drupal 8, we've rebuilt this API and added it to the recent 8.x-1.0-rc1 release of the Entity API module. Commerce is now using it for administrative listings of products, orders, and stores. The API adds a QueryAccessEvent to allow modules to alter the access conditions, making it possible to apply further filtering (e.g. only show the user’s own store). Next we will extend the filtering to Search API to filter customer facing listings.

User-driven API improvements

Over 4,000 websites have launched on Commerce 2.x in the past year, pushing us up over 6,000 in total. As developers launch their projects, we keep our lines of communication open to hear about all the things that annoyed or hindered them, and we work to improve our APIs as a result. Several examples that made it into this release include:

(Note that as a result of the last two, if you have overridden the PaymentInformation or PaymentProcess panes on your site, you will need to update them for the new release.)

We love to hear stories of the great things you’re doing with Drupal Commerce, and we’d also love to improve the core APIs and data model to better support you, too. Feel free to join us and hundreds of other developers in the #commerce channel on Drupal Slack for real-time discussion or post your proposals directly to the issue queue for discussion.

Oct 22 2018
Oct 22

Lately, we've been using Gatsby with Drupal for projects where we need it decoupled.

Gatsby is a unique project. It's most often evaluated as a static site generator compared to the likes of Jekyll and Hugo. While Gatsby can generate a static website, it's more accurately described as a content mesh.

Gatsby uses GraphQL to pull in one or more sources to generate site content. There is a large list of Gatsby source plugins including: Drupal, WordPress, YouTube, Twitter, Hubspot, Shopify and Google Sheets just to name a few. It's optimized for blazing fast performance. Since it's built using React, it can be used to build hybrid sites. Along with generating static pages it can also render client-side content. It can pull in dynamic data, add password protected content and take advantage of features typically not found in static generated sites.

Similar to Drupal, Gatsby is open source. It has a devoted and ever-growing community, with an expanding plug-in library which makes building your site even easier.

With this combination we can leverage Drupal as a content authoring platform and utilize Gatsby to render the frontend.

The screencasts below show how quickly you can configure a Drupal 8 website to pair with Gatsby.

[embedded content]

With our Drupal 8 website set up, the next step is to configure Gatsby to pull the Drupal site's content.

[embedded content]

In my next blog, I'll be covering how automate your Drupal to Gatsby content deployment to Netlify.

Download a Transcription of this Screencast

Download Transcription

Oct 22 2018
Oct 22

Agiledrop is highlighting active Drupal community members through a series of interviews. Learn who are the people behind Drupal projects. 

This week we talked with Janne Kalliola. Janne does not code, but he is a very active Drupal community contributor. Learn about CEO dinners he helps organize and what would he be working on, if he had an extra day between Thursday and Friday.

1. Please tell us a little about yourself. How do you participate in the Drupal community and what do you do professionally?

I’m Janne Kalliola, the founder and CEO of Exove, a digital growth company headquartered in Helsinki, Finland, and offices in London, Singapore, Tallinn, and Tampere and Oulu in Finland. I’ve been coding since 1983 and made my first commercial software product in 1991, while in high school. Before founding Exove, I’ve worked at a university, SSH, Telecom Middleware company, and MySQL clustering company.

Nowadays my coding is limited to a few selected clients of Exove and some hobby projects, due to time limits. Being a father of three adorable children and a CEO of a company is now more important than coding.

In the Drupal community, I focus mostly on the business community composed of various C-level people and directors of companies working with Drupal. I am at the board of both Finnish and Estonian Drupal associations and was one of the organisers of Drupal Europe. Exove and One Shoe from the Netherlands organise annual Drupal Business survey that sheds light on how Drupal companies are doing globally.

I and Michel van Velde from One Shoe also organise an annual Drupal CEO Dinner in every DrupalCon Europe. It has become a tradition of open speech, peer support, and gossiping between CEOs in the Drupal community. Being a CEO can be very easily quite a lonesome work, as you cannot share your worries, vulnerabilities, and concerns fully with the rest of the organisation. Only a person in similar position understands the pressure of the work, and being able to talk about it – at least once a year – is very crucial for the mental wellbeing of company leaders.

2. When did you first came across Drupal? What convinced you to stay, software or the community, and why?

We bumped into Drupal in 2007, when a partner of Exove asked whether we could help one of their clients with Drupal related matters. I surveyed our staff of seven (or so), and our CTO Kalle Varisvirta told that he had some experience with the system. So, we accepted the gig and built our first Drupal site. The project was a success and could not have been done with WordPress that we already mastered back then – and still do. After the first one, it was quite easy to convince the next clients, and gradually we have become one of the largest Drupal agencies in the Nordic countries.

The “tipping point” for me, in the community context, was the first CXO event, organised by Kristof van Tomme of Pronovix in Brussels in 2010. I met a number of Drupal agency leaders, including Michel from One Shoe, and found out that they are open, focus and compassionate. The event is still one of my fondest memories of the business community, and it made the biggest impact on my company. I am also quite an outspoken person, so I made an impression on others, too. From that event forward, I’ve gained new acquaintances and also friends at such events.

Now I’m preaching about growth to the Drupal companies. You could call it a passion or a mission of mine. Larger and stronger companies can create and sustain the growth of Drupal, as we pay most of the salaries of the community at the end. The better the companies are, the better the situation is for the whole community.

3. What impact Drupal made on you? Is there a particular moment you remember?

On the technology side, I’m constantly impressed on Drupal’s ability to tackle bigger and bigger cases – more information, more languages, more functionality, more people, more servers, etc. – without showing wear and tear. There are numerous other content management systems, both open and closed source, that would break under such stress, but Drupal just keeps on delivering. Further, the versatility of the platform is a huge bonus, too. The open-endedness of the platform allows us to grow it to the exact direction our clients want without causing havoc with the architecture.

Speaking of community, I really love the openness and empathy of the people. There have been some rough times in the past, but the community has come together time after time, resolved the issues and moved on.

The past Drupal Europe conference was the most positive conference I’ve ever experienced, and it sort of encapsulated the positive tenets of the community.

I already mentioned the first CXO event that was a huge experience for me. My first DrupalCon in Chicago 2011 is very memorable and of course, all CEO dinners we have had during the years, have been exhilarating experiences.

4. How do you explain what Drupal is to other, non-Drupal people?

Drupal, the technology, is a well-balanced combination of a content management system, application platform, and e-commerce framework, that is a great foundation for delivering digital experiences that bring digital growth.

Drupal, the project, is one of the largest open source projects that has produced an enterprise-grade software product while keeping the community engaged and approachable.

5. How did you see Drupal evolving over the years? What do you think the future will bring?

I think that Drupal is going in the right direction. Drupal 8 was – and still is for some companies – a painful transition, but now we reap the benefits of the change.

I’m most excited about the e-commerce capabilities and the new upcoming administration user interface facelift that changes the way, how we humans interact with the system. The JSON API layer is one of the key components to allow embedding Drupal into larger IT architectures, and also creating huge potential for rich end-user interfaces with modern JavaScript technologies.

6. What are some of the contribution to open source code or community that you are most proud of?

As said earlier, I don’t code that much anymore. My contributions are thus on the community side. Organising CEO dinners, Drupal Business surveys and local and regional DrupalCamps are the visible highlights of my contributions.

The less visible work is helping other companies, Drupal Association, and the project lead Dries Buytaert with various items – typically related to growth, opportunities, or health of Drupal companies. I do this with one-to-one discussions and participating in BoFs. People already know that I don’t hesitate to say my opinion, and I’m becoming better at listening to others and drawing conclusions to get the momentum going.

7. Is there an initiative or a project in Drupal space that you would like to promote or highlight?

Drupal marketing, both in global and local context, needs more effort. The system is too good not to be known by a wide range of people. Everyone needs to do better here and participate in the effort to create a positive spiral, that strengthens itself with every cycle.

8. Is there anything else that excites you beyond Drupal? Either a new technology or a personal endeavorment. 

I am blessed with three magnificent children. Seeing them growing and learning every day, makes me so proud and humble simultaneously.

The same can be said about my company. I am blessed to work with such great and friendly colleagues - I learn from them something new every single day.

If I had more time – like an extra workday between Thursday and Friday – I would work more with modern JavaScript. It is moving at the speed of light nowadays, and there are so many great things happening just right now.  

Oct 22 2018
Oct 22
I've been interested for some time in this whole idea of decoupling Drupal and decoupled architectures: collecting links, ideas, videos, and anything that I considered useful. Here is my list. I hope you find something useful, maybe not :-).Question: Decoupling Drupal… Wait, What? Why? When?In a few words, decoupling is good because:
Oct 22 2018
Oct 22

Rotary is a global network of 1.2 million neighbors, friends, leaders, and problem-solvers united by one goal: unite people and take action to create a lasting, meaningful change. It is a non-political and non-sectarian organization open to anyone, regardless of their race, color, creed, religion, gender, or political reference. Rotary consists of 34,000+ member clubs worldwide, as well as 1.2 million individuals, known as Rotarians, who all work towards solving important global problems, such as: fighting disease, growing local economies, promoting peace, providing clean water, saving mothers & children and support education. 
The object of Rotary is to encourage and foster the ideal of service as a basis of worthy enterprise and, in particular, to encourage and foster:

  • The development of acquaintance as an opportunity for service.
  • High ethical standards in business and professions, the recognition of the worthiness of all useful occupations, and the dignifying of each Rotarian's occupation as an opportunity to serve society.
  • The application of the ideal of service in each Rotarian's personal, business, and community life.
  • The advancement of international understanding, goodwill, and peace through a world fellowship of business and professional persons united in the ideal of service.

Rotary chose Drupal as the primary CMS for their website due to its flexibility and extensibility. The wide variety of modules and distributions assist Rotary with the best web technology solutions for providing, managing and distributing content.

7. Global Impact | Charity.org

Oct 22 2018
Oct 22

Inheriting from Symfony (in principle but not implementation), Drupal 8 allows us to define certain services as lazy. Why? Well why the hell not?!

Sometimes, our services get big. Not necessarily in the number of things they do (hopefully not) but in the time it takes for them to get instantiated. As you know, when we define a service and make it a dependency of something else, the service container will instantiate that service and inject it where it is needed. And this happens whether on that particular request that service is used or not.

For example, let’s imagine you have a Controller with 2 public methods used for 2 distinct routes. Most likely, when one method gets hit for the route, the logic of the second one doesn’t run. And even if only the second one depends on an injected service, the latter gets instantiated in both cases regardless.

Of course, for “popular” services like the EntityTypeManager or form builders this is not a big deal. For one, they are probably going to be instantiated anyway for other parts of the request. And second, they are not expensive to construct. Well, they probably are but anyway, see point 1. However, if we have our custom service as a dependency which is used only for that one route, it doesn’t make sense to have it instantiated for both routes. Especially if it is expensive to do so — heavy on resources. Enter lazy services.

Lazy services basically “tell” the container:

Ok, I need to be injected, sure, but unless I’m not used, please don’t construct me… mkay?

So how does this work in practice? Let’s see an example.

Assume this service:

namespace Drupal\module_name;

class MyHeavyService implements HeavyServiceInterface {

   * This be slow.
  public function __construct() {

   * Does something, doesn't matter what.
  public function doSomething() {}

A few things to note here:

  • It’s important to have an interface. Without one, this won’t work. You’ll see in a moment why.
  • The constructor does, for some reason, take an expensive nap.
  • It’s not important what the API of the service does.

For such a service, the normal service definition would look like this:

  class: Drupal\module_name\MyHeavyService

If we inject this into our Controller, any request which uses the latter will instantiate this service as well — which costs us 4 seconds a pop. So to make it lazy we just have this instead:

  class: Drupal\module_name\MyHeavyService
  lazy: true

Lazy services work by way of proxy classes. Meaning that for each service that is declared lazy, the container expects a proxy class which is responsible for decorating the original one and only instantiate it if any of the public APIs are requested. But don’t worry, we don’t have to write another class. We have a PHP script provided by Drupal core that does this for us:

php core/scripts/generate-proxy-class.php 'Drupal\module_name\MyHeavyService' 'modules/custom/module_name/src'

The script takes two parameters:

  • The namespace of the service we want to create a proxy for
  • The location where it should be written

Do note that proxy classes are dumped automatically into a ProxyClass folder located at that specified path. So this is what gets generated for our service at modules/custom/module_name/src/ProxyClass/MyHeavyService.php:

// @codingStandardsIgnoreFile

 * This file was generated via php core/scripts/generate-proxy-class.php 'Drupal\module_name\MyHeavyService' "modules/custom/module_name/src".

namespace Drupal\module_name\ProxyClass {

     * Provides a proxy class for \Drupal\module_name\MyHeavyService.
     * @see \Drupal\Component\ProxyBuilder
    class MyHeavyService implements \Drupal\module_name\HeavyServiceInterface

        use \Drupal\Core\DependencyInjection\DependencySerializationTrait;

         * The id of the original proxied service.
         * @var string
        protected $drupalProxyOriginalServiceId;

         * The real proxied service, after it was lazy loaded.
         * @var \Drupal\module_name\MyHeavyService
        protected $service;

         * The service container.
         * @var \Symfony\Component\DependencyInjection\ContainerInterface
        protected $container;

         * Constructs a ProxyClass Drupal proxy object.
         * @param \Symfony\Component\DependencyInjection\ContainerInterface $container
         *   The container.
         * @param string $drupal_proxy_original_service_id
         *   The service ID of the original service.
        public function __construct(\Symfony\Component\DependencyInjection\ContainerInterface $container, $drupal_proxy_original_service_id)
            $this-&gt;container = $container;
            $this-&gt;drupalProxyOriginalServiceId = $drupal_proxy_original_service_id;

         * Lazy loads the real service from the container.
         * @return object
         *   Returns the constructed real service.
        protected function lazyLoadItself()
            if (!isset($this-&gt;service)) {
                $this-&gt;service = $this-&gt;container-&gt;get($this-&gt;drupalProxyOriginalServiceId);

            return $this-&gt;service;

         * {@inheritdoc}
        public function doSomething()
            return $this-&gt;lazyLoadItself()-&gt;doSomething();



As you can see, we have a simple decorator. It implements the same interface and has the same public methods. The latter, however, are derived automatically from the service class and not the interface. And basically, the container is injected and used to instantiate the underlying service the first time any of the public methods are called. If none are called in that request, it won’t get instantiated.

I mentioned above that having an interface on the service is necessary. The reason is that when we inject it somewhere, we need to type hint the interface. Otherwise, the container would pass an instance of Drupal\module_name\ProxyClass\MyHeavyService which is not the same as the original Drupal\module_name\MyHeavyService.

So now, we can inject it, type hint it with the interface and it would only get instantiated if any of the public methods are called. Neat no?

The responsible for making all this happen is the Drupal\Core\DependencyInjection\Compiler\ProxyServicesPass compiler pass. Looking for service definitions that have been marked as lazy, it creates a new identical service definition (non-lazy) which uses the proxy class and adds that to the container instead. It’s actually not rocket science if you look at the code.

And like many things, just because we have this available, it doesn’t mean we should use it for every service we write. Remember, if you create services used all over the place, this is useless. The criteria for whether to make your service lazy should be:

  • Is it heavy to instantiate (depends on a bunch of other services which in turn are not super popular either)?
  • Is it ever instantiated for no reason?

Hope this helps.

Oct 22 2018
Oct 22
How to Create a Customer Service Request Form in Drupal 7

An OSTraining member has asked us how to achieve the following in Drupal 7:

  1. A customer fills out a form to send their request for repair or service on a specific piece of equipment.
  2. A customer service agent comments on the request to either approve or deny it.
  3. The customer gets an automatic email after his request has been processed.

In this tutorial, you will look at this use case. You will learn how to achieve these requirements by creating a node.

My first thought was to do the job by collecting the data requests with the Webform module. I thought I would convert this data into nodes, so it can be then processed with the help of Views.

This is possible with the help of the Rules and the Webform Rules module.

However, there’s a less complicated process if you let your customers create a node. The main advantage is that you avoid the complex conversion step in the first place.

It also makes no sense to mix up your form submissions with your content, it’s easier to create a node instead of creating a submission and converting it into a node.

Let’s start!

Step #1 - Create a “Support Request” Content type

  • Click Structure > Content types > Add content type.
  • Uncheck Published and Promoted to the front page.
  • Close comments.
  • Leave the Author and date information (this is relevant information since you’re letting your customer create the node).
  • Leave the Main menu as default.


  • Click Add field and follow this structure:
 Field name  Type  Widget  Values  Device  List (text)  Select list

1) Dishwasher

2) Oven

3) Refrigerator

 Request status  List (text)  Select list

1) Pending*

2) Approve

3) Denied

 Required field.

* Default value.

 Additional comments  Text  Text field  Max length is 3000


Step #2 - Restrict access to certain fields

You certainly don’t want your customer to change the status of the request.

Also, the field additional comments are meant to be used by your employees.

To hide this fields from the user, you’ll have to download and enable the Field Permissions module.

  • Download and enable the module with your preferred method.


  • Click People > Permissions > Roles. 
  • Click edit permissions on the authenticated user line.


  • Look for the Support request: Create new content permission and check it.


  • Click Save permissions.
  • Your customer can now create nodes of type Support request on your site.
  • Click Reports > Field list > Permissions.
  • Look for the fields you want to revoke.


  • Click on each link (both fields).
  • Choose Custom permissions.
  • Click Save settings.


Your customer can now create a node (in the frontend of the site). Notice that the customer won’t have access to the backend because you haven’t granted those permissions.

  • Create an authenticated user and log in to another browser.
  • Click the Add new content link.
  • Fill out the node “form” and click Save.
  • Check the Content link in the browser you’re logged in to the site.

Excellent! The first part of the task is accomplished! Let’s move on.

Step #3 - Retrieving and processing the nodes

You can filter all support requests in the content view page, this is ok if you have 10 nodes.

But if you have more requests and some of them have already been approved or denied, then it’s not a practical way to select only nodes with status “Pending”.

For that purpose, you’ll have to create a view. Install and enable Views and Views UI if you haven’t done yet.

  • Click Structure > Views > Add new View.
  • Create the view Support requests - Older first.
  • Click Continue & edit.


  • In the Filter Criteria section click Content: Published and set its value to No.
  • Click the Add link.


  • Search for the Request status field and choose it.


  • Click Apply (all displays).
  • Choose Is one of and Pending.


  • Click Apply (all displays) again.
  • Save the view.
  • Now you have access only to those requests with pending status.


The employee can click on the link to have access to the full node, from where they can edit it. They have to approve/deny the request.

Otherwise, it will still be appearing in this view. So it’s a good thing if this view is empty (if you trust your employees).



Good job! That was the second part of the task.

Step #4 - Send the customer an email with the help of Rules

  • Install the Rules module and all its dependencies.
  • Enable Rules and Rules UI.
  • Click Save Configuration and Continue.


  • Click Configuration > Rules > Add new rule.
  • Give your rule a proper name.
  • Choose React on Event > After updating existing content.
  • Restrict by type > Support request.
  • Click Save.


  • You have now an Event.
  • Click Add condition.
  • Leave Data comparison.
  • Click Continue.


  • The Data selector value is node:field-request-status.
  • Click Continue.
  • Test the Approved value first.
  • Click Save.


  • Add another condition testing the Denied value.


  • Now click Add action.
  • Select Send mail from the dropdown list.
  • Configure the action with the help of tokens (replacement patterns).
  • Click Save.


From now on, your Drupal site will send the corresponding user an email, each time a support request is processed. Congratulations!

I hope you liked this tutorial. Thanks for reading it!

Additional Reading

If you want to learn more Drupal, join OSTraining now. You'll get access to a vast library of Drupal 7 training videos, plus the best-selling"Drupal 7 Explained" book!

About the author

Jorge lived in Ecuador and Germany. Now he is back to his homeland Colombia. He spends his time translating from English and German to Spanish. He enjoys playing with Drupal and other Open Source Content Management Systems and technologies.
Oct 21 2018
Oct 21

Wouldn’t it be nice if you could add any block you want to your paragraphs?

In years past, layout for Drupal has been in the hands of front-end developers, but over time various modules were developed that provided site-builders the ability to adjust the layout. An improvement yes, but there still wasn’t a clear cut option that empowered content editors to alter the layout during the editorial process.

Look out! Here comes the Paragraphs Module. This module has been taking the Drupal community over by storm because it allows content editors to add pre-designed components which gives each page the option to have different layouts. One of the limitations of the Paragraphs module, is that each paragraph can only be used once, and only for the current node you are editing. This means that you can’t re-use a common paragraph such as a call to action block, email signup or contact us form, so you end up finding yourself duplicating a lot of work if you want the same block on numerous pages. While the Drupal community has been working to help solve this problem by allowing the re-use of paragraphs, there are still going to be plenty of situations where you want to insert custom blocks, views, or system blocks such as the site logo or login block.

How do you allow your site editors to add re-used blocks into their content during the editorial process?

Let me introduce you to the Block Field Module. Maintained by the one and only Jacob Rockowitz (you know the webform guy ), you can be assured that the code follows best practices and that there will be support. The block field module allows you to reference any block regardless of where it is coming from and the best part, you don’t have to create some hidden region in your theme in order for the blocks to be rendered.

There are plenty of awesome articles out there that explains how to use paragraphs so I won’t get into that. To follow along with my steps be sure to have downloaded and enabled both the Paragraphs and the Block Field modules.

Steps to Add Blocks to Paragraphs

  1. Download and Enable the Paragraphs and Block Field modules.
  2. Create a paragraph type called Block Reference (or whatever name you want)
  3. Add a new field, by selecting the Block (plugin) field type from the dropdown and save it.
  4. Go to manage display and make the label hidden. 
    I always forget this step and then I scratch my head when I see the Block Ref field label above my views title.
  5. Now go to back to your content type that has the paragraph reference field and ensure the Block Reference paragraph type is correctly enabled. 
    The content type with the paragraph reference field was not covered in this tutorial.
  6. When adding or editing your content with a paragraph reference field. Add the Block Reference paragraph type. Select the name of the block that you would like to reference from the dropdown hit save on the content and watch the magic happen.

In conclusion, it does feel a little scary giving content editors this much freedom so it will be imperative that all views and custom blocks have descriptive names so that editors can clearly identify what blocks to reference. Overall I feel like this is a good solution for referencing existing blocks that can save a lot of time and really unleashes the power of the paragraphs module. The Drupal community continues to amaze me!

Oct 20 2018
Oct 20

“Alone we can do so little, together we can do so much” 
— Helen Keller

Authored by Gábor Hojtsy, Meike Jung, Baddý Sonja Breidert, Floris van Geel, João Ventura, Surabhi Gokte, Andriy Iun, Lars Stadel Linnet, Rachel Lawson and Stefan Auditor

“In his Driesnote he also talked about the Drupal Europe [leads] and it was really impressive because he invited all the organizers of Drupal Europe up on stage, and all of us in the audience gave them a big round of applause. It was a standing ovation for the team. It was really special and I think it was nice to honor them the privilege to see how important they have been for the Drupal community. They’ve done such a good job. […] Standing in the audience […] it was so emotional.” — Podcast hosts https://drupalsnack.se/drupalsnack-81

“Drupal Europe […] was an outstanding conference like no other. The feeling of being part of the community and working towards common objectives is indescribable and very motivating. The event ran seamlessly and provided value to all participants thanks to the highly driven and competent organizers.” https://thunder.org/thunder-drupal-europe-darmstadt

“I am amazed for sure. I did not know what to expect when I came to Drupal Europe. […] By coming here I was just blown away by how professional it is, how involved everyone is, how dedicated everybody is. So I wanna give a big thanks to all the organizers. […] It’s clear that they have gone out of their way to make this Drupal Europe the event of the year.” — Michael Miles in https://drupalsnack.se/drupalsnack-81

“When we put out a conference like this, we come all together. […] There is a whole spectrum that you can do in the community. And they come all here together. We have other events where maybe the people who are interested in frontend go or those who are interested in backend go. But Drupal Europe or DrupalCon Europe, these events bring us all together. […] It is exciting!” — Baddy Sonja Breidert https://drupalsnack.se/drupalsnack-81

“Darmstadt was far from tourist attraction (I’ve been to DrupalCons in Barcelona, Prague, London, Vienna etc) and for me Drupal Europe was equally as good yet far more accessible to all. I had excellent community conversations and did great business too. Works!” https://twitter.com/pdjohnson/status/1041088750544203776

“On a personal note, I thank you all for your warm welcome and letting me be part of an awesome experience I will never forget. Your contribution makes a difference, it did for me and I’m certain for many others.” https://twitter.com/KenMunene/status/1041651771146416128

“It was lots of fun and new learning at Drupal Europe. Thanks to all the volunteers for tirelessly working in making it successful event. This event has really set higher benchmark for future Drupal events.” https://twitter.com/mohit_rocks/status/1041546210258157568

“Just another day in the park, a Chinese, a Syrian, an Indian and Ethiopian playing basketball in Germany. Once in a lifetime experience!” https://twitter.com/tsegat/status/1040261120664252416

“As a graduate of TU Darmstadt [across the street] I’ve always dreamed of visiting Darmstadtium as a conference speaker. Thanks to Drupal Europe this dream came true! This was an amazing conference at an amazing venue. Thank you for having me!” https://twitter.com/hchonov/status/1040641366609588224

“1.5 years ago I was part of the very hard decision to not do a DrupalCon 2018 in Europe. I always hoped that the Drupal Community will step up and organize something themselves. But Drupal Europe exceeded all wishes and hopes, a very very big thank you to all involved people ❤” https://twitter.com/Schnitzel/status/1040907413703073792

“[…] It was hands down the best Drupal event I have been to! Thank you so much for the organization team and the volunteers! You are the heros!”


“Thank you so much to the Drupal Europe organizing team and everyone who attended! This was an amazing week and I enjoyed every minute. […]”


“This Drupal Europe has been the best conference I’ve ever been to, of any kind. There is not a single thing I would have changed from start to finish. It’s the people. You are all fabulous. Every single one of you” https://twitter.com/rachel_norfolk/status/1040707031093727232

“This Drupal Europe has been a really special event. Thanks to all the volunteers that have invested so much time on it: a big event like this is really needed to keep the ball rolling.”


“‘The Drupal community is an optimistic one and I love that’ — So says @sparklingrobots and after two days here I can confirm the feeling. Loved every minute I had at Drupal Europe” https://twitter.com/FrancescaMarano/status/1040178911265652737

“The passion, energy and sense of inclusion within the Drupal community has amazed me this week. Loving my first Drupal Europe experience!”


Statistics image by Meike Jung

Why Drupal Europe?

From the first DrupalCon in 2005 in Antwerp, the community self-organized to put on events for itself. Some events where lead by specific companies (DrupalCon Szeged or DrupalCon DC for example), while others were collaborations within the community. As the conferences grew very big and more and more professional, no collaboration of people could take on paying the unimaginable amounts of bills (especially up front) and no company wanted to take on the risk of losing a million euros. The Drupal Association gradually took over the logistics parts and then most of the organization of programming other than sprint teams and track content. However, the Drupal Association needs to make money to pay its bills, keep drupal.org up and organize all its other activities for promoting Drupal. DrupalCon was/is a key income source for the Drupal Association so if DrupalCon is not making money that is a problem.

It turned out in 2017 that when staff costs are factored in, DrupalCon Europe was not making money for the Drupal Association (while DrupalCon in the United States did, providing 45% of the total income of the Drupal Association by itself). Megan Sanicki wrote a very detailed blog series that gives a lot of insights into the finances and goals of DrupalCon. In summary DrupalCon Europe cost the Drupal Association around a million euros to put on and instead of making money, it lost around 15% of that consistently. So based on those facts the Drupal Association decided to put the event on a pause while something more sustainable is figured out.

A group of community members were selected to form a committee to help define what DrupalCon is, so a licensing scheme can be devised for event organization companies to apply to organize DrupalCon Europe instead. If this scheme is to work well, then this could bring DrupalCon to further regions of the globe as well. Some people thought if the event is losing money why would anyone sign up to do it and thought this is a cop-out.

Even if this was to be a hope of a long term solution for Europe, we’ve experienced a lot of sadness and outrage at the time at events and online forums in Europe. According to Dries Buyatert’s stats at the time, almost 45% of Drupal contributors are European with the United States a distant second at 29%. Many felt that the Drupal they helped create makes the Drupal Association money in the United States so contributors and users have a chance to meet there, but the substantially bigger contributor community in Europe (who in no small part made Drupal possible in the first place) lost that opportunity. In this light, we did not agree with the consideration of the two DrupalCon events on their own terms, in that profits from the United States would not be brought to compensate losses in Europe, but at the same time we did not wish cuts at any other parts of the Drupal Association which would have been necessary to offset for the situation.

All in all we needed to take the Drupal Association decision and see what we can work out in that situation. Literally as the news hit, DrupalCamp Antwerpen was happening and various attendees of the camp immediately rallied together to skip sessions and discuss the situation and plot a path forward. Those participating showed great interest in maintaining a large event in Europe but recognised the need for that event to look for different ways to achieve results. It wasn’t enough to just continue as we have before.

The discussions continued at the DrupalCon Vienna community summit and then BoFs throughout DrupalCon Vienna. Ideas ranged from making existing camps bigger, switching to university venues, changing the format drastically, buying a big tent and so on. One of the BADCamp lead organizers David Hwang provided lots of input and encouragement. Read the massive notes document of 17 pages detailing various discussion points.

Ultimately we agreed that we need a melting-pot type of event where developers get inspired by Drupal used for fun projects, customers get inspired by the community spirit and how things are made, designers, translators and marketing folks could productively participate, and so on. DrupalCon Vienna ended with a decision that we are going to organize the event, but we did not yet know anything beyond that.

Distributed online team

We set up an online team of leads on google drive for document sharing and used Slack for chat because that was readily available on drupal.slack.com. We regularly had issues with the disappearing history, had to copy conversations to documents and re-explain things but this was the common denominator we could work with and we were not into revolutionizing the chat system used by Drupal but to put on a conference. We wanted to pick our battles. We used Jitsi for video meetings which worked great on desktop and iOS, people on Android had regular issues though. A bit later, by the time the conference happened, the Android client got more stable as well.

The tools we struggled with most were project/task management. We started using Trello, but left it largely unused and grew out of due to the complexities of the project. We started using OpenSocial but did not have people to actively nurture communities there and abandoned that too. We set up OpenProject on our own servers to rescue ourselves but also left that largely unused. At the end we kept each other in check on our meetings and used various spreadsheets to move processes. It was (not surprisingly) hard to get volunteers to track their contributions in project management software.

Photo by Gábor Hojtsy

Later on when tasks were too complicated for one group to handle, we branched out to a web team, program team, volunteer leads team and lead organizer team each with their own meetings, but still kept the all-team weekly meetings going for over a year until the conference was over. We did not have a team/meeting structure for people working on sponsors, financials, venue/catering, attendee care and communications. Those were discussed more ad-hoc as needed and mostly managed by the respective single person responsible for them.

The web team had great success using GitLab’s issue tracker to track issues and do QA and integration of features developed on a staging site. In the lifespan of the website we developed two different versions, the initial simple version being a manually updated static brochure website and the second being a full-fledged Drupal 8 website.

Email was an important tool, too. It was a good decision to set up dedicated IMAP accounts early that could be shared by working groups. Ticket sales/attendee care, sponsoring, and volunteer coordination are some examples where this approach was really rewarding (especially when you cannot rely on a single person monitoring a mailbox full-time).

With the European General Data Protection Regulation (GDPR) coming into full effect in May obviously many web workers (i. e. most team members) had a focus on implications for our tools. We were not perfectly set up for this (using data storage hosted outside the European Union and obviously handling personal data) but we did the best we could for privacy protection. We deliberately did not ask for any personal data other than information we needed for the ticket and to communicate with attendees. We did not send personal data in webform submission notifications. We used tools with GDPR certifications for ticket sales and emails. We did not sign contracts with all site administrators who had access to user accounts, which would have been needed strictly speaking, but we made sure to have a common privacy understanding in the team and limited critical access.

Hello World

We posted our Hello World post a week after DrupalCon Vienna announcing that we are on it because

  1. We wanted an event which brings together the European Drupal community.
  2. We wanted to make sure that the European market sees that Drupal as a technology is a strong brand.
  3. We wanted to prove our community that we can do this conference sustainable and cost effective.

We were primarily looking to solve the financial problems by choosing less fancy venues and not providing food.

It was also very important for us to state that we are not doing this to set up a parallel Drupal Association and we fully intended to collaborate with the Drupal Association. While we did not (intend to) use the DrupalCon brand, the Drupal Association helped us with a lot of historic data, spreadsheet templates, email samples, etc. that sped up a lot of our work and provided key insights to plan our financials. They also helped with our marketing through the Drupal Association channels and drupal.org frontpage. The Drupal Association also needed a place to hold the board meeting and board retreat and organized that around and at Drupal Europe as well.

Settling on a venue

We launched our call for venues two weeks later (which had outstanding results) alongside a call for swag that we could sell and make early money (which did not work). The call for venues had some outstanding results with the following city submissions:

  • Germany
    - Darmstadt
    - Friedrichshafen
    - Mannheim
  • The Netherlands
    - Amsterdam
    - Utrecht
    - Zaanstad (north of Amsterdam)
  • Belgium
    - Antwerp
  • Scotland
    - Edinburgh
    - Glasgow
  • Poland
    - Kraków
    - Wrocław
  • Czech Republic
    - Brno
  • Australia
    - Newstead, Victoria

After all if Australia can participate in the Eurovision song contest, why not have Drupal Europe there, right? ;)

We asked a lot of questions about the venues, and most would have been great in some way for our event. We spent a lot of time discussing various options and locations considering to avoid conflicts with events like IronCamp and Frontend United. We posted an enthusiastic update in November and as you can see there we’ve still been experimenting with how to approach the conference model and proposed a version that got significantly amended later.

We planned to confirm and announce the venue mid-December, but that did not happen before mid-January when we announced our venue and dates.

While most of the venues proposed could have worked, we choose Darmstadt because it provided a good combination of an amazing venue in a very accessible location combined with reasonable venue pricing. It was definitely not a less fancy venue as we set out to have, but the pricing was fair. It was a key deciding factor that the German community not only suggested us the venue but they were ready to stand behind the event and serve as the fiscal entity. While Drupal Europe Stichting has been set up in October in Eindhoven to possibly serve as a backing entity, it did not have staff or experience putting on events and had no reserves in the bank. We also talked to the Drupal Association to serve as the fiscal entity, but as they wanted to avoid losing money and we had no guarantees to not do that, that was also a no-go.

Given how amazing was the venue, we found it surprising that we got it for a reasonable price for this week. We thought that the venue would be hard to work with or there would be lots of hidden costs, so we carefully examined all potential charges listed. We did not find anything hidden and they were very positive and supportive of us. Later on we did find out two issues:

  1. This week clashed with important religious holidays including Rosh Hashanah, Hijra and Ganesh Chaturthi. We did not consider these date conflicts, which speaks to the lack of cultural diversity in the organization team at the time. We regret that some of our (potential) community members could not attend due to these conflicts. One of our volunteer leads celebrated Ganesh Chaturthi at Drupal Europe and helped us become a lot more aware of this religious celebration. Organizers of international events should use http://www.interfaith-calendar.org/ or an equivalent and also consult people to get more context to each holiday/celebration listed especially their significance.
  2. This week also clashed with the Automechanika expo in Frankfurt, which draws 136.000 visitors who take over hotels in the cities around Frankfurt as well. Despite the plenty of hotel rooms normally available in Darmstadt downtown, it is hard to compete with that demand when you are a comparatively tiny conference of at most a couple thousand people. This turned out to cause problems for accommodations for our attendees (but read on later) and even for some of our bigger exhibitors as they had a hard time to find companies to do booth buildup.

Event organizers with a more diverse team would have definitely avoided this week as they would be aware of both conflicts before booking. If we would have known, we would not choose Darmstadt as this was the only complete week available with only 9 months to go before the event in this venue.


Darmstadt downtown nearby the venue — photo by Jean Fenouil

Darmstadt being a city of 160k people with a sizable university population with the venue located right downtown resulted in an atmosphere where you can go out for dinner and probably bump into another group of Drupal Europe attendees. Randomly meeting other attendees was the norm.

The close proximity of the Frankfurt airport was a big plus. A direct airport bus is running between the venue and the airport normally every 30 minutes daytime. And there are power plugs and free wifi on the bus, how is that for a great arrival / departure experience?


While we sometimes felt like mere “conference organizing enthusiasts” in discussions with Darmstadtium, our partnership turned out to be very productive. They worked with us to find the best solutions for our problems within the frameworks they were able to offer. We ended up almost booking the whole venue (except one big auditorium) and basically took over the building for the week. They gradually understood more and more of our diverse program elements and what each meant to us. They even took care of little details like setting the led lighting on the infodesk to the conference’s brand color for the week.

Photo by Jean Fenouil

The venue was very well received by our attendees, especially the natural light in the atriums and most rooms. Even one of our contribution rooms had a huge glass wall letting in natural light and direct street access to get some fresh air.

“We are really digging the venue of Drupal Europe. Large open spaces and some really stunning architecture. […] Our team can’t seem to get over the sheer beauty of the Drupal Europe venue. It’s truly stunning […] Really thankful to Drupal Europe for the great choice!” https://twitter.com/Srijan/status/1039511199312822272 and https://twitter.com/Srijan/status/1040253518798577664


The hotel situation might have cost us a considerable number of potential attendees as the above mentioned expo resulted in many big hotels completely booked by automotive companies. We attempted to negotiate group rates for room blocks in hotels but they said there is no such option for this week as the rooms will be booked either way. And indeed that came true.

We started calling out the issue publicly as early as May telling people to book hotel rooms anticipating this problem, but understandably many people did not yet know if they would attend as no program was available yet, people did not know if they are going to speak or not, etc. Later on some feedback indicated that our calls for hotel room booking was not alarming enough early enough.

Drupal Camping photo by Floris van Geel

After the issue was raised in our Slack channel, several volunteer initiatives started right away and all options were immediately reflected on the web site:

  • Some team members researched hotels farther away and looked up alternative booking portals, even called up remote hotels to reserve room blocks. We did not end up offering those blocks as they were only accessible with cars and the reservations were only valid very short term which did not let us develop a solution to distribute them.
  • A Google map with train stations was set up to indicate towns outside Darmstadt with only a few minutes to reach by train to assist extended accommodation search.
  • Some locals started a couchsurfing channel to share sleeping space available within the Drupal community locally.
  • A group of volunteers started organizing a camping site on drupalchat.me. The so-called Drupal Camping turned out to be quite an attraction with an event bus. We had to cope with very strict german rules, so after 10 pm it was “Nachtruhe”, meaning that we had to skip the bonfire and party elsewhere at the lake to enjoy our music and the stars without bothering other guests. Even with the 60 Drupal people we had at the camping on Tuesday we managed not to get kicked out and in the end be happy campers with not so much troubled camping owners.

Drupal Europe brand

Alongside the call for venues, we also launched a call for designers. While we had a temporary logo right away, we needed a complete brand we can use for the website, roll-ups, stickers, track icons. Our call for designers received many great submissions.

Sample submissions from Aline Skibitzki, Steffen Belz, and sixeleven srl respectively

After thorough discussions we decided to partner with sixeleven srl in Italy, the same company that designed the DrupalCon and Drupal Dev Days Milan brands and work forward from another brand proposal they sent. Sixeleven delivered a brand manual with fonts and colors and worked with us designing the sponsor brochure, stickers, PDF schedule, etc. We also had two designers on the lead team who produced matching designs for the lanyards, rollups, digital signage, further website elements, etc. which worked in perfect unison with the sixeleven designed items.

Social media, giving Drupal Europe a voice

We knew from the get-go that we need to be active on social media. And in fact through the year we posted over a thousand tweets on https://twitter.com/DrupalEurope. We made several announcements on Twitter exclusively especially before we had attendees we could send emails to. We kept posting more detailed posts to our Medium blog, but daily news were delivered over Twitter. While we hoped to be able to, once we had our Drupal website, we did not integrate the blog or the social media channels there, so our Twitter feed was more like the source of the most up to date high level news source while our website was best to review all available information.

While Twitter is quite popular in “insider” Drupal circles, we hoped to reach out of those. We also set up our Facebook presence which replicated a lot of the Twitter messaging and we also had a LinkedIn page that did not get much activity though. Further attempts were made with Xing.com, a dedicated Meetup account, an event page on Airbnb and probably some more volunteer-based initiatives. The idea was to drive interests from various platforms to the channels where we were actually providing information at. None of these approaches were very effective in part because we did not have the resources to keep them up to date.

While we ran a very small ad campaign on Facebook and a bit bigger one on Twitter targeting technology people in the region, we did not seem to succeed with reaching outside of our regular reach with them so abandoned the idea to spend money on them.

Finally we thought it is important to have a consistent social media voice so our Twitter account was managed by a single person. We made sure to make the biggest noise about all the things that helped build our credibility at the start and then things that demonstrated our value provided. Some people considered our social media activity too chatty but it definitely helped give a familiar voice to the conference that was not too formal and contributed to the community camp feel of the event.

Websites and the process of getting them ready

Credits Drupal Europe Web team

As mentioned earlier, over the span of the year we had two different websites. The initial website was a Symfony 4 based HTML-landing page. The other was the full Drupal 8 site with workflows, user generated content and so on, that turned out to be more complex than we initially anticipated.

HTML-landing page

Starting with the simpler of the two first, the goal there was to put together a quick and simple website, just to tell the world that we are here, who we are and what we want to achieve.

It was initially created on the 13. October 2017, in a very simple and slim version, which gradually evolved. We stopped development on it on 17. May 2018 and it was replaced by the Drupal 8 website shortly thereafter. Statistically we had 226 commits over the period, giving an average of 1 commit per day. 8 people contributed to this site with 85% of contributions from 3 contributors.

Using Symfony 4 as a midway point between a fully-fledged website and a simple HTML website worked out quite well, there was a slight overhead to it, but that was mitigated by it providing benefits in regards to asset handling with automated optimization of js, css and image sizes.

Commits graph from GitLab styled by Meike Jung

Drupal 8 website

We explored a lot of different approaches to building the website, the big contenders were CoD, RNG and even using Commerce as a base for the event — but quick prototyping using those approaches did not provide a useful shortcut to a complete website. Ideally CoD for Drupal 8 would be our go-to choice but that was not yet mature enough when we needed it.

We then decided to decouple the ticketing system from the website and later investigate the possibilities of integrating it into the website, which simplified what the website had to do. We ended up going with a setup that required a lot of configuration, but very little custom code for handling the functionalities — we also went at it with the mindset that what we build was not meant to be reusable so if a shortcut was taken that would be okay as the website wasn’t going to live more than a little over a year.

We took good care to make the website responsive and support features we needed with webforms, field permissions and an extensive set of content types, views and paragraphs. We even powered the digital signage in the venue off the website, read on that later.

Ticket sales from Pretix styled by Meike Jung

This website received a total of 795 commits between March 5 when we started its repository until September 26 when our last commits happened as of this writing. That comes down to almost 4 commits per day. There were 17 contributors to this website, the top 3 contributors made 83% of the commits.

Initial release of the Drupal 8 website

While we did not intend to create a reusable website by any means, we realize people may learn from how we did things. So we published the whole source code at the end of the conference at https://www.drupal.org/project/drupaleurope_website. We are not going to support this project, it is merely posted as an example, however other event organisers may want to pick this up and bring it further or cherry-pick some ideas for their websites.

Timing and the website

A look at the calendar can be treacherous when you still have so many months to go until the event. We started too late with defining milestones which put us in tight situations during the course of building the website. At a time when the website team was still evaluating Drupal distributions, it turned out that a placeholder website was not enough to serve the changing requirements during preparation of the event.

We wanted to publish information about sponsorships and found out after a while that it would really help convincing others to show some early sponsors. We wanted to start selling “early supporter” tickets and offer a corresponding badge for download (and optimally already link sold tickets to a user account). While we kept updating the brochure site, that took time away from volunteers’ building the Drupal 8 website. Many little holdups resulted in a really tight timeline before the event. We could not allow much time for session confirmations and we were way too late to use featured speakers for serious marketing on the site.

Verticals as our final program concept

We arrived at our final program concept by the beginning of March. We’ve had lots of discussions with community members to try to solve the life and death problem of DrupalCon Europe that the customer attendees are not there because there is not targeted content for them and sponsors are not there either because they cannot sell to customers as much as in the United States as a consequence. While this is in part a result of how Europe is different culturally from the United States, we could refocus the program on users of Drupal to work around this a bit. We’ve seen the summit model working very well at the beginning of DrupalCons (so much so that DrupalCon Seattle in 2019 is going to dedicate one more day to summits) and we thought we turn that around and organize the program around industry verticals.

Some of us met and sat down at the DrupalCon Nashville sprint to refine the concept and match to possible schedules and room allocations. We published our industry verticals at end of April (and posted the photo above). Our industry verticals where

  • Digital Transformation + Enterprise
  • Government
  • Healthcare
  • E-Commerce
  • Higher Education
  • Publishing + Media
  • Social + Non-profit
  • Infrastructure (later expanded to DevOps + Infrastructure)
  • Drupal Community
  • Drupal + Technology
  • Agency Business

We were still assembling a track team at the time. Ultimately we were more successful with some of the topics than others. Healthcare was least successful and needed to be removed with the sole session we accepted from it transferred to Digital Transformation + Enterprise. Drupal + Technology received the most submissions by far.

We hoped to recruit sponsors for tracks as well but that did not work out too well. Only one sponsor bought a specific track sponsorship and the two diamond sponsors used their track sponsorship option. In hindsight the track sponsor packages were not necessarily providing comparable benefits to similarly priced other packages.

“One of my favorite Drupal Europe things was the eCommerce track. Normally a DrupalCon has one, if even two — or even none. There were TEN sessions about Drupal and eCommerce. I wish more events would reach out to this vast market.” https://twitter.com/nmdmatt/status/1040885627309441024

Session tagging

Alongside the verticals we also announced session tagging. We provided a way for speakers to add arbitrary tags to their sessions which we lightly edited later for consistency (eg. title casing them). No limits were provided for tags as we believed tags would give more details about sessions even on skimming the list. They provided a great cross-section of content to browse with, for example looking at all security sessions at https://www.drupaleurope.org/session-by-expertise/security shows content from building secure containers through writing secure code to the The OpenEuropa Initiative. These would not have been in the same track at a traditional DrupalCon. We pre-created tags with the traditional track names and some technologies and tools we expected would show up to inspire submitters.

Session tagging was then also adopted by BADCamp for 2018 and for DrupalCon Seattle in 2019 with a somewhat different approach, picking up to three tags from a predefined set.

Code Sprint Contribution

This question bugged some of our leads for a while.

DrupalCon already replaced “code sprint” with “sprint” some time ago, recognizing that this activity was not only about development but also about translations, design, marketing, and even planning for future development. Still the “sprint” terminology was so firmly established in the Drupal community that it looked hard to change, even though still not representing the activity too well and confusing for newcomers.

It is not a “sprint” where a backlog of sized stories is used to form a set of tasks that a given team of people commit to deliver in a timeframe and then release / demonstrate. The backlog is fluid, the team is fluid and the timeframe is fluid, while the work may or may not be committed and released. It is also not a sprint in the sense of needing to run real fast and getting very tired at the end. At DrupalCons there was usually a segment attempting to introduce the concept before every keynote and as part of the closing keynote explaining around the misleading terminology. Also sprint is not necessarily something that people associate with working on marketing materials together or do project planning. Why not change the terminology to begin with then?

Contribution is a dictionary word that is more natural to understand, more inclusive to different energy levels and types of work. It does not sound (and does not have the history of being) so attached to code development only. So from March onwards we decided to change the terminology and drop “sprint” entirely in favor of contribution. Contribution day, contribution room, contribution mentoring, etc.

The change was in no small part inspired by WordCamps having Contributor days. We decided to use contribution day rather than contributor day as it sounded slightly more inclusive of new contributors, i. e. not the day of those who are contributors (already). Also contributor room, etc. could have othered contributors as if other rooms or sessions are not for them.

Almost empty contribution room on Monday morning — photo by Gábor Hojtsy

Several sponsors signed up to support contribution, two of which also got to name our two week-long contribution rooms. Feedback about the natural light as well as all day coffee/tea and snacks in the contribution area was really good.

“I arrived with some question-mark-salad in my brain and left Drupal Europe with the proud feeling that I contributed to this community, that I now understand what kind of issues this community also faces and that I really can help to find solutions for those issues as well. I am a part of it, so I will contribute.” https://www.drop-guard.net/blog/johannas-first-mentoring-and-contributing-experience

“I love the emphasis on “contribution day” and “contribution space” rather than “code sprint” at Drupal Europe. OSS contributions comes in many shapes and sizes. And representation matters.” https://twitter.com/eojthebrave/status/1039505954138611713

Mentored contribution

We worked with the existing (also volunteer) contribution mentoring team from the start to carry the tradition of mentored contributions on Friday. Altogether 40 people signed up to be mentors at Drupal Europe.

Many people raised before that if they arrive on Monday without experience, they feel out of place then as mentoring only happened on Friday usually. Contributors working on specific areas often only have dedicated time at events like this to work on issues all day and are therefore not often easily or practically approachable to mentor new contributors on Monday. So we discussed with mentors that some of them would be available on Monday already to introduce new contributors to the Drupal processes. We were happy to see a couple people tweeting they enjoyed this. While it is easy to say that full mentoring from Monday onwards would be useful, it also falls on volunteers with limited capacity.

We also provided a mentor’s table in the exhibition space out of our budget and helped provide mentor supplies for Friday. Due to some miscommunication, not all regular mentor table equipment was ready from our side on Monday, but we managed to solve that throughout the week. We also provided the usual eight free mentor ticket codes for volunteers who primarily attend to mentor so they don’t need to even pay for their ticket to contribute. These tickets were distributed by the mentoring leads.

Mentors usually have custom t-shirts provided by the event but this time we did not have the budget nor the possibility to have the right sizes and fits collected and shirts ordered based on them in time, so mentors printed their own green ribbons which were used to identify people doing mentoring especially on Friday but also throughout the week. Compared to the shirt, the benefit of ribbons were that they were more reusable for multiple days and were possible to combine with all kinds of clothing styles.

On Friday we provided space for the usual three areas:

photo by Gábor Hojtsy)
  1. First-time contributors workshop where Drupal processes and tools are introduced to participants (see photo on the left)
  2. Mentored contribution to put that into practice with actual tasks; helped out by mentors
  3. General contribution with topic teams working together to solve ongoing tasks such as media management, modern admin UI, search API, MongoDB, Drupal demo, etc.

We also recognized contribution day itself needs more work to be well organized for non-code contributors as well. We discussed with mentors to structure the introduction in a way that is modular based on the tools needed for specific tasks. However, more effort and processes need to be in place to have recurring translation, marketing, design, etc. teams at contribution days. We set up the #contribution-funnels Slack channel on drupal.slack.com following contribution day to improve on this.

All-in-all there was so much interest in contribution on the Friday that we needed to expand the available space considerably on the spot and ask the venue to set up a whole new hallway with tables and power strips. The new contribution area was available in less than 15 minutes.

Contribution days also provide rare opportunities for lead Drupal contributors to meet face to face and discuss topics important at the time. Drupal Europe provided space for many of such important meetings and was hopefully useful in moving those initiatives forward.

Admin UI and JavaScript modernization team meeting photo by Gábor Hojtsy

“So many contributors today, really looking forward to see the aftermath! Big thanks to all the mentors, who kept a happy face till the end!” https://twitter.com/rouvenvolk/status/1040696363053473792

Initial audience survey

We also launched our initial audience survey in March. We got 92 responses, which may not be highly representative but the people were quite varied from project managers to site builders to frontend developers. It was clear from the results that people thought DrupalCon was awesome (39%) or at least all right (28%), while 20% of our respondents did not even attend a DrupalCon yet. There was no single other event that all the people responding to our survey could meet at. People liked how DrupalCamps feel, but were not concerned of event size as long as they can meet their peers there.

A sample reason why DrupalCon is the best: “I got to meet people from a wide variety of countries, companies, roles, and also friends from the US who only ever travel over to Europe for the big DrupalCons.” Likewise, “Being part of the community” was listed as the top reason to participate for 40% of our respondents, followed by attending sessions which was top priority for 27%. Interest for business, content and editorial as well as showcase sessions were highest. People were evenly distributed among looking for Drupal speakers and speakers from other areas.

75% of respondents said there should be workshops and/or trainings. We did not ask specifics about costs associated which was an oversight. Read on later about workshops and trainings.

40% of the respondents said they’d rather not get a goodie bag and free t-shirt. On the other hand 42% said free coffee and tea all day should be offered. Only 14% said we should reduce the ticket price and not have coffee and tea at all. In terms of lunch, 38% said they are fine with “venue food” (a further 31% even said they would pay extra for better food at the venue), while only 17% said we should not offer lunch and reduce ticket prices instead. The respondents of course did not yet know what kind of “venue food” to expect in Darmstadt.

All in all, the survey confirmed our goal with creating an event that brings the various folks of Drupal together to meet and inspire each other, as well as our focus on industry case studies. On the other hand, our initial cost cutting ideas about catering were not validated.

The first European Splash Awards

At the end of April alongside the industry verticals, we also announced that we’ll hold the first European Splash Awards. While we thought of it as a social event at first, later on we realized it had a lot of value built into the main program as a keynote.

Splash Awards originates from The Netherlands where in 2014 local companies realized they need more celebration of the great projects built by companies. Later on the format was licensed for local awards ceremonies in Germany and Austria, Norway, Bulgaria, Denmark, France and Romania. In Eurovision style we wanted to bring the country-awards together for a European Splash Awards to showcase the wide variety of highly professional projects built with Drupal. This lined up perfectly well with our industry tracks as we attempted to steer the conference towards showing the real business value of Drupal more. It was a logical step to integrate it into our schedule as a keynote. The variety and quality of nominees also impressed Dries Buytaert sitting in the front row:

“Congratulations to all the Splash Awards winners at Drupal Europe! Such an impressive list of brands and innovative Drupal use cases.” https://twitter.com/Dries/status/1039417091571507203

Photo by Paul Johnson

We believe there is a lot of possibilities for improvement in the presentation of the awards, but we got a lot of good feedback on the format already. More countries are looking to host their own Splash Awards next year and DrupalCon Seattle even includes Splash Awards as a program item now. We are looking forward to see how that turns out in the United States.

Driesnote and the Prenote

Other than ensuring Dries can make it to Drupal Europe, we did not need to do much for the Driesnote. Once realizing the date conflicts with religious holidays on the beginning of the week, we moved the Driesnote to the middle of the conference so everyone had the chance to attend or at least view the stream.

Dries was very professional about the preparation and ran a test of the Driesnote on Monday. It was maybe his most action-packed keynote ever with announcements about Drupal 7 and Drupal 8 end of life and Drupal 9 release dates; a perfectly flowing demo of Drupal 8.6.0; extended Drupal 8 security support; video updates on various initiatives; announcing that drupal.org will adopt GitLab and that DrupalCon is back in Amsterdam in 2019. Phew!

Driesnote audience photo by Gábor Hojtsy

Our only challenge about this session was the room size. We hoped we can have everyone in person in the same room for our most popular session. If the conference is to have the 1600+ people as we hoped, we could have integrated the two adjacent rooms (that we used for contribution) for the Driesnote into a much bigger keynote room that could hold most participants. (And in that case cut back BoF space to have room for contributions).

However for all other sessions, the keynote room even in the more compact size we used it in was too big. We did not afford ourselves the luxury to pay for the room for the day and then not use it for sessions, so we attempted to put the most popular / most important sessions in this room. At least for the keynote our audience size was right in the sweet spot and filled the room.

Photo by Amazee Labs

This Driesnote was also special in that Dries invited the lead organizers of Drupal Europe on stage and we received a stunning standing ovation from the audience. Thank you!

Megan Sanicki also announced shortly before Drupal Europe that she is stepping down from the Executive Director position at the Drupal Association and leaving the organization. Dries also invited her on stage and said farewell to Megan.

We continued to not having a question segment right at the Driesnote but have a separate Q&A session dedicated for questions, so a lot more questions can be asked and detailed answers given, which was quite well received.

“This Dries Q&A format is fantastic! He’s right here with us, not far away on a distant stage. I really liked the new Q&A format and hope you keep building on it. I thought the “cozy” room size actually added to the atmosphere.”

https://twitter.com/wizonesolutions/status/1039894979760582657 and https://twitter.com/wizonesolutions/status/1039957709905436672

We moved the Prenote alongside the Driesnote to Wednesday morning. The Prenote kept its tradition to be a welcome event for the Drupal community and was definitely still as good as ever on Wednesday morning.

“So delighted that Drupal Europe continued the fine tradition, no institution!, of Prenote this year. Always causes belly laughs.” https://twitter.com/pdjohnson/status/1040345314367037440

Finally, we also had the traditional conference group photo after the Driesnote, right outside at the back of the building. Not taking chances here, our team members spent hours on the day before to find the best spot even considering the angle of the sun at the time. The photo turned out amazing.

The future of the open web and open source panel

This was the by far most challenging session to organize for us. First of all, we wanted to inspire our attendees to consider how our work reflects on the future of the internet and society as a whole through our open source practices and whether we are building an open or closed web. Recent developments like Firefox’s Facebook Container extension, Apple’s blocking of third party tracking in Safari, Microsoft’s acquisition of Github, the rise of the IndieWeb (see Drupal integration at https://www.drupal.org/project/indieweb) and the Brave browser among various other things were key moves to discuss.

Photo by Amazee Labs

We hoped to have various voices in this conversation from browser makers through policy makers to consumers and software providers. We confirmed and announced our initial group of Matt Mullenweg (WordPress), Dries Buytaert (Drupal) and Barb Palser (Google) in the middle of June but Matt Mullenweg unfortunately needed to cancel due to scheduling conflicts two months later. Our final lineup was Heather Burns (Tech policy and regulation specialist), Barb Palser (Google), DB Hurley (Founder and technical lead of Mautic, one of former development leads of Joomla) and Dries Buytaert (Drupal). Tim Lehnen (interim Executive Director of the Drupal Association) is also passionate about these topics and moderated the panel. They provided a great mix of of views from concept through regulation to implementation.

“Thanks to @Dries, @WebDevLaw, @dbhurley and @TimLehnen for a rich discussion about open web and open source this morning — and to the Drupal Europe volunteer organizers for putting on a super cool event — it’s been an awesome week.” https://twitter.com/barb_palser/status/1040163192780062722

The Open Web Lounge

When an idea is good, chances are high that you are not the only one who had it. That’s good for the idea.

It popped up at DrupalCon Nashville where a sponsor dedicated their exhibition booth with the label “Open Web Lounge” for barcamp-style sessions, inviting people dedicated to other open source technologies as well. Meanwhile the German Drupal Association, as a founding member of the CMS Garden initiative, discussed options of promoting their project at Drupal Europe during their monthly meeting.

Some weeks later, a detailed concept was there and sponsors were found for a dedicated room. The 337 square meter room called “Darmstadtium Lounge” was a perfect fit for the plans. We created a space for sessions open to passersby but also areas with loose furnishing allowing for informal talks about common interests and lessons learned.

CMS Garden invited the communities of other renowned open source CMS and organized barcamp-style session proposals that were agreed upon on a daily basis. Unfortunately we did not record the sessions, but we had some awesome presentations and insights there by simply comparing how other CMS communities handle topics like marketing, “genius but unpleasant” community members, raising diversity, or of course different approaches of software solutions. This “off the island” programming offered great insights for example in how multi-language concepts differ between Drupal, Joomla!, TYPO3, Neos or WordPress.

“Getting a really open insight on how the #wordpress community takes care of marketing at Drupal Europe. They have an open backlog too ;-)”


The Open Web Lounge leads used the possibility to raise awareness by adding talks to the conference schedule each morning, so they were dynamically displayed on the venue screens.

It was a perfect fit that the program team did a great job to convince founders of great open source tools as speakers, who also visited the Open Web Lounge.

Photo by Floris van Geel on google

Rocket.chat and Nextcloud announced their partnership and integration a week after the conference — with a photo of the founders taken at Drupal Europe

Forming a track team and launching the call for speakers

Once we published the concept of industry verticals at the end of April, we needed a team to help us get to high quality sessions. We planned to follow the basic DrupalCon structure of a program team with a couple track chairs for each vertical. Only this time, we needed track chairs for areas that are not strictly Drupal but more focused on industries using Drupal. Healthcare failed out of the gate in that we did not manage to recruit a single track chair for it. Some tracks were hard to recruit a whole team for, such as the publishing track, but then brought fruits several times over. It took a long time to form the complete team, and we started meeting with the subset we had to make sure we can launch the call for papers.

All-in-all our track chair team of 32 track chairs (one of whom later resigned) did an amazing job across our 10 tracks. First they worked on blog posts to announce their tracks which helped them get on the same page about the focus of each industry vertical. These were published on our Medium blog. Then they worked to reach out to a diverse group of speakers and encourage them to speak. We did all we could to have good diversity in various ways on the chair team and had several first time track chairs mixed with people with experience.

We hoped that having experienced track chairs would smoothen the process, but given that this was a considerably different conference from DrupalCons and we needed to figure out a lot of our own process and priorities, that experience did not necessarily help. Leadership tasks of the track team were divided and handed over between four individuals which did not help with the smooth running of the team. Having one strong hand to lead the track team would have made processes a lot more effective but unfortunately no single person had the capacity to take this on.

While the track team worked really hard, due to our budget uncertainties we could only grant them free entry to the conference quite late in time. However we made it clear throughout the process that the worse it would be for them is a voucher granted for a cheap ticket if we cannot afford free tickets, so they did not have ticket purchase pressure.

Speaker selection

Our call for speakers ran for a month originally and was then extended for one more week until July 8, 2018. The submission dynamics looked like the following:

As with ticket sales, deadlines really made things go. We were glad we extended the deadline for a week as we got a lot of good sessions that were still in the making at the original deadline. We were looking for content in the following three formats:

  1. 20 minute sessions (including questions)
  2. 45 minute sessions (including questions)
  3. 2–3 hour workshops
“Building Local Communities — foster Drupal adoption” workshop leads photo by Shyamala Rajaram

For workshops, we ended up providing two 45 minute slots combined with the break in-between, so in practice 105 minutes, which was even less than 2 hours. We wanted to have one workshop room that consistently hosts workshops on all three session days, and these were indeed very well received. A combination of frontend, backend, devops, community and business workshops were selected.

We aimed to have the 20 minute slots after lunch as a “speed-up” block, so each day most rooms (except the workshop room) had two 20 minute sessions. Where our session selection resulted in more 45 minute sessions, we also used this slot for full sessions.

For each industry vertical we gave full autonomy to the track team to decide their scoring and selection methodology and similar to DrupalCons provide a priority list of their selection. We even expanded the available session slots through the process, which some tracks used to add more to the accepted session list than originally planned.

While we asked about diversity in the session submission process, we did not expose the concrete data provided by the speaker to the track chairs to protect speaker privacy. We did expose if there was a diversity category chosen or not as a yes/no flag. While out of our overall submissions 31% of sessions were self-identified as having at least one diverse presenter, out of the actually delivered sessions (following all cancellations that were resolved) we had 29.5% of our sessions self-identified as diverse. Unfortunately in many cases, due to our lack of speaker funding, diverse speakers needed to cancel due to lack of financial possibilities.

While the track teams got to work frantically after the submission deadline on July 8, summer holidays made it very hard to ensure equal representation from all track chairs. Summer holidays also made it hard to get confirmations from speakers about their sessions. There were speakers we’ve literally been tracking down through colleagues or our friends we knew they knew. Two volunteers shared the task of communicating with speakers through a shared mailbox.

It took us almost a month when we finally announced the public session list with 162 hours of sessions and 9 in-depth workshops on August 3rd. In hindsight, more reviews by track chairs of submissions up front could have helped speed up the selection process a great deal.

While we did not have a speaker funding pool, we did offer one free ticket per session. For sessions with more than one speaker, we also provided a coupon code for early bird ticket rates, so that co-speakers at least don’t get a bad deal even though they waited for so long to see if they get accepted. Finally, we provided a coupon code with all declined sessions, so those who did not get accepted could also still buy on the early bird rate. We also called attention to our free diversity tickets in the emails we sent, given the application process was still open at the time, so declined speakers could also apply there as appropriate.

Finally, we also hoped to get some help from our speakers to promote the conference and sent along a voucher code that they would invite people from their networks with. This voucher was valid for a €100 discount from the tickets being sold at any given time. Unfortunately we’ve only seen 5 uses of this voucher, so it did not work really well.


While we already mentioned that potential trainers reached out to us in our post at the end of April, we had a lot of conflicting feelings internally about trainings. We considered them important parts of the event to provide high-bandwidth knowledge sharing. On the other hand the Drupal Association even cancelled trainings for DrupalCon Vienna 2017 (before cancelling the whole conference outright for 2018) to save costs. Our rough calculations also did not indicate we could make profits on trainings, at best we could break even. However that compared with the amount of work it took to organize them did not add up.

Nonetheless several trainers were interested and willing to step up, so we agreed with two trainers that they would organize the whole framework. We launched our call for trainings after call for sessions closed on July 10. As we already had a group of interested folks, we only ran the call for 8 days.

Then we drafted a contract between Drupal Europe and the trainers, so they would get a deadline by which they need to pay for the room they booked as well as costs for food for their trainees. They would sell their trainings themselves while the event would also do promotion of the trainings and profits would be shared with the event. We launched training ticket sales a little more than a month before the conference on August 2nd with the following trainings:

  1. Drupal 8 getting started
  2. GDPR for companies
  3. GDPR for developers
  4. Drupal 8 module development
  5. Drupal 8 migrations
  6. Drupal 8 with ReactJS

Trainings did not sell well, however this could very well be attributed to our self-fulfilling prophecy. They were launched too late and as we were busy with preparing for the conference, we did not have big marketing reserves to help push them and make up for launching late.

In the end two trainings remained, “Drupal 8 getting started” and a merged version of the two GDPR trainings. Neither of the trainers got to deliver a training at the end who lead the whole process. We think the topics were quite good, very relevant, and the trainers were also great. It is probably also the case that the free workshops proved to be competition for the trainings. We had a well received ReactJS workshop and also planned to have a migration workshop (which was unfortunately cancelled later), so that may have attributed to the lack of sales of those trainings.

Informal gatherings (BoFs)

Nobody knows the power of BoFs better than us. Drupal Europe was formed in a series of BoF discussions at DrupalCon Vienna (after the initial discussions at DrupalCamp Antwerp).

It was important for us that we have plenty of BoF space and it is self-serve and entirely digital. We also wanted to have BoFs as first class citizens included in the schedule displays (read on later). So we opened BoF submission on August 20, three weeks before the event with 96 slots for three days that was later even more expanded to over a hundred slots. Submitters could pick from a set of predefined room and time combinations which automatically put their BoF in the right room at the right time. Participants could move their BoF around as needed and also unschedule it if they wanted so.

We were delighted to see BoFs following sessions on diversity, Gutenberg in Drupal, Drupal demo, layout management, etc. Also independent of sessions about paragprahs module’s UI design, the Drupal Business Alliance, mentor orientation etc. There were also various fun BoFs like Tunisian fine pastry tasting or the movement BoF that took place outdoors. The German Drupal Association also used a BoF space to organize its yearly meeting and the DrupalCon Europe 2018 organizers also used a BoF space to meet the community and take questions.

We let submitters to assign industry tracks and expertise tags as appropriate so BoFs would also show up on pages for specific tags or tracks.

Roundtable discussions

While not organized by us, these are important to mention. Events like Drupal Europe are ideal to gather various interested parties for deep discussions. So the Drupal Association organized various roundtable discussions with supporting partners as well as local community leaders.

Community leaders round table photo by Paul Johnson

The reception of the community leaders round tables were great as people had a chance to share pain points cross-borders and get direct feedback from the Drupal Association and Dries Buytaert in person about their concerns. The second community leaders round-table was organized to focus on some top action items. For example, a “Marketing Drupal to Customers” initative was formed by Suzanne Dergacheva, Paul Johson and Ricardo Amaro and is looking for your participation to make materials happen.

“Awesome to meet over 30 Drupal community leaders from different European countries and to represent Austria. As somebody said, together we can create magic!”


Volunteer coordination

“Volunteers do not necessarily have time, they just have the heart” — Elizabeth Andrew

Drupal Europe was organized by volunteer leaders from the get-go. For the scope of this section we’ll use the “volunteers” term for contributors who were not involved in the larger creation of the event but signed up for specific tasks instead.

(Some) volunteers group photo by Dropsolid

No event is successful without helping hands, and we found many of those at the right time. We created and posted a questionnaire on the website asking interested people to answer some basic questions regarding how they want to help, what medium of communication they prefer and will they be able to help on-site.

We sent out the first email to the volunteers who signed up via the questionnaire in early August. In this email, we explained the volunteering tasks and the communication methods to use. In further emails we provided details about the signup sheet we used to let people pair up to tasks.

We designed our volunteer signup sheet based on the sheet from DrupalCon Nashville. The sheet detailed the roles and responsibilities of the tasks they were supposed to do on-site. Two weeks prior to the conference, we sent out the signup sheet and asked volunteers to assign themselves to tasks they are comfortable with. We did not set any required amount of tasks or hours for volunteers, but we were not able to offer any benefits other than warm feelings either. Everyone spent the time they could contribute.

We had a great team of on-site volunteers helping us with activities like check-in at the registration desk, monitoring the sessions in rooms, sponsor care, trivia night, contribution rooms, photography and videography.

The tasks of monitoring sessions in rooms demanded the highest amount of volunteers and we had several gaps. We tried to fill those by approaching attendees we knew who did not yet sign up to volunteer but were attending those sessions either way. A printed checklist was created for room monitoring containing the necessary action items for the room monitor at that time slot to check before and during the session.

The almost 900 amazing photos that you see in our Flickr group were taken by a few people, huge thanks for your continued service!

The first in-person meeting with all the volunteers was held on Monday, September 10 where they could meet other volunteers and ask questions. During the meeting, we also dealt with unassigned gaps in the volunteer sheet.

During the event, we used Slack for communicating with the volunteers. We also decided to use drupal.org issues to give credits for contribution. On drupal.org we have a Drupal Europe 2018 project issue queue where we created issues for most of the volunteering activities from the Drupal Europe volunteer signup sheet.

The budget

The hardest part was always the budget which is probably true for any event of some size. The venue contract required a downpayment and apart from some small savings in the German Drupal Association’s bank account there was no money to work with yet.

The financial report of DrupalCon Dublin served as a benchmark. We used a copy, filled in the cost estimations we had and quickly drafted ticket price levels. While the Drupal Association historically been putting on DrupalCon Europe for somewhat more than a million euros, our target was half a million euros instead. We hoped we can gather similar attendance and sponsorships but we had no history or credibility with participants or sponsors so that was hard to predict. Some people just assumed we are replicating a DrupalCon while others considered this a big DrupalCamp and did not expect the quality we were aiming for. Our target of break-even was set at around a thousand attendees with various flexible budget elements. Selling faster/better would make spending on marketing to wider markets possible, grants to attendees possible, more diversity support possible, etc.

Given very little seed money to work with we needed to sell fast. We decided to sell a batch of “early supporter” tickets for a little less than the estimated break-even ticket price at the time. We also quickly created our initial sponsorship packages and started promoting these. All that while we still had a pretty “drafty” static web page. It all looked far from professional.

A comparison of our actual ticket and shirt sales (ticket shop) income compared to contracted down payments that could not be postponed shows how close we were at the start to make it or break it. While we had sponsor income as well later on, that was not there at the time of the first payment yet and just started to be significant after the second payment.

The chart compares major costs to the actual income situation over time. At each point in time we were interested if we can pay the next down payment (shown also as accumulated amounts) and ultimately hoped for reaching the point when the blue income reaches the pink costs, as we would not be losing money at that point. Week 37 is when Drupal Europe took place, and we only reached break even two weeks before.

Faith moves mountains is beyond any religious context true for the Drupal Europe lead volunteer team. Almost all lead volunteers immediately bought their ticket (and those for their colleagues) at the start. Some even offered a private loan, which we were not too far from needing on week 15. The Drupal Association bought all tickets it needed right away. (Thanks!) About half of our sponsors and around half of our attendees were also relatively easy to convince. The other half took a lot of work to convince which took most of the lead’s time to ensure that the event is at least break even.

In our regular budget reviews, up to two weeks before the event we were to lose money. This has cost us a lot of things. If we would have had financial certainty much sooner we could have had time to raise funds to organize scholarships, could have supported our speakers to cover at least some of their costs, we could have organized better quality video recordings, ensuring all content is recorded, etc. As it was though, we even had uncertainty up to a month before the conference even if we can grant free tickets to the track team who worked for months to assemble the conference program. And we had to plan with a gap to cover incidental expenses like that of the on-the-spot expansion of the contribution area on Friday.

If we may give one advice to the community, for any future Drupal event: sign (and pay) your sponsorship early. Buy your tickets early, don’t wait for the full program if you’ll go anyways. If you are faithful you’ll be part of the momentum that moves a mountain.

Since the tax amounts are only estimated, we only know our profits for sure once the finance authorities make the final decisions in terms of taxes next year. If there is indeed profit left, we hope to support Drupal events in Europe.

General tickets

As mentioned earlier, we set up Early Supporter tickets to be able to pay our first downpayment to the venue. And we succeeded, thanks for believing in us! Our Early Bird rate was the same as for DrupalCon Vienna and our Regular rate was 10% more. That does not sound very much like the affordable conference we set out to organize, right? Well, the Drupal Association kindly provided us with some ticket breakdowns from previous DrupalCons and we were quite surprised about the number of granted tickets. Our final total ticket income of € 270.000 divided by the 1000 or so attendees we had comes down to an average ticket price of € 270. That is well below even the Early Supporter rate. About a third of our attendees did not pay directly for their ticket. Their ticket was either included in a sponsorship package or were speakers or track chairs or received a diversity ticket or they were the few mentors who received free tickets. So if all attendees would have bought their tickets, the price would have come down to € 270. On the other hand, we considered it important to give free tickets to speakers for example and in fact would have loved to provide more financial support to them, since some of them even needed to cancel their participation because they did not have enough funds to attend. None of the people under categories receiving tickets that they did not directly pay for looked fair to exclude.

We were also surprised by the historic sale dynamics of tickets being sold very, very, very late in the process practically starting 5–6 weeks before the event once sessions are announced. Up until then its very hard to tell your conference size or even how many people to plan with. We did not have significant seed money to work with so we needed to have more aggressive timelines and have a larger part of our income earlier. We also did not have certainty of the amount of tickets to be sold. We had a venue flexible to accommodate a DrupalCon Vienna sized event with 1600+ attendees and we shot for that target in our marketing as well.

Our actual ticket sales were as follows. Number of tickets sold in dark blue, number of shirts sold in violet and number of general donations made in light blue from February to September:

Here are all the rates for comparison:

We also sold single day tickets onsite for € 270 to be used on Tuesday, Wednesday or Thursday for one ticket per person. We sold 24 single day tickets at the conference and 28 ahead of the conference. In other words most attendees bought a weekly ticket.

Ticketing and payment processing

We did a lot, really, a lot of research at the start around ticketing and payment providers. All the usual online services came up. We settled on a solution using the Pretix open source ticketing system and Stripe for payments. We could ensure our Pretix setup was GDPR compliant since we hosted it ourselves and controlled all the data. It had good usability even on the admin side. This let us run our own ticketing software and control every detail we needed. We had flexibility to set up various ticket types, coupons, discounts, upsells, etc. Using this setup we estimated we saved €30.000 in fees considering usual online ticketing provider fees.

While we had hoped to integrate Pretix with the website more than the embedded widget, we did not end up having time to do that. Unfortunately that lead to us spending lots of time deduping website accounts with tickets bought and more waiting time at the registration desk for attendees who did not have website accounts (despite receiving a mail to register on the website for a badge).

We also used the open source pretixdroid app on reformatted spare Android devices donated by volunteers for checking in attendees. Some devices and some pretixdroid software versions worked better than others, but scanning the QR code of tickets resulted in very fast check-ins for those who brought their QR codes along.

At the registration desk, we (intended to) split the registration lines in letter batches according to given names, and had a separate line for speakers. In an ideal world, attendees would have noticed the letters and the speaker queue and queued up nicely. In reality they were overwhelmed with their first impressions, were still trying to find their place, noticed familiar faces and started discussions, etc. Maybe more visible signage about letters or volunteers helping people find the right queues even could have helped. In hindsight, the separate speaker line also became an issue since many speakers did not pay attention to it, which resulted in several of them having handwritten badges and loss of time at registration.

Coupons and other promotions at events

While we kept raising the sales prices for tickets, we wanted the community to still get good deals. So we ran various coupon campaigns at DrupalCon Nashville, Frontend United, DevDays, etc. For DevDays we printed little business card size coupons and got them in each attendee bag to encourage people to buy tickets. We also got rollups printed that were brought to various events across Europe and the US and flyers to hand out to conference attendees and meetup participants.

For DrupalCon Nashville the Drupal Association let us place our rollup in their booth and we got Drupal Europe hoodies made to wear there to promote the event and make our organizers easy to spot. For further events we made pilot versions of the event t-shirt in white to wear and use as promotion. Our volunteers were present at each and every event we could be at appropriately dressed, handing out flyers. All-in-all we probably reached all the usual Drupal audience we could.

Photos by Gábor Hojtsy

In hindsight it was not worth the effort to create vouchers for every single event as the conversion rate was very low. It was not enough to offer discounts, we should have promoted them more heavily.

Diversity tickets

Especially since we kept ticket prices comparable to DrupalCon Vienna, we wanted to provide new opportunities to potential attendees from diverse backgrounds who would not have a chance to come. We also wanted to give opportunity to all who believes the same to financially support this effort, so starting with Early Bird tickets, we provided the opportunity to purchase 25% to a 100% of an additional ticket to be used for granting diversity tickets. This did not work at all. We did not sell even a single ticket this way. There are probably many reasons. Our explanation of the options were perhaps unclear and we did not exactly define how such tickets will be distributed (as we did not yet know at the time). It was also definitely a new concept. One track chair offered their previously purchased ticket for this pool.

We did not want to abandon diversity tickets however and decided to dedicate the few general donations we had received (altogether € 1.270) as well as funds from our main budget to cover 25 free diversity tickets. We thought this is going to be such a small drop in the ocean for a conference that hoped to have 1600+ attendees, but without any attendee-funded tickets and no financial certainty of the event yet, this was the extent we could commit.

As we did not have credibility/history in the community and our date selection drew deserved criticism for our lack of diversity earlier, we decided that we should not make decisions about who receives diversity tickets. Instead we partnered with diversitytickets.org which also hopefully helped us reach outside of the Drupal community serving yet another dimension to diversity. While we were ready to even expand the ticket pool if needed, for our 25 offered tickets unfortunately only 17 applicants signed up. All of them received their free ticket codes. 10 of them used the ticket code.

Contributor tickets

Back in our Hello World post right after Vienna we stated we want to make the event accessible to contributors who are not interested in sessions but all the more in meeting community members and work with them to make Drupal happen. We (again) did not know if we’ll have money for this, so we perhaps launched this program a bit late, a month before the conference. After much debate we decided that contributors paying for their catering is fair, so we set up a €100 ticket for contributors. We also decided that one would need to fill in a webform to explain their reason for the ticket, so its not misused and does not endanger the budget. Six applicants requested a contributor ticket, all got the voucher code to buy one and all of them used their vouchers. Honestly we were quite surprised by the low number especially that we promoted the option in social media and right on the frontpage of the event, but it was a late offering.


How to convince sponsors to significantly support an event that has never taken place before? That was the first challenge the sponsorship team had. The goal was set to get sponsorships worth the cost of the venue, which was around € 200.000. That was approximately 1000% of what we were used to raise for local Drupal events and therefore we had to think a lot about how to convince companies to sponsor the event. We decided very early on to use similar sponsorship packages and format as in DrupalCon as many sponsors knew how those worked. We gathered information about potential sponsors and on March 13th, we sent out the first version of the sponsorship brochure.

But what were we selling? To start with, we were just selling an idea. An idea of a large scale Drupal event that would attract 1600+ attendees. Within the first hour, two sponsors signed up and one more followed on the same day. The first diamond sponsorship was signed one week later and also two module sponsorship packages. We got confident that this could work out, as we had raised nearly € 35.000 on the first week.

We had to create formal sponsorship agreements and make sure that all the venue rules got included in them. We noticed that many companies were still unsure about Drupal Europe and were waiting to see what the program would include and how many people we would attract. You could say that we had the famous chicken/egg problem in front of us. We had to think about some alternatives.

At DrupalCon Nashville, we came up with the idea of a country marketing sponsorship, which we presented to some agencies. The idea was to encourage Drupal agencies and communities from different countries to market themselves together. This could attract visitors from the countries to visit the booth and start a conversation with agencies. Some countries showed interest but unfortunately we couldn‘t convince anyone to take this sponsorship package. We still think this could be an interesting approach for agencies / communities to promote their work at DrupalCon Europe.

As this didn‘t work out, we had to come up with more ideas. Again, DrupalCon Nashville inspired us with the Open Web Lounge that was sponsored by Automattic and after discussing the idea with CMS Garden we decided to have an Open Web Lounge at Drupal Europe and started to contact potential sponsors. This idea became successful and we managed to get two sponsors for it.

Only one week before the actual event, the last two sponsors confirmed their sponsorship and we hit our goal and even € 4.000 more. Kuoni, the professional company that will organise DrupalCon Amsterdam 2019 signed the sponsorship agreement that made us hit the goal. Thank you Kuoni for supporting our event and showing the community that you care!

In August we had to start organising the exhibition area. The employees of Darmstadtium helped us to do that and we started to contact sponsors and allocate them a booth area. There is a lot to think about when planning an exhibition area and as we had never organised such a large event before, we definitely hit some hurdles on the way. With the patience of our great sponsors, we managed to organise everything needed for the event, such as renting computers, screens, tables and chairs.

Photo above by Baddý Sonja Breidert.

One of the learnings from the event itself, was that it is important that there are clear rules about what the sponsors are allowed to do and what is not allowed. We noticed a lot of advertising material flying around the venue (literally as well as physically), some of the companies didn‘t ask for permission to do so and we even noticed flyers by companies that did not sponsor the event by any means. Sad.

We should have better promoted the designated „open area“ where the community could place stickers and advertising material, and then keep the sponsor area clean and only available for sponsored content. The German Drupal Association’s community stand close to the registration area served as the “open area”, welcoming every not-for-profit Drupal project to place their promotional materials there.

Again, we want to thank all of our sponsors. Without you, this event wouldn‘t have been possible.


Various of our organizers have kids and we thought it would be important to provide professional childcare for attendees and speakers to make their participation possible. This decision was in no small part inspired by very successful childcare services at WordCamps. We announced the plan for childcare on May 18th. In hindsight this was quite late for family-travel planning 4 months before the event. We were expecting small children as most European countries already had school at the time of the event, but ultimately the service we would have offered depended on parent requests. We researched various service providers and were really looking forward to how this turns out. While we got lot of good feedback for trying, less than 10 interested parents signed up and only one of them responded to our request for details (age, etc) about the kids. Even that single parent did not attend at the end, so we did not end up offering childcare.

Our decision to have childcare sparked a lot of discussion and had wide reaching effects of other conferences looking into the option as well.

Onsite services for attendees and speakers

While childcare did not work out, we still wanted to provide parents with support, so we offered a lactation room for those who preferred privacy for breastfeeding or pumping. We also continued the tradition of a quiet room which could be used to get away from the buzz of the conference for some quiet time or prayers. To make these rooms private, we booked two rooms in the quietest area of the venue, the door to which were sometimes unfortunately closed by venue personnel. We were not diligent enough to check often but immediately acted when an attendee called that to our attention.

Speakers were provided their own preparation room that also included drinks catering in the room so they could have personal time to prepare for talks.

All attendees were expected to abide by the conference code of conduct, which we built almost entirely based on the DrupalCon code of conduct for simplicity. There were some necessary changes as our code of conduct contact would of course not be at the Drupal Association and we cannot deny entry to future Drupal Association events for misconduct at our event as we don’t have authority to do that.

We also provided communication stickers (green: open to communicate; yellow: only if you know me; and red: I’m not interested in communicating at this time) at the registration desk and green lanyards to request not be photographed. The Drupal Diversity and Inclusion group provided pronoun stickers (she/her, they/them, he/him, etc) and we planned our badge with enough space to place that sticker as well. Green communication stickers run out fast. We’ve expected a subset of our attendees to use these stickers but they were widely used. No-photography lanyards were ordered as neon green which turned out to be not true. A true neon color would have helped to spot attendees with this lanyard in photos easier and therefore such accidental photos to be discarded easier.

The venue is very accessible for wheelchairs with ramps and elevators. We also offered help with arranging interpreters if needed, but no attendee requested that.

We also offered an all-gender restroom block that included toilets that are otherwise marked men, women and an accessible toilet. This block was right at the second biggest session room with an easy accessible path to it as well.

Social events

What’s a major Drupal conference without good social events? Various people highlighted social events in general or specific social events as their favorite moments in our post-conference survey. In that light, it may sound odd, but we only (co-)organized two social events all week and left the rest to the community to figure out. (And you figured it out very well, thank you!).

Trivia night photo by Amazee Labs

A major social event that is a mainstay is the Trivia night as it is fun for beginners and experienced Drupalers alike. So much so that we built in the financing of it in the sponsorship packages. This has historically been organised by the Irish Drupal community and they were back here to lead the event at Drupal Europe as well. But finding a suitable venue for it was not easy. We got various quotes and explored several options but they were either very expensive or at very sketchy areas of town. We even ping-ponged for a long time between which day it should be, which made social event organization for others a challenge. Finally we settled on the traditional Thursday and agreed that the venue would host it in the convertible keynote hall re-furnished for this occasion. Again we were lucky to find a good partner in Darmstadtium and their technology, as they could create a ballroom with tables for groups of five people out of the keynote theater in an hour. Hosting it in our own space helped us avoid smoking, loud music, etc. but still host a bar. Unfortunately some attendees got very carried away with their party-time, throwing paper airplanes and beer coasters around which we should have stopped when it started as opposed to only when the complaints came in. Other than that we only got good feedback about this event.

“First trivia night. I really enjoyed it, we had pretty good scores for beginners and even made a new friend David Needham”


Biergarten photo by Jean Fenouil

Our other social event was outdoors in the Bayerischen Biergarten which was organized almost last minute. With luckily amazing weather, the plentiful fully outdoor space helped to not feel like a cramped crowd.

Several other events were submitted by you! Thanks! The game night hosted in the venue drew a very diverse crowd with lots of games (photo on the right by Gábor Hojtsy), a small group of people walked around town, the camping group hosted a social night, there was a CEO dinner discussing the Drupal Business Survey results and other topics, the Belgian and Dutch associations hosted a party as well in the park right next to the venue and there was a publishing and media get-together. In short, you did not disappoint! We made a requirement that all submitted social events would apply the same code of conduct that the conference used.

We did not have capacity to organize a first timer’s social event or the traditional women in Drupal get-together, neither the usual exhibition opening party. While many social events were organized by you all, it is not surprising that nobody took authority independently to organize these. We could have been more transparent about the need to help organize these which may have resulted in them happening.

While we were happily in our bubble, the church bells at Tuesday midnight reminded us of 1944 September 11, when 80% of Darmstadt was destroyed in a bombing. It reminded us of a horrific world war’s scars still present but at the same time of how respectful international collaboration has fostered a long period of peace (at least in Europe) ever since.


The major issue with conference centers is that if you are to have catering, you are required to work with the house’s caterer and they have their usual pricing. Yes, one of the ideas to reduce the budget was to not offer catering. On the other hand we have been to DrupalCons that were harshly criticized for running out of coffee. Also the need for lunch and especially coffee and tea all day was underscored in our initial survey as well.

We have discussed the option to let attendees go get their lunch outside the venue. Theoretically this would not be difficult because Darmstadtium is located in the center of the city. But Darmstadt’s downtown is not quite big enough to effortlessly feed 1600+ people spreading out to the nearby restaurants, easily expanding beyond a two hour lunch break even. The caterer sent us an offer with a self-buyer’s option for lunch. That was the point when we realized that we would save € 5–7 per person per day on lunch. So we decided that we’d include lunch. Nothing fancy, just basic tasty food.

In dietary terms, the organizer team is pretty diverse. We had no doubts that an inclusive event needs to respect all common diets and have options for diverse food intolerances and allergies.

Photots by Gabor Hojtsy Photo by Shyamala Rajaram

We came up with a brisk idea: let’s serve vegan food. That way it already respects vegetarian, vegan, halal, kosher, lactose-free and free of two major allergens. Looking at the dietary requests in the user registration form one of these were already a requirement for more than 25% of the attendees. The plan to always have one of two dishes gluten-free did not work out on all days, but we managed to provide solutions on the fly with the caterer. We must admit we challenged the cooks a bit. In the end they thanked us for all the new ideas.

So actually on the one hand pre-contracted caterers might be an issue but on the other hand there are several advantages in working with one. They were experienced partners of the venue, they knew their workflows and spaces and they could usually make educated estimations. In our case the caterer made the plans for the placement of the buffet and drinks stations directly with the venue’s people. And we just had to mention once that we don’t want to hear any complaints about the availability of coffee or water.

While feedback on the food was overwhelmingly positive in social media and onsite, the post-conference survey had a more balanced view. Some people really missed meat options and a few people mentioned the food could have had more variety within its boundaries. The option to have a dedicated meat stand with some availability to extend this concept came up while talking to people.

We only heard positive things about the all day coffee and one person mentioned there should have been an option to have tap water. We already had no plastic or single use wrapping or cups or plates and we asked the caterer to donate the leftovers to a local food charity.

“Great atmosphere, interesting talks at Drupal Europe. And btw, all food vegetarian/vegan with no single-use wrappings whatsoever. That’s the way to go!” https://twitter.com/hukkajukka/status/1040186240585355264

“Deep talk about the delicious croissants at Drupal Europe at night! Loving it XD”


“Love the fact that all food at Drupal Europe is vegetarian and there are no plastic or paper cups, plates or other such waste. And finally, food is really tasty and there is plenty of it.” https://twitter.com/plastic/status/1040185970564521985

“The food was excellent, plentiful and varied. I like the fact there were pastries in am. As someone who skips breakfast to be at the prenote, keynotes etc that was marvellous. And fruit. Yay!” https://twitter.com/pdjohnson/status/1040320555692503040


The Darmstadtium has a dedicated page to boast about their network capabilities and their award won for it.

Latest IT infrastructure, a fast internet connection (up to 10 GB/s), extreme reliability and the provision of individual customer networks (VLAN technology) — with our digital infrastructure, we fulfil the most stringent requirements for network technology and connectivity.

But, you know, we’ve seen many things before and DrupalCon has brought down the wifi system of some venues in the past where the IT people were so confident. Not here! Apart of a few isolated issues with client devices, the network worked flawlessly even on the contribution day when most people were concentrated in one specific corner of the building.

We had more than a thousand clients every session day on wifi. Somewhat less than half of those devices were Apple devices according to network stats. Roughly 10% of all devices used the 802.11ac protocol while 25% used 802.11n on 2.4Ghz and 75% used 802.11n on 5Ghz. 1TB of data was transmitted over wifi on the session days, while our wired devices doing session streaming also transferred another 1.7TB of data.

Our main contribution for making the wifi work was the network name and password. We chose “DrupalEurope” and “ContributeToday” to signify and spread the community spirit that brought together the conference in the first place.

“Very few conference centres deliver on WiFi availability for number of clients nor speed. Not once in the week, even during keynotes, did I experience problems. Fantastic service, that’s not just the WiFi either. Highly recommend your conference centre as a venue.” https://twitter.com/pdjohnson/status/1041595697680797697

“Conference centres never believe us when we say we will eat all your data. And use all your connections. @ds_darmstadtium thank you for providing us with the perfect environment. I hope we’ll be back again some day.”


“Possibly the best internet of any large Drupal event @DrupalEurope. Super productive event and we haven’t really started yet. Hopefully we will see you here. #DrupalEurope”

[Speedtest.net results showing 3ms ping, 140.83Mbps download and 113.76Mbps up]


Digital signage

A significant cost cutting measure that was also great for the environment was to skip printing program booklets. DrupalCon had already done away with goodie bags that we did not have either, but we went one step further. Thankfully for us, the venue had plenty of digital screens everywhere starting from welcome screens in the parking lots and elevators (see on the side, photo by Gábor Hojtsy) through screens in the elevators, screens in the hallways and even screens on the doors on the second and third level.

The screens could display any URL and would normally reload every 10 minutes. So we built some screens as custom styled Drupal nodes while others were powered from Views and included some custom JavaScript and CSS. We built several screen variants up front and used timelapse simulation for testing to check the dynamic time based logic for various screens.

We got some of them tested well with the venue remotely (eg. the door screens for rooms). The ones that were well tested ahead of time worked from Monday onwards without a hitch. As we were ready with some screens last minute, we did not give the venue much time for remote testing, so we had to spend quite some time with testing and adjusting some of them on Monday.

Slightly unfortunately all screens used Internet Explorer 11 to display content and almost none of us had that on their development environments. We relied on a browserstack.com subscription for this occasion. We also set the refresh interval to much more often when we were adjusting screen display. Another issue we had was with Drupal 8’s great caching, which caused us issues once people were not updating their BoFs anymore and Views caches did not get invalidated often enough normally. We adjusted our configuration when we realized this and that made the program overview screens follow time more closely.

All-in-all the usage of digital signage allowed us to skip a lot of housekeeping time before/after the keynotes and update program items dynamically as they needed updates. When a talk was cancelled midday or another replacement was added, we could update the online schedule which updated all screens almost immediately.

Photo by Gábor Hojtsy

Informal gatherings (BoFs) were self-scheduled by participants but immediately showed up alongside every other session or workshop in a timeslot on all screens (see photo on the right by Janne Kalliola). We heard that this resulted in a lot more activity at BoFs. We also created program items throughout the day from the Open Web Lounge unconference schedule that was always defined in the morning for the day, which drew participants to those as well. (Additionally to the Open Web Lounge having its own screen).

Some extra work went into SVG maps of the venue that laid out the spaces of the building including where to find each sponsor. We displayed these as well in rotation (floor by floor) on some of these screens.

Photo by Janne Kalliola Twitter wall photo by Janne Kalliola

Finally, on our last venue visit, we had various interesting ideas for the use of the big gray projector wall in the main hallway. As people arrived and went towards the keynote room and contribution rooms we wanted to add a welcoming touch. Our initial idea was to feature photos from previous events on the first day and then from this event onwards. That morphed into a curated twitter wall that we could still use to display photos on but also had the option to feature text-only posts or photos where the added text was useful for clarification.

We evaluated various ready-made services for the Twitter wall, signed up for a few to try them out but the decent ones usually cost € 200 per day for a live curatable feed and we did not have that kind of budget to spend. Building our own quick solution with Views and oEmbed for tweet display was a logical next step. It would be amazing, if someone could bring this forward and create a supportable module or distribution out of our open sourced code.

We were not even ready with the twitter wall on Tuesday morning, so we used the keynote live feed to display on the screen and invite attendees in to the keynote. Once the session days were over we used this same screen to display wayfinding information for contributors behind the welcome tables of mentors and to say farewell to our participants at the end of the day.

Photos by Gábor Hojtsy

“Brilliant!! [the screens] were amazing, accurate and very helpful.”


Video recording (and streaming)

This is an area that was most affected by our lack of funds. We asked for a video recording/streaming offer from the venue which was impossible to fit into our budget so we attempted to put our own solutions in place. There was no single source of existing video recording equipment at the European communities in the quantity needed that we could use and we of course did not have the budget or intention either to buy 10 recording kits. While we did not promise recording or streaming of any of our program, we wanted to do our best to try and do it.

We set up https://www.youtube.com/c/DrupalEurope (for most of the time without the custom URL as we became eligible for that way after the conference) to stream on the week and host our videos after the event.

We ended up with three solutions for video with overall very mixed results.

  1. We had a very dedicated volunteer for recording and streaming the keynote hall. He had been working on a sustainable concept of a bullet-proof hardware solution for such purposes and took the chance to get the most out of his idea. He installed three cameras, one at the back of the stage to cover the audience, one in the middle of the audience and one up at the ceiling where the video control room was. He then mixed these live with the projected screen footage, the digital signage screen developed for this room and audio feed from the venue. The result was recorded locally and streamed live. We had great results with this solution as even though the live streaming broke at some points due to conflicts with configuration of our other live streaming equipment in other rooms, the local recording was consistently useful and could be used later to upload the correct session videos (except where speakers requested to withhold their publication).
  2. We also had four previously used streaming boxes from the Dutch Drupal Association. Without a dedicated volunteer to attend to these and a lack of testing up front, it turned out too late that they were not getting audio from the HDMI over IP boxes they were connected to. Once we installed audio inserters alongside the streaming boxes, the streams were working well, but that was too late for many sessions unfortunately. These did not do local recording, but even if they would have done so, the lack of audio would have been an issue. Finally, the streaming from these boxes only worked if the input was 1080p or lower, higher resolutions did not work. As we got our recording equipments together last minute, we did not have the possibility to let the speakers in these rooms know ahead of time and pre-session setup did not always include setting it to a working resolution.
  3. Finally the remaining five rooms had recording done with boxes we received from the Austrian Drupal Association. These only did local recording, not streaming. They needed to be manually operated and required a lot more work after to cut the recordings and do uploads. Results were also mixed in terms of whether audio or video was recorded.
Keynote hall video setup photo by Floh Klare

It is clear we had too much trust in the self-sufficiency of some of the technology we used, given that the individual solutions were proven at previous Drupal events. However they were not used on this scale nor in this combination and were likely operated/maintained by more dedicated people even at those smaller events.

We should have done better testing of everything and assign one person responsible per room to be sure that the technology works in each case, on top of the room monitor that was there to help the speaker. The German Joomla! community kindly offered their equipment and operating team earlier that we turned down at the time as we did not have the certainty of the budget yet to promise to cover their travel and accommodation expenses.

After the first session day on Tuesday, the organizers team stayed in the venue until sunset for a retrospective meeting to figure out ways to improve how we solved problems especially in regards to the recording solutions on the spot. We received several complaints over Twitter about the video streams at the conference. While we decided to focus more lead volunteers on further days to help speakers set up and make sure recordings work, we did not want to sacrifice the experience of people actually participating in person so we kept that as our first priority.

Tuesday retrospective photo by Gábor Hojtsy

It took us several weeks after the event, but eventually we got most things that were usefully preserved online, see https://www.youtube.com/c/DrupalEurope. As of this writing we are still looking at cutting session slide imagery as a video track on top of session audio recordings where we only had audio.

In hindsight if we would have had the budget capacity and more of a budget certainty in time, we would have signed up professionals or semi-professionals to do this so it does not fall on the limited set of leads who were busy with serving the in-person participants as well. At least we cannot blame the volunteer coordinators, they have been trying really hard to find enough room monitors early enough and still weren’t 100% successful.

In summary what would have improved our situation would have been to split speaker screen video right at the laptop and not receive video from the venue’s system. Ideally we would have been able to record, stream and monitor the output at the same time. Without monitoring, relying on local recording was not sufficient and monitoring the too numerous streams we had would have also required more people. Because we did not have tech personnel available in every single room at the beginning of every single session, some people tried to solve problems unplugging and moving our kits and that did not help. We should have had readily available tech help in every few rooms and tell people not to touch our tech.

Post-event survey

We got lots of feedback onsite, both good and bad. We tried to turn any onsite negative feedback into actionable improvements right there by changing room tech support, getting more tables for contribution when needed, etc. However we also wanted to get a better overview of what people liked and did not like so we can inform future events. While there will not be another Drupal Europe, the results could still help DrupalCon Europe and other events. Here are some highlights from the survey results based on 151 submissions we received as of this writing.

First of all, we asked respondents to rate the conference from 1 to 10 (10 being best) and our average rating was 8.44. Not bad!

For 14% percent of our respondents, Drupal Europe was their first big Drupal event and most of them found it very easy or easy to network with others. The subset of them who said they were new to Drupal said Drupal Europe was a good introduction. This is somewhat contradictory to what we felt that due to the lack of external marketing we only reached the usual suspects. Of the people having their first big Drupal event, most were out of Germany, for example Kenya, Zimbabwe, Greece, etc. 55% of our respondents were DrupalCon regulars and 31% already been to at least one DrupalCon.

In terms of overall country distribution, almost half of our respondents were from one of these three countries: Germany, United Kingdom or the Netherlands. The diversity gets a lot more interesting beyond that, we had attendees from Tunisia, Zimbabwe, India, Ethiopia, Canada, Ukraine, Australia, Pakistan, Armenia, Russia, Jordan, South Africa, Egypt and Congo. Given the numbers of them, it is also no wonder the Dutch and Belgians hosted their own social night! A potentially important data point is that based on the results, Austrians did not turn out in numbers at all, despite or maybe due to the DrupalCon in Vienna last year. (But the usual caveats apply about survey respondent samples).

82% of the respondents said they received somewhat or much more value then they expected and only a single respondent said they received significantly less.

A roughly equal number of people said they missed the opening and closing keynotes or to the contrary they enjoyed having more industry programs instead. Similar about the food, we received many praises for the food being varied and not too heavy so people could keep going with their day while others said we should have had more sauces and variety with the food even if we kept the same constraints we set up.

A considerable number of people said they would love to see more in-depth workshops while at the same time a few people said more high level sessions would be nice. A middle ground as someone suggested is to really mark the approach each session takes well in the schedule (which requires a lot of discipline up front from speakers as well).

Several people noted that first-timers tool workshops would be nice ahead in the week so they can be productive on contribution day or at least get to know the tools even if they don’t manage to attend contribution day. More visible non-developer teams for contribution day was also requested by many. Here’s your chance to recruit design, marketing, project management, translator, documentation, usability testing, event organization, etc. talent for your topics!

As for what should be cut, a recurring line of feedback was to have less sessions as there were too many things going on at once. We designed this conference with 1600+ attendees in mind, and picked optimal distribution of people to room sizes based on that. With around a thousand attendees, some sessions were not that well attended. At the same time, some people pointed out that certain sessions were standing room only. If we were to cut some of the competing topics at the same time, this would have been worse given the same room configuration. We could have merged some session rooms and create bigger session rooms though to adapt to such an event setup.

Our digital signage, website and twitter account were used to keep people up to date with conference changes and program announcements and we did not have pre-keynote segments and opening or closing sessions to inform people. Half of our respondents found this very useful while a third found it only somewhat useful or not very useful. Probably a combination of the two approaches would work best.

Finally some choice quotes about favorite moments:

  • “Seeing many of my favorite Drupalers and being introduced to some excellent new folks! […]”
  • “The constant flair that everyone helps each other.”
  • “Getting (nearly) all of the local association leaders together in a room. Was really powerful. We need to do more of this…”
  • “Becoming a mentor […], learning that I can share my knowledge and people are grateful for the support.”
  • “Randomly having a conversation with someone who then went off [and] had a similar conversation with someone else and connected us.”
  • “Getting help on Friday and that ‘aha!’ moment.”
  • “Celebration of the Drupal Europe team. It reminded me of why I was involved in Drupal for the last 10 years (which has sometimes been hard to remember sometimes, specifically as Drupal and I change over time).”
  • “It was the sum of all those little details, Drupal Europe was an ongoing favourite moment.”

Final words

This year was fast paced and very activity filled for us. We learned a lot and enjoyed working together thoroughly. While we organized an event in Europe, we’ve been working with inspiring people from all over the globe from India, Suriname, Canada, Ethiopia and so on to put on the best event we could.

At the same time as volunteers, hardly any of us had a grasp at the extent of the work needed to do to put on such an event. Many underestimated the time and attention required. Some left the team when it became apparent to them that they cannot contribute as much as they hoped and we tried our best to support them. Even in hindsight reading back all the stuff we wrote about what we did, it is hard to believe. We had a very strong sense of purpose of providing this energizing family reunion that is also a great technology conference and we absolutely put our hearts and souls into it.

At the same time when we give volunteer labour we take that time from somewhere else. Whether that’s taken from our family, friends, employers, free time, or sleep time. It comes from somewhere. We need to account for it. We’d like to extend our thanks to all companies who supported volunteers in some way and especially our families and friends who put up with us.

As you may have learned in the Driesnote or online, DrupalCon is back in 2019 in Amsterdam in partnership with Kuoni. They already attended DrupalCon Nashville earlier in 2017, and following the announcement, a BoF was held at Drupal Europe to provide a place for all to meet Kuoni and ask questions. Three of our organizers will be involved in an advisory capacity in a committee to help transfer know-how and keep the community spirit.

Kuoni at Drupal Europe photo by Paul Johnson

We don’t think we quite figured out a sustainable way to put on Drupal Europe even though we set out to do so. We would not be able to organize another one with the same team for 2019 for sure as many of us need to shift focus back to their families and jobs. Therefore we are looking forward to how a shared model could work with an event production company directly advised by a community group. See you there! If you need more reasons to come, Paul Johnson created a video at Drupal Europe to showcase the various goals people attend Drupal events of this magnitude with.

“It was the first drupal event I attended and I must say I was amazed! I want to go again and do more workshops, more contributions, meet more people. Drupal has such an amazing community! ❤”

Survey respondent

Oct 20 2018
Oct 20

Imagine if you will, you have a an Events link on your main menu. Someone clicks on it and the Events landing page is loaded in their browser. How was this page built? With Drupal, you have several options. 

If you are the kind of person who likes to have a say in the way things are done, be it from a previous bad past experience or idle curiosity, the following will help you engage in the planning aspects of your Drupal site. So, let’s look at five recipes for building landing pages in Drupal.

  • Node page
  • Node Plus View Block
  • A View Page Plus a Block
  • Panel Page
  • Custom Theme Page

Node Page

Content pages in Drupal are called nodes. You fill out a form (e.g., a content type) online, save, and you have an article or event or some other kind of page. This page has a URL. That’s important to remember. Every page in a website has to have a URL. 


Using Drupal’s default Basic Page content type, you fill out the form. Give the page a title of About Us. Fill in the body field with information about you or your company. Add it to the main navigation menu with a check of a box. Lastly, you create a URL alias. Instead of the default format of /node/3, you want /about-us. Save and you see your new landing page.

Yes, it’s boring, but we’re just getting warmed up. 


Simple page. Simple technique. Easy to create and edit. Easy to translate in a multilingual site. And let’s not forget the other cool things you can do with a node.

Node Plus a View

Building on the previous example, let’s build an Events landing page. Obviously, this kind of page is going to be a little more complicated. Here are the requirements: a title, some introductory text, and a list of Events that you created using an Events content type. You will have many events so using a manual approach to creating and updating a list of events is not a fun idea.


With this scenario, you use the Basic Page content type and create a node titled Events. Using the body field, you add some text that describes your events. Like before, check the box to add this node to the main navigation. Give your page the URL alias of /events. Save and the first part of the configuration is complete.

The next step in the configuration process is a little more complicated, but it’s the concepts you need, not the details at this time.

Drupal has a module called Views. It’s an incredible tool that lets you create an SQL query on the database and then create a display for the results of that query. For this landing page, you need events for the future, not the past, so you filter accordingly.

Given we already have a Drupal feature with its own URL (the event node), we don’t need another. That means you will create a block display for the SQL query results. Blocks can be small bits of information or larger, more complicated displays. They can even hold forms. What they don’t have is a URL. They only show up because a page is there to host them.

Without going into all the particulars, you will place the block so it appears under the body field. If you want to know more about how this done, please join us in a Drupal 8 Site Building Best Practice training class.

When you go to the yoursitename.com/events URL, you will see the Events node and the view block that lists the upcoming events. With some styling, you can make the two features (node and view) appear as one, seamless. Or not.


Some will argue that you could have made a View page versus using this two step process. And, in the next example you will. In this scenario, you looked ahead and saw that the introduction text would not be a fixed blurb. You will change it from one season to another and your staff will not have the skills to edit a View.

So, this scenario worked nicely for your business process and staff.

A View Page Plus a Block

Let’s change up the requirements as a means of introducing another build option. You need a list of events, but instead of some introduction text, you need an image banner. There are several ways to accommodate this new image requirement, including adding to the previous scenario. In this example, we will use a View page and a block.


Create an SQL query, grabbing all the events scheduled for the future. Instead of displaying the list of events in a block, you create a page with a URL of /events and place it on the main navigation menu.

Next, create the block that will display your image banner. Like with most requirements, Drupal provides several alternatives to meeting them. For this scenario, assuming you are using Drupal 8, create a new block type called Image Banner. Add an image field to the new block form and set the field display to show only the image.

Create a block, using your new block type. Upload the image you need for the Events landing page. This process is very similar to creating a node. The input form looks similar as well. 

Place the banner image block either above or below the page title block to match your design. This is a quick and easy way to insert an image above the title of the page if that is your choice. 


A View page isn’t like a node. It doesn’t have fields. You can add a header and footer text, but it’s not the same as adding field to a node. Bottom line, a View show the results of a query - typically that of nodes. So, if you need to display information other than the query results, you might need to use methods like described above, by adding blocks or combining a node with a view.

Another reason for mixing and matching features to create a landing page is display. By default, a Dupal page - node or view - is broken into two parts: Title block and Main Page Content block. If we had chosen to add an image to the available header text box in the view, the image would appear below the page title. Yes, you can do some template coding and rearrange things a bit, but why would you if you could simply place a block and accomplish the same goal.

The point of all this is, remember that content comes in parts in the Drupal world, and quite often, a simple mix and match strategy is all that needed.

Taxonomy View Page

A technique that can be overlooked is the use of the default taxonomy term page. A term is a word or phrase used to describe the content in the node. By default, a term page displays when someone clicks on a term link shown on a node. The page provides a list of nodes tagged with that term. 

Let’s see how this default feature might be used to create landing pages by changing our focus from Events to types of content.


Imagine that you have three types of content that will be placed in a body field: How-to Lessons, News, and Blogs. Instead of creating three separate content type forms, you add a field that assigns terms to the content, declaring it a How-to Lesson, for instance.

By default, the How-to Lesson term has its own landing page. In Drupal 8, the term page is a View page and can be modified to meet your display layout needs.

Let’s take this scenario one step further. It’s come to your attention that you need a banner image and introduction text to appear above the list of nodes tagged as How-to Lesson. In this scenario, you can add an image field to the term and use the description field for your introduction text.

The results are very similar to what we have created in the previous scenarios: a page title, and image, some text, and a list of nodes. Place the page URL on the main menu and you have a landing page. 

Hopefully, this demonstrates the need to think about your processes before choosing a configuration strategy. There are several steps involved but it’s actually quite easy to do with a Drupal training class.


Websites can be complex and that might mean multiple content types. However, imagine that one of your staff is blogging the latest insight on gardening strategies and it morphs into a how-to lesson. If they created the blog post in the Blog content type, they would need to move that content to the How-to Lesson content type instead. 

If this is something that might happen, create one content type for narrative content and use terms to distinguish between them. If you do, you can then take advantage of the term’s default pages, like demonstrated in this example.

Panel Page

So far, our examples assumed simple displays. What if you want to create a landing page whose content is built solely from blocks. Basic text blocks. View blocks. Blocks from other modules. Again, there are several ways to make this happen, especially if your theme (that bundle of code that controls the look and layout of your site) has the appropriate regions to organize your blocks in the way you need.

For now, let’s assume you need something unique.


Panels is a module that you can add to Drupal. It provides a graphic user interface (GUI) and allows you to create a page with its own URL that can be assigned to the main menu. Remember, if you need a page in Drupal, it has to come from something that can have its own URL. You can also create a custom layout to display blocks.

The process to complete this task is too complicated to step through here, but it can be learned.


Some will say that you should create the theme regions you need versus using Panels, and they would have a valid point. However, if by now you are intrigued with the build process and are wondering if you might be able to do it yourself, then a tool such as Panels doesn’t require you to know how to customize a theme. 

Of course, with training, a custom theme is something you can manage. In fact, let’s consider one way of using a custom theme to create a page in your site.

Custom Theme Page

Let’s take a moment to consider the Drupal theme. Without going into all the details of theme development, at a minimum, you need to know that the theme defines the regions (header, navigation, sidebars, content, footer, and more) used to organize and display blocks. It also manages the templates used to say what gets rendered in the region.

For example, there is a page template. This renders the region if there is a block assigned to show in said region. You can add as many regions you want in order to accommodate the various block layouts you need.

You can also create a template for a single page. Let’s consider this strategy for a moment. 


Assume that you created a node using the Basic Page content type and titled it Resources. In the theme, you create a template specific to this node. At this point, it’s all about hand coding. You create a template that renders all the blocks you have created to display on this page. Then, with some CSS, you style the blocks in a layout of your choosing.

With the Resources node assigned to the main navigation menu,  you have the page you need because its custom template is hard coded.


To be honest, although this blogger has seen this approached used, it is not conducive to making quick changes to the page. Why is it listed as an option? Because, depending on who you hire to create your site, you might end up with a vendor that uses this technique. Be it on purpose to gain maintenance business from you or just from lack of Drupal building experience, you could end up with a site that does not meet Drupal’s flexibility characteristics.

Make sure you are specific in your requirements regarding the use of custom code if this is a concern.

Planning and Promet

The five options conveyed here are not the only options you have available. Moving forward, consider taking an active role in the development strategies chosen to create your site to ensure you receive a solution you can manage. 

Remember to build in time in your schedule to have development strategies discussed before they are implemented. If your developer is reluctant to let you in on their plans for meeting your requirements, they might not be the vendor for you. 

If you still have questions, check out Drupal 8 Makes it Easier and The Path to Migration to learn more about your options and considerations for your project.

Promet offers a unique planning engagement that we call our Architecture Workshop. This workshop is a customized engagement that engages all of your stakeholders in the Discovery Process.We do a 3-5 days of intensive onsite exercises with stakeholders (for your busy C-level folks we customize the agenda to bring them in where they are needed during this onsite). Then the team goes away and produces a set of deliverables that  includes a full-field level Architecture Blueprint of the website(s). Whether you choose to use a waterfall or agile development methodologies - you have everything you need to build the website everyone has agreed upon. 

Not building your site and stressed out about getting an accurate quote? Investing in this kind of Workshop will make sure that you get the right Partner, and the best price.

For more planning information email [email protected].

Oct 20 2018
Oct 20

The most common way to post content on a web page is via HTML text, images, audio, and video. No matter your approach to content delivery, you probably know that your approach needs to be accessible. Did you know that non-web content such as Adobe PDF documents need to be accessible as well?

Is your restaurant menu downloadable? Do you post your meeting agendas? What about event brochures or product catalogs. PDF files are great for such purposes and need to be accessible.

You might be wondering how one makes non-web files like PDFs accessible. That’s where the Web Content Accessibility Guidelines (WCAG) comes into play. Yes. The same criterion you use to create accessible web pages applies to non-web documents as well. Of course, not all will apply such as Bypass Blocks and Captions for video but the WCAG criterion will be your guide. 

Let’s consider some of the guidelines that will apply to non-web documents.

Applicable WCAG Criterion

When creating documents, you need to cover the basics. 

  • Declare the document’s language.
  • Include a title for your document
  • Use Header styles instead of manually bolding a header or changing its font size
  • Ensure that said headers are orderly, that you don’t jump from header 2 to header 4, for instance
  • Include a brief description of your images via alternative text 
  • Ensure color contrast ratios are met
  • Identify the meaning of shapes and icons that you might use
  • Declare header row in the any data tables you create
  • Resist the urge to use tables to manage your content layout
  • Ensure that embedded links have a clear purpose (no “Click here” links)
  • Remember not to leave inline bookmarks hanging without it’s partner link

The more complicated the PDF, such as those with forms, you will need meet other criterion.  However, for your basic content document, hopefully, you are thinking that this list doesn’t sound too bad. If not, you have help. If you miss something while creating your PDF, Adobe Acrobat has an accessibility testing tool that will remind you to check things it can’t, tell you if it sees something wrong, and will give you help to fix the issues.

But, let’s not get ahead of ourselves. The first step in the process of creating the accessible PDFs.

Create a Source File

Microsoft Office, Corel, Google, and Adobe are just a sampling of product vendors whose applications can create PDF files after its user has created a source file. Perhaps you are using one of these or some other application. As long as your source file can be made to accommodate the requirements listed above before you export a PDF, then you are well on your way to creating an accessible document.

Save As or Export a PDF

If you create an MS Word document, for example, the process is to save as a PDF. If you create an InDesign document, the process is to export. Whatever the vernacular, convert your source file into a PDF.  

Convert does not mean print to PDF, nor does it mean scan to PDF. Both of these options create an image of the text. That means assistive technology cannot see the text. 

Sadly, not all conversion processes work perfectly. That means testing and repair is required.

Test and Touch up the PDF

Even if you have a simple Word document with sections and subsections divided by headers, you can still run into issues once the file has been converted to PDF. Use the accessibility testing tool in Adobe Acrobat to check for hidden issues. 

For instance, by default, the Acrobat accessibility test result will likely tell you to check your color contrast - assuming you are using color in  your document. It might also say you don’t have a title when you do. FYI, the title being requested is part of the document’s metadata. Lastly, it will likely ask you to check the logical reading order of your content. 

You might think that checking the logical reading order can be ignored. You created a document whose content is presented in a logical order. How could it have possibly changed? Just to be sure, you scroll through the PDF and see that all is well. 

Logical reading order isn’t about what you see, it’s about the order assistive technology will read the content. So, be sure to click on Reading Order in the Accessibility options in Acrobat. Make sure that the numbers assigned to each item on the page conveys the actual order. You would be surprised how often the reading order differs from what you see.

There could be other issues the test reveals. Don’t worry about not knowing how to fix all the issues it finds. Acrobat provides links to short tutorials that explain how to remedy an accessibility problem it has found. 

However, before you fix something in the PDF, make sure it was formatted correctly in the source the source file. It if is not, fix it there and convert again.


If you have a choice between placing content on your site via a PDF versus HTML text, consider the HTML text first. Being more accessible than a file that one has to download, it is easier to format HTML text and it images to be accessible.

If faced with a multi-page source file that can’t easily be ported into HTML text, then plan ahead. Allow time to inspect your PDF’s reading order and remedy any accessibility issues before you put it online.

Not sure you have a problem? Email our Accessibility Experts - they can evaluate your site, and provide you with an Accessibility Scorecard. If you know your documents are a problem, we can estimate the cost of remediating those documents. 

Oct 19 2018
Oct 19

Digitisation has altered the game for content providers. Customers - whether businesses or consumers - look for bite-sized pieces of content delivered to their chosen interface anywhere and anytime. Content creators continuously need to rethink and rewire how they disseminate content across channels due to the proliferation of digital platforms, the variety, and granularity of media, and the ever-shorter attention spans of customers. And so arises the need for a Content as a Service (CaaS) solution.

A hand holding a sticker resembling a fish with Be Content written on it and real fishes in the background

The democratisation of content and the entry of social media and the technology giants into the content business are erasing the divide between media and entertainment market segments. This is building a new ecosystem that will be driven by content-as-a-service delivery models. Drupal can offer a magnificent CaaS solution for the organisations looking to distribute content on screens, websites, mobile apps, IoT devices and beyond.

A Peek at CaaS

An illustration showing the Content as a Service workflow with icons like mobile, desktop, house lock, shopping cart, watch and loudspeaker.Source: Bloomreach

CaaS is an architectural pattern that completely decouples the content authoring process from how it is used. Traditional CMS offers a single software to separate the data layer from the presentation of said data. Even though the presentation of the data is separated, it is still attached to the technology, delivery channels, and the capabilities supported by the software. CaaS comprises of a backend CMS that provides content authoring capabilities with APIs for delivering content to external systems.

CaaS is an architectural pattern that completely decouples the content authoring process from how it is used.

An efficacious content-as-a-service model enables enterprises to store content in a form and with the sort of detail which makes it easier to discover, repurpose, transform, and transmit. Today, service providers can leverage their application programming interfaces (APIs) as platforms for disseminating content.

Simultaneously, organisations must consider the level of granularity that is needed to store and expose units of content in the most effective manner. They should track the business costs generated by individual units of content so that their content supply can be refined and new business models can be developed. Even though technology constraints must be duly assessed, content providers should understand their content’s ‘lowest common monetisation denominator’ (LCMD) and the returns on content assets.

Executing content as a service

CaaS is a paradigm for delivering the right amount of content to the right kind of customer at the right time via the right channel. That is:

  • Content is enough to meet the demands of the customers
  • Content is personalised
  • Content is delivered accurately when the customer needs it. Updates are done in real-time.
  • Content is delivered on the platform of choice at the right time and then swiftly and endlessly transferred from one platform/ device to another.

A perfect CaaS model is integrated with numerous services that connect to a customer-facing platform and expose units of content on demand. These can constitute music on Apple Music, books and magazines on Amazon Kindle, or shows on Netflix. The ubiquitous nature of the IoT is expected to make CaaS indispensable as all types of data are gathered by big data platforms and made available to application developers.

APIs are the drivers for most “X-as-a-service” ecosystems and content-as-a-service is no exception to this
A graphical representation showing the the growth in Web APIs with a blue-coloured regionSource: Bloomreach

With the increase in platforms, formats, devices, languages and locations for exposing content, the ease, speed, and efficacy of governing and delivering it must also increase. APIs can transmit data to and from any destination faster and with cost-effective ways. In the API economy, APIs are developed like products for supporting new business models. An API strategy is a collaborative effort among product and technology teams to keep a digital business strategy on track. APIs are the drivers for most “X-as-a-service” ecosystems and content-as-a-service is no exception to this.

The value of CaaS

A linear flowchart showing the content value chain with icons resembling plus symbol and a person to describe the value of CaaSSource: Cognizant

The ability to precisely identify the smallest unit of content that can be stored autonomously and delivered profitably is the foundation of any CaaS model. This can be referred to as the lowest common monetisable denominator (LCMD) of content which can be tracked, tagged and reused. Through taxonomy and semantics, enterprises can store content at the LCMD level and develop an aggregate or smaller levels of the data on demand.

So once the organisation identifies the LCMD of content the evaluation can be done on the returns from pieces of content created at that granularity, that is, returns on a content asset (RoCA).

When can you use CaaS?

Following are the scenarios where you can utilise the capabilities of CaaS:

  • Mobile applications: Alterations to mobile applications, most often than not, needs the application to be resubmitted to a digital distribution platform vendor like Google or Apple for the approval. CaaS system enables businesses to alter the content in these applications without having to change the application.
  • Multiple channels: CaaS enables business users to deploy the same content to several delivery channels via a singular system rather than having to maintain different systems for different channels.
  • UX flexibility: Being independent of the presentation layer, designers can freely use any technology to develop their UX and are not tied to technologies or components supported by the CMS. Javascript frameworks, that evolve at their own pace, provides developers with greater UX flexibility.
  • AI-based application: Leveraging chatbots and other AI-based applications, it is easier for robots to consume content via an API.

Drupal as Content as a Service

Flowchart showing circles and boxes illustrating workflow of Drupal as Content as a ServiceSource: Dries Buytaert’s blog

If you want to enable your frontend developers to create engrossing customer experiences, Drupal’s content-as-a-service approach allows you to think outside the page-based mentality. Drupal’s CaaS solution helps in delivering reusable, future-proof content seamlessly by decoupling the back and front ends where needed.

Moreover, frontend developers can develop better experiences with Drupal’s presentation-neutral content and RESTful API and leverage tools like Angular, Ember, Backbone and many more. Ingestion of content from third-party content, for example, from aggregators and syndicators, to bring content into your Drupal environment can be done which can be disseminated to any channel. With Drupal’s CaaS capability, content is easily consumed by other websites and application that you choose.

It has all been possible because of the amazing work that is going on in the Drupal Community’s API-first initiative. It is actively working to advance existing and new web services web services efforts thereby making Drupal an excellent CaaS and optimal for developers. Through web services like JSON API and GraphQL or the tooling that accelerates headless application development like the Waterwheel ecosystem, Drupal as a content-as-a-service is great for developers.

Drupal is stupendous for both editors and developers

Drupal is stupendous for both editors and developers. The biggest advantage that Drupal has over its headless competitors is that it can be an amazing CMS for content editors to give them control over the presentation of their content and a rich headless CMS for enabling developers in building huge content ecosystems in a single package.
With Drupal perpetually powering more and more websites, it is also being extracted to its full potential in order to serve content to other backend systems, native applications, single page applications, and even conversational interfaces simultaneously.


As digital transformation accelerates, content providers are altering the nuts and bolts of their content activities. As more content is delivered as a service through a myriad of APIs, more data will get generated thereby assisting content providers in creating more precise business models.
Content as a service is like a treat for the developers giving them maximum flexibility in their pursuits of digital innovation. Drupal as a CaaS has been offering a great digital experience to both content editors and developers alike.
Drupal experts at Opensense Labs have been powering digital transformation of businesses through Drupal development.
Contact us at [email protected] to build great digital experiences using Drupal as Content as a Service.

Oct 19 2018
Oct 19

I have a card component with a title, image, text, and link. How come all my card variants are inheriting all the values from the default one? Short answer, you don't. It's a feature, not a bug.

Where this really becomes frustrating is when you have a pattern that lists a number of items in an array. In that case, all variants will have (at least) that many items, even though you may want fewer.

For illustration:

list.twig has something like this:

{% for list_item in list_items %}
  {{ list_item }}
{% endfor %}

Then list.yml has something like this:

  - join():
    - include():
        pattern: content-teaser
  - join():
    - include():
        pattern: content-teaser
  - join():
    - include():
        pattern: content-teaser
  - join():
    - include():
        pattern: content-teaser
  - join():
    - include():
        pattern: content-teaser
  - join():
    -- loads of more teasers for the main listing page

Now you want to create a variant of list such as list~related-articles, but with only 2 items. You'd expect this would work
  - join():
    - include():
        pattern: content-teaser
  - join():
    - include():
        pattern: content-teaser

But, no. This will still render as many items as were in the parent component. That's the beauty (a feature, not a bug) of PatternLab's inheritance system. To stop it you need to do something like this:

  - join():
    - include():
        pattern: content-teaser
  - join():
    - include():
        pattern: content-teaser
  - and so on, so each extra one is basically set to 'false'

When we do this with a component such as a card, we might also want to have variants such as card~no-image, card~no-text, etc. In this case, we'd have a card.yml like so:

card_title: 'My Card Title'
card_image: '<img src="https://mark.ie/path/to/image.jpg">'
card_text: 'The text of the card will go here'

However, if we create variants, each of the items in card will be inherited to the variant. You'll notice this if you try to create one super mega component for all variants of a hero component for example (hero title, pre-title, sub-title, image, alignment, cta buttons, etc).

In this case, what I do is create a default component card.yml or hero.yml and give it only values for items that will more than likely be in all variants (basically whatever you are going to mark as a required field in Drupal (or whatever CMS you are using)), then set all others to 'false' in the component. Now when I create variants I only need to override the specifics for that variant, since everything else that is being inherited is already set to false. I also create a 'Kitchen Sink' version of the component which shows every item in action but DO NOT create this as the default/reference component.

My default card.yml might look like this:

card_title: 'My Card Title'
card_image: false
card_text: false

Now my variants can look as simple as:

card_image: '<img src="https://mark.ie/path/to/image.jpg">'

And card~long-title will be just one line:

card_title: 'This is a long title on a card just to illustrate what happens when it wraps to more than one line'

And that is why this is a feature, not a bug - it allows us to write variants very simply and quickly. Is there a better way of doing this? I'm not aware of one. If you are, drop it in the comments. Thanks.

Oct 19 2018
Oct 19

We've made a list of Drupal camps and summits that you can attend in the last quarter of the year. Drupal events are bringing together Drupal developers, site builder, themers, end users and those interested in learning more about Drupal. We are attending Drupal events because of sessions and collaborative discussions.

Bay Area Drupal Camp 2018

The United States, Berkeley, CA University of California 24-27 October 2018


BAD Camp is just around a corner, and it’s four days of free training, single-track summits, contribution sprints, presentations, sessions and after-hours socials. There will be more than 60 sessions. 

DrupalCamp Ottawa 2018

Canada, Ottawa, ON University of Ottawa's SITE building 26 October 2018, 08:00-18:00


Drupal Camp Ottawa will have 3 tracks this year: the first one is Code & Development, second is Strategy: Business, Management, Communications, and Content, and the third is Front-End Development & Web Design. 

DrupalCamp Baltics Tallinn

Estonia, Tallinn, 37 Kultuurikatel 2 November 2018, 09:00-18:00


It is a non-commercial, annual one-day event with two parallel session tracks, where people share, learn and cooperate. There will be more than 10 workshops and sessions. 

North West Drupal Unconference

United Kingdom, Manchester Federation Hotel 3 November 2018, 09:00-17:00


Unconference has, unlike conference, no agenda or scheduled sessions. Attendees determine talks on the spot. Everyone is encouraged to bring a talk to the event, with the day having 30-minute slots including time for questions, and time for people to change rooms ready for the next talk to begin. Agiledrop is proudly sponsoring this event!

DrupalCamp Atlanta 2018

The United States, Atlanta, GA Doubletree - Buckhead 8-10 November 2018


It’s one of the southeast’s largest annual Drupal events. Featured speakers on this DrupalCamp are Preston So - Acquia, Jesus Manuel Olivas - WeKnow, Jacob Rockowitz - The Big Blue House, and Suzanne Dergacheva - Evolving Web. 

Drupal Camp Oslo 2018

Norway, Oslo 9-10 November 2018


There are tree lecturers announced already: Sally Young, a Senior Technical Architect from Lullabot, Baddý Sonja Breidert a CEO and a Co-Founder of 1xINTERNET, and Stella Power, a Managing Director and a founder of Annertech.

New England Drupal Camp 2018

United States, Manchester, NH Rhode Island College 16-17 November 2018


It’s the 5th annual New England Drupal Camp. This Drupal Camp sessions and training will focus on DevOps, anchored with a keynote presentation from Jeff Geerling, the maintainer of DrupalVM and author of Ansible for DevOps. 

DrupalCamp Ghent

Belgium, Gent Campus Schoonmeersen 23-24 November 2018


There will be two keynotes from Danielle Jacobs, a General Manager of Beltug, and Preston So, the director of Research and Innovation at Acquia. There will a lot of sessions about modules, use-cases and business with Drupal. Social activities connected with Ghent's hidden gems are planned.


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