Delivering the next-generation WordPress experience for an iconic brand.
Technology
WordPress (PHP, MySQL), ReactJS, GraphQL, Gatsby
Date
2020
Services
Development, Tech Strategy
in partnership with
Introduction
We got a call from our long-term partner BlueGlass — a leader in SEO and performance marketing — about a new client of theirs… Rivella, the Swiss beverages brand. Could we help them build a state-of-the-art new website?
Rivella wanted a new website for their iconic brand and they had a clear wish list. These consisted of both improvements to the end-user experience as well as to the capabilities (and agility) associated with being able to update and expand the website. Above all, Rivella wanted to avoid having to rebuild their website in a couple of years and was looking for a solution that was foundational, supporting their multiple marketing promotions and online contests. It should do justice to the image of the Rivella brand and, in addition to a modern, fresh look & feel, invite the user to interact with the products and the “Rivella world” through functionality-driven blocks.
Finally, they absolutely wanted to avoid supplier and technology lock-in and high maintenance and license fees.
Through a carefully orchestrated process, we set out to do a large-scale multi-language, multi-geography headless WordPress website that delivered Rivella’s powerful, flexible, stable new website on a tight schedule.
Challenges
In paper it sounded simple, right? Create a new website. How hard can it be?
Well… not so simple. First, the website was set to be delivered on a very demanding schedule. Between kick-off and the delivery date, we had just under five months. 🏃🏻🏃🏻
Second, the website wasn’t just the website, but also two different engines to support current and future contests and sweepstakes. These required a ton of logic and anti-fraud checks to be implemented. 👀
Finally, the website and the underlying concept BlueGlass envisioned weren’t exactly suited for an off-the-shelf solution. The requirements (and eventual technical vision) required us to use a very popular CMS in a way that isn’t exactly its’ most common implementation.
Collaboration-First Environment
We got together with BlueGlass to clearly understand the needs associated with the website. As we went through the information available and started to draft some of the concepts we wanted to bring to life, we understood how important coordination would be.
This was a project involving multiple stakeholders both at the client (Rivella) as well as between both of our teams. We worked in-person (while that was still possible) as well as remotely fine-tuning the concept, design, and technical approach and then throughout the execution of the entire project in short iterations and sprints, designed to provide mutual feedback in the shortest possible timeframe. A better understanding of existing Analytics data allowed us to understand visit patterns, current challenges, and opportunities for improvement.
We wanted to make sure that technology decisions were fully informed by design and conceptual approaches and that, similarly, the design team had input from our team, even though that was not our primary responsibility.
Leveraging Figma’s collaboration-first tools we were able to discuss ideas, sketch potential features, think-through how those would be implemented in near-real-time, supporting BlueGlass in providing multiple versions for review and approval across a period of three to four weeks.
Choosing the right technology approach
We already knew the client wanted to be able to gain autonomy in managing the website (editing copy, photos, adding and removing certain sections). From the concept BlueGlass drafted we learned more: we wanted to have excellent SEO, good loading speeds, unique animations, and “touches” that could (now and in the future) bring the Rivella brand to life.
The promotions Rivella wanted to run from the new website were another (important) part of the requirements. We essentially required modular functionality that we could easily turn on and off and that, when on, could handle a fair amount of traffic.
First, the CMS
Vendor lock-in and license fees were things to avoid. Our eyes turned to open-source content management systems. The “natural contenders” were WordPress and Drupal. Why one over the other? Although Drupal gets some more love for corporate and government projects, we believe this is mostly due to (some) poor implementations and approaches with WordPress.
We wanted to use WordPress — we felt this was the right choice for a couple reasons: First it is a popular, widely used CMS — ensuring Rivella isn’t locked into us as the sole provider that can upkeep their website. Second, we felt it’s newest addition, the Gutenberg editor, provided a key element we were looking for: a solid, visual-first content management experience.
But we didn’t want to deal with some of the drawbacks of WordPress. How could we build this as a modern web application running with WordPress?
An Headless Future
We felt the requirements and criteria we had set pointed towards the same direction: a headless WordPress implementation. We’d keep the flexibility and benefits of WordPress as a true content management system while introducing a limitless hyper-modular user-facing website with a modern tech stack (still, far from vendor-locked by picking ReactJS) ensuring flexibility, maintainability, and ultimately providing a better UX.
We don’t like throwing technology at a problem. Sometimes (most times?) less is more. So wouldn’t your typical website be enough? Our assessment was that in light of the needs presented — the criteria for the website and the existence of these functional “micro-apps” — the benefits of this approach far outweighed the theoretically more complex initial development
A choice, at last
The final tech stack was decided. We’d use WordPress (powered by it’s PHP engine) on the backend — making full use of Gutenberg — and a static-first frontend built with ReactJS.
Choices are just the beginning...
These choices provided a couple of additional challenges and we needed to make critical decisions on them. Since this approach (stack-wise) isn’t super common there isn’t a lot of literature and lessons learned to use as a basis for these decisions.
First Server Side Rendering… two options:
Server-side-rendering (SSR) which would render the webpage on request time on server-side then hydrate the code on frontend again. This could work but server-side-rendering for content that does not change sometimes up to a month at a time and doesn’t have user-specific (personalized) content is a bit unnecessary and adds a potentially avoidable layer of load-time.
Pure Server-side-generation, which would render all the pages down to html+css+js on build time. This seems a much wiser alternative, assuming we can provide a build process with zero downtime… which was achieved in the end 💪 This also is slightly more performant than server-side-rendering as the only thing happening on the server-side during request time is general webserver I/O compared to code generation+ I/O.
Any dynamic components (such as the social wall) that require more frequent updates are also fetched and lazy-loaded after the initial load of the page (client-side) and javascript-loaded into their appropriate place in the page.
After some research and initial experiments (done in parallel with and informed by the design process) our choice to accomplish the above landed on a popular framework for those familiar with the React.js ecosystem: Gatsby. It also provides decent SEO and loading speed optimizations, including image processing at build time.
Leveraging Gutenberg and WordPress
A big part of our reasoning to go with WordPress was to fully leverage Gutenberg. Gutenberg has gotten a lot of love… and hate. Historically, WordPress is a very specific community and environment. A lot of the WordPress developers grew out of plugins and the traditional PHP/JS(JQuery) stack. The introduction of a javascript-first editor with concepts such as “building” was a big step forward. But this — we felt — was the exact step forward we needed.
The idea behind Gutenberg of “blocks ” was also well aligned with our wish of modularity and following the DRY (Don’t Repeat Yourself) principles. This meant we could develop any page section as a “context-abstract” piece (in Gutenberg lingo “block”) that could then be freely used by the marketing team of Rivella on any page. Develop once, use as much as you want. Yes, it is as good as it sounds.
Going back to the requirement “on design-driven content editability” how can we achieve this and inject the data into Gatsby?
We came up with a structure that catches “custom components” (basically any section of the website) added to the page on the Gutenberg side, and renders Gatsby equivalents of them during build time. To avoid the mass of unnecessary code appearing, code splitting has been done so that unnecessary code never gets loaded. This also means Rivella has the ability to temporarily “hide” a Gutenberg component while not having to remove it from the page.
This also required having a down-to-the-pixel styling of the Gutenberg editor. When you’re editing the site on the admin-site you’re seeing something very close to what the user will eventually see, reducing errors and providing what is a better editing experience. Given both our frontend and Gutenberg are ReactJS-powered we were able to build shareability of code — ensuring we only code (and style) components once, then making them available in both Gutenberg as well as Gatsby for static-generation. We guess this is WYSIWYG taken to another level.
So far so good but can it be better? Of course. Gatsby provides an image processor for fast loading images that are available on local disk space. However there is a problem, the images are uploaded on WordPress which is not where Gatsby lives. After a bit of thinking and prototyping, we came up with a structure that fetches any image that comes with the content on build time, saves that to disk, processes that, and serves the optimized image. This also allowed our client to not worry about unoptimized images messing up with their load times.
In the end the full website is a series of static files generated by Gatsby and not influenced by WordPress load or processing times or any backend functionality (that, when needed, that’s called post client-side rendering).
There is the habit of using 3rd party pre-built components in web development. These are packages for ReactJS and (the dreaded) plugins for WordPress. This leads to maintainability issues and bigger bundle sizes (and thus load times). We were able to selectively use these packages and plugins while ensuring that nearly 90% of our codebase is custom-built, providing better performance and future-proofness.
Modularity and Promotions
We strived for modularity with the entire website. This was well taken care of on the CMS side with Gutenberg that, as discussed earlier, by design somehow forces that modularity.
But we also had promotions and sweepstakes that our website had to support. These were more functionally-advanced but also modular by design. Although Rivella had been developing from scratch each of its regular promotions most of the logic was the same. We decided to approach this as pluggable modules that had two layers: (a) abstractable logic; (b) specific-promotion-details.
This meant that, for example, in a popular bottle-cap-sweepstake the system we developed wasn’t designed just for that specific promotion but for any similar one they’d run in the future. The code-processing, fraud-detection, detail validation, win-determination are all agnostic sets of functionality that can be deployed with any future sweepstake. Sure, the form labels might change, details might be added, but the core of the functionality is there.
And this isn’t just a budget-aware decision. The fact that we can reuse the same exact set of functionality in the future, means that any improvement we do today is there, instantly available, in the future, without having to be thought of and implemented again.
These ended up being custom-coded WordPress plugins with little to no dependencies with re-usable classes of abstractable layers, coupled with specific functionality for that specific promotion (such as an additional field or a special format for codes). All of them, of course, API-exposed to the headless React.js frontend. Rather than “separate microsites” these are components right within the website. These modules are designed to be as independent of each other as possible, so they can be turned on and off easily and so that if one of them fails the others continue — within reason — to operate normally.
Localisation
Multi-language and multi-geography were requirements from the get-go. Thankfully we were able to accomplish this leveraging WPML, a popular localization plugin for WordPress quite a bit, together with a fair share of custom functionality.
We needed both translated pages as well as pages that were either country-specific or shared amongst countries.
This setup allowed us to generate sitemap trees of pages according to their language and country that our Gatsby builder could process like they were just a “normal” page.
And this didn’t deter us from our will to modularize. Components are shareable across languages and regions and “behind the scenes” functionality was added to link these components together.
This means that taking their editorial process a step further, Rivella can leverage that foundational work to, for example, trigger a notification or alert when a linked section’s copy is changed but its another-language-equivalent isn’t.
Following the same principle, a shared component used across languages or regions can be updated just once, becoming available in each of the pages it is being used at.
Staging and CI/CD Process
“This sounds cool but who’s triggering these builds? I gotcha, this is where you squeezed-in those billable hours.” you might be thinking.
Well, a lot of work was also put in place to safeguard the website and create a smooth editing experience.
First and foremost we created two client-safe environments: staging (where the client can play with changes and confirm they are ok) and production. Keeping both as truly separate was both inefficient and risky (the client could confuse environments). Therefore we centralized website editing under one WordPress dashboard. Changes can be done there and then built into the right environment. The client can still benefit from rollback and push to the live environment once it has been fully tested in staging. The way Gatsby applications are usually built is through CLI, however, an end client wouldn’t want to use CLI. So we have built “Deploy to staging” and “Deploy to production” buttons into the WordPress dashboard through a custom plugin we have written from scratch that triggers our build process for respective environments. The code served to the world only would get updated after a successful code generation completes (build doesn’t happen on top of the actual-served directory) to avoid downtimes or causing site unavailability if the build fails. And if a build that was triggered by Rivella team members should fail, we have laid an emailing pipeline to get an SLA triggered and someone looking into it (this hasn’t happened yet, so…).
We separated the code-editing from the content-editing. Both have different deploy and build pipelines. This means a client editing a page and making it available on the live environment won’t accidentally trigger a super-secret-feature (i.e. code, not content) to be deployed.
The Result
The result of this process was a brand new website that is future-proof, developed in under five months from concept to final deployment through the work of multiple teams in close sync. The new Rivella website has a solid technical foundation that enables a rich and versatile user-facing website that is ever-evolving and modular. It is visually rich, fast, and designed for SEO and it includes many possibilities for Rivella to run their popular sweepstakes.
It is also secure — with many behind the scenes tricks to ensure the tamper-resistance of both the website as well as the promos.
To top it all up, Rivella can freely edit the website’s copy and sections through a visual editor and have full autonomy to publish these changes, benefiting from a staging environment designed to avoid production-level mistakes.
Despite the innovative approach, this was a budget-friendly execution that also cared for a final product that has no vendor lock-in and no license fees during its lifespan.
At the end of the day, if they want to continue working with us it should be for our continuous good work, not a silly lock-in.
