Choosing a CMS: Why Oakwood used Wordpress for Eytys.com

Centra Implementation Case

Project: New global DTC website for footwear and clothing brand Eytys
Centra Implementation Partner: Oakwood
Content Management System: Wordpress

This interview will give you insights into the benefits of headless systems and what the biggest challenges when working with headless content management systems are from the perspective of Vincent Boiardt, Technical Director & Partner digital agency Oakwood. His team uses the best available tools to build rich digital experiences for brands like Eytys.

Read on to find out:

• How headless content management solves problems of monolith systems

• Why independence in your ecommerce tech stack is crucial

• What the most important aspect is to consider when choosing a CMS

• Why Oakwood is frequently working with headless Wordpress

• Where the headless CMS market is heading in the future

Tell me about Oakwood, and your role in the company.

I’m the technical director at Oakwood Creative, I’ve been at the company for 13 years as one of the partners, I and our CEO run the company. Nowadays we do a lot of e‑commerce. We’re a digital design agency, so we do everything that has to do with design – that being said, we see code as part of our design delivery.

We do a lot of development ourselves, one‑third of our team consists of developers. We’ve been working with Centra pretty much since they started, I think we’re their oldest long‑term implementation partner. We really enjoy doing e‑commerce, especially when we get the chance to do something for brands that have an equal focus on both brand experience and functional, converting websites.

So you were pretty early on the headless train?

We did our first headless project with Centra 3‑4 years ago. However, we started headless even before that. We’ve been working with React for about five years, and when it comes to React, having good APIs is a must. 

When we started, headless wasn’t even a buzzword, but since then it has become quite popular.

What are the main benefits of a headless approach to e‑commerce and web development? What do you like the most, and what do your clients like the most?

We see ourselves as independent when it comes to tech, and I think headless embodies the idea of having one application and several different data sources. The CMS is considered a data source, the e‑commerce system is a data source. The big benefit for our clients is that they’re not dependent on all these sources integrating together.

Previously, when you had a big monolith system, you were dependent on a built‑in CMS, or you had to use a CMS that was compatible with your monolith.

With headless, you have fewer limitations when it comes to platform choices. This is very valuable for the clients because they’re not tied up, forced to commit to a platform long‑term. This means we could switch their e‑commerce platform at any time, and the user won’t even know that anything changed - because the frontend and user experience stay the same.

What is your approach to choosing the right CMS for your projects?

As I said, we put a lot of focus on being independent. I think one big factor is that you want the entire technology stack to be similar in a way. For example, if you work with an e‑commerce platform that uses GraphQL, it makes sense to use a GraphQL CMS so that you can use the same methods to fetch data from both the content and e‑commerce system. These are things we take into consideration for picking the right CMS, as well as the user experience for people that are going to work with the CMS.

For us, it’s important to control the user interface in the CMS. That’s why we’ve been using WordPress a lot lately. WordPress kind of went away when the headless hype started as people initially went for new systems. But WordPress is back as a really good content management system for the end‑user, who actually uses it every day to manage their site.

With WordPress, we also have a lot of control of the data output, so when we’re setting up the CMS, we can make sure the data output is exactly how we want it to be. The application can fetch data without needing a middle layer, which would otherwise be necessary to normalize/modify data in order to match what’s needed in the application.

Image description: Eytys digital flagship store was built on WordPress

From what you’re saying, I get the feeling that the most important thing for you and your team is to always meet the client’s requirements as closely as possible.

Well yeah, the client is going to be working with the CMS in the end, so it needs to be intuitive for them to use. They shouldn’t need a large handbook to be able to make changes and update things on their site. It has to be easy to use.

WordPress has been the easiest for us to customize and adapt to the client’s needs. But if our client needs a different system, we don’t mind changing it. We’ve worked with Contentful, Prismic, Sanity, GraphCMS, pretty much every headless CMS there is.

Since you’ve worked with all of them, can you tell me what were some of the biggest challenges that you encountered?

If we take Contentful as an example, I think the way you customize is not very intuitive as the possibilities to adapt the UI for your specific needs are a bit limited. For me, the fact that it’s SaaS is both a good thing and a bad thing. It means that you get all the security updates and maintenance, but you’re also stuck with a pricing plan that can be bothersome depending on what you need.

Take the way Contentful charges for different locales. You reach a limit quite fast, and you suddenly need to pay a lot more. In our case, most clients need to localize their websites for multiple languages. If you only need two, it’ll be great, with one language it’s not even a problem at all. At least that was a challenge that I noticed in the past. They might have updated it since then. 

Image description: View of the blog post editor in headless content management system Contentful

What would you like to see in the future of content management systems? Where would you like the market to go?

There are a lot of systems being built on similar tech stacks as we use, React, and so on. So you’re starting to see systems that can integrate with your app in many new ways.

For instance, you can re‑use components from your application in your CMS. If you’re using Sanity, you can integrate your own components so that the preview functionality is much closer to the end result that will be generated on the website. With headless systems, simple things like the preview functionality have suddenly become a much larger task than before. If you’re building a traditional WordPress site, previewing is built‑in. What you see in the preview is exactly what you get on the site.

But in our stack, you need to make sure that your application supports previews. Sanity makes it easier by allowing you to reuse components. WordPress too, with their new Gutenberg editor - it’s based on React, so we can build packages with our own UI components, and we can use the actual editor in the CMS. The person who edits the content will see the same components in the editor that are used on the website.

I think the future is kind of moving away from 100% headless, especially regarding the preview. A lot of people still use the CMS for one specific purpose: managing their website. They need to be able to preview their website, and see exactly how it’ll look after their changes - some of the current headless solutions might make it difficult for them.

So basically it needs to become a bit simplified again?

Kind of. For people working with the CMS, I think there’s a need for it to be less headless, and more visual. They need a clear understanding of how things will look on their website.