DrupalNorth.org - Tales from the Trenches, Building the First Multilingual Conference Site in Drupal 8 Beta

It All Began Over A Pint...

Last year after a Toronto Drupal Meetup, I was in a pub brainstorming ideas for Drupal North Regional Summit with Chris Luckhardt. I had just taken a sip of my pint when he exclaimed,

“The site’s got to be built in Drupal 8 — and as we’re Canadian, its got to be multilingual!”

After I managed to stifle the flow of foam from my nose - I regained my composure, and then told him he was Crazy.

But for some strange and yet compelling reason, the idea grew on me. A few weeks later I signed my team up as the drupalnorth.org website sponsor.

Jeff Eaton's Keynote. Photo by Chris Luckhardt.

The Team

We didn’t work alone. Dave Rhino from Digital Echidna was the Art Director. Chris Luckhardt acted as Product Owner. Novella of Kafei Interactive, and Jean-François of the Québec Drupal User Group did the French translations.

The (Limited) Scope

So the dev work had to be streamlined as we had no idea what problems we’d run into. We knew we could get away with something feature-light, as there’s some serious nerd-cred from actually building the first multilingual conference site in D8 beta - so we took shortcuts.

• Event registration was managed in eventbrite.com

• If possible, implement any functionality in the front-end using 3rd party code when practical.

• No contrib! (ok a little… 8.x date, pathauto & token)

We ended up with 4 functional requirements

1. Fancy Landing Page
2. Basic Pages
3. Collect Session Proposals
4. A really awesome schedule page.

Kickoff & First Impressions

We knew we’d shed a few tears on the build, but my expectations what would give us trouble were wrong. The first thing I noticed about D8 was how easy it was to get started in the authoring environment.

Major improvements include...

• CKEditor, with fielded image insert comes standard.

• Enable 4 core modules and literally everything can be translated.

• Everything that’s a list of content in the Admin UI is a view so it’s easy to customize.

Tear #1 - Figuring out Configuration Management Initiative

We quickly ran into troubles with configuration management initiative (CMI). My team is used to D7 Git + Features based workflows on pantheon, acquia cloud, and platform.sh. I heard though the grapevine that CMI was awesome (which it is) and easy (not quite yet).

The docs are still in early days so we spun our tires on getting things running. It wasn’t so much an issue of CMI not working as there’s a paradigm shift from D7’s Features.

Adding to the confusion there’s 2 totally different ways to use CMI.

Option #1 - Commit your config settings exports to your git repo (The good way)

Option #2 - Import/Export all your config as a tarball (The Insane way)

The problem is drupal comes with configuration defaults that dump the exports inside your sites/files folders (which does not get committed to git by default). Also the “export” button in the fancy config UI encourages the insane method of configuration with “one tarball to rule them all”. The git based export is done via drush.

 

Win #1 - Custom Theme with Twig

My team has been focusing on the front end for quite a few years now, but honestly it’s kind of frustrating how many contrib modules we need to use so we can get some half-decent markup (Panels, Fences, Semantic Panels, Aurora theme, Html 5 Tools, etc… )

We made a resolution - Either we’re going back to the basics and build most sites with D8's Twig theming ONLY (no panels or context), or we’re going to specialize in headless drupal and skip the theme layer entirely.

Good News Folks - Twig theming is Awesome!

It’s easy to learn, and most of the crazy theme functions are replaced with sensical twig templates. Honestly it takes a day or two to make the switch from D7 theming.

We ended up using:

• Classes loosely based on the Drupal 8 CSS architecture

• Sass partials to keep everything in fairly organized design components.

• Gulp Automation for:

  • SVG / Img minification

  • Generated style guides in Hologram

  • Auto-prefixer for css vendor specific prefixing

• Sliderbar.js for the mobile nav

• eq.js for width based element queries.

The theme layer’s flexibility let us leverage 3rd party tools very easily. We still have some markup I’d like to be cleaner, but wrangling the markup is way faster than in Drupal 7.

Win #2 - Multilingual Support

Back in beta-6 this gave us some trouble, but by beta-9 it’s really straightforward. Just turn on the 4 modules under “multilingual” and you’re done. This is a major improvement over the D7 contrib i18n’s many required contrib modules.

Then in your Twig templates you just wrap your content with the translate tag. It can get fancy, but the basic syntax here works great.

[code]{% trans %} Submitted by {{ author.username }} on {{ node.created }} {% endtrans %}[/code]

Or

[code]{{ 'Diamond Sponsors'|t }}[/code]

Tear #2 - Beta to Beta Migration

We didn’t want to upgrade between betas if we didn’t have to, but bugs in translation and CMI forced us to. The upgrades didn’t work at all. We literally recreated every content type, field, and view manually - Twice.  Beta 6 to 8, and Beta 8 to 9.

The only redeeming factor in the eye gouging exercise, was that the complex part of the build only started after we upgraded to beta-9. During the project, Head to Head contrib was added to make the beta upgrade process possible. It worked for us on a different D8 build, but something kept throwing errors for us. We’re guessing multilingual was the main difference between the site where the upgrade worked, and drupalnorth.org.

Win #3 - The Schedule & Live Updates

The main component we cared about was the schedule. It was the thing I knew most of the attendees were going to be using all the time so it got the most attention.

We created a “time slot” content type, which has an optional entity reference to sessions. It turned out to be a great way to structure the schema as we could add time slot content for lunch or keynotes, or render Session details from their referenced entities. Again this is 100% with Entity References in core!
 

Time is the Context that matters during a conference

We built a “Live Updates” panel, that shows what’s happening in the current “time slot”, and the next one. It's built with a simple custom module which added a countdown timer. When the timer expires it triggers an ajax call to refresh the events display. Here’s a quick video of it in action.

 

Tear #3 - Finding Solutions in The Core Issue Queue is Hard!

Predictably, we came across a few bugs during the build. Most were simple enough to fix.

Then we found a nasty bug when creating user accounts

After testing, we launched user registration to allow session proposals. Once live, occasionally some people couldn’t create accounts and reported 500 errors. We couldn’t get the bug to happen, but 3 random sources reported the bug, and 20+ others successfully signed up. Nothing says fun like a non-reproducible, yet very real bug.

We couldn’t find a solution

We theorized the issue might have been related to image upload, perhaps memory/resource load on the server, user module bugs, or caching bugs. We searched for a long time but couldn’t find any answers, until finally a fellow Drupal North organizer pointed us in the right direction.

Turns out it was a known critical bug the whole time.

New users accounts were assigned UUID (unique ids) which then got cached. So the next user (semi-randomly) would sign up with the cache UUID which wasn’t unique and Drupal exploded.

Fortunately the bug is now fixed. It was in the Entity sub-component the whole time we were looking for it. Unfortunately there are a lot of sub-components in core, and I didn’t think to look in Entity.

The D8 core issue queue is a vast, intimidating ocean

Don’t get me wrong, I love the contrib modules that are now in core. I’ve been using the issue queue for 6 years, and core’s issue queue is a very different place from contrib. Core is frequented by very smart people working on important tasks, and I don’t want to add noise or waste anyone's time. “Core Etiquette” is strict so I’m very mindful when posting or commenting.

I suspect we’re going to intimidate a lot of people with the status quo.

Stack exchange, IRC, drupal groups - they all have lots of great people & content supporting them, but for anything really new in Drupal (like all of D8!) — The issue queue is the documentation. Now that core is larger (and better), folks are going to spend a lot more time in the core issue queue. Many will get lost at sea. As a community I think we need to work on this problem.

Now that it’s all said and done…

I’m thrilled with Drupal 8. We launched with beta-6 and ended with beta-9. Only 3 contrib modules were needed.

D8 is now our default version of Drupal for “simple” client site builds. Yes there’s still bugs to fix, but the fact that we’ve have 3 live Drupal 8 sites running nearly 100% core-only has proven to me that the choices made regarding Drupal 8’s architecture were good ones.

Thank you to all the fine folks who have made Drupal 8 what it is - Awesome.