Instead of marketers making the case for a CMS, it’s the development team making the case for cutting the head off the existing CMS like WordPress, Drupal, or Sitecore, or migrating to a different headless solution. This solution would allow the marketing team to make edits without relying on developers, while keeping the agility our development team required.įor a lot of companies, the path to a headless CMS happens in the opposite direction. We needed a solution that would offer the development team the flexibility they wanted. And without widgets and plugins weighing the site down, our Core Web Vitals were out of this world. If we wanted to add an embedded product demo on a page, that was no problem. If the docs team wanted to switch from Jekyll to Gatsby, they could do it. On the other hand, the development team had grown so accustomed to the flexibility the hand-coded site offered. As a fast-growing company, new hires needed to be able to make site edits quickly from day one. But as we grew, it began to take too long to onboard new marketers, and soon became untenable. This workflow worked when we were a marketing team of four. That simply wasn’t the case for traditional sites I’d worked on, like a monolithic Sitecore. If I had a request, they could make it happen. It had great Lighthouse Scores, and our development team could make branded site customizations left and right. While I admit it was a tad intimidating to learn git workflows and markdown syntax, it was obvious from the start that the tradeoff was worth it. At the time, this company didn’t have a CMS at all. It wasn’t until I worked at a small startup that I saw that the UI of the CMS-the part I interacted with as a content editor-was only a piece of the puzzle. And while none of these tools were perfect, they got the job done-for me at least. If I needed to edit a web page, I just logged into the What You See Is What You Get (WYSIWIG) tool and made the changes myself. ![]() Squarespace, WordPress, Drupal, Sitecore, Wix, it didn’t matter to me. From my perspective, the popular CMSes had slightly different UIs, but the same functionality. In 10 years of content editing, I’d never heard of a headless CMS. The ability to preview content before it is published goes away without additional coding, as does control over styling through the editing interface.I have a confession: for a long time, I thought all content management systems were alike. One of the main disadvantages is that much of Drupal’s out-of-the-box functionality is lost instantly. What Is Limiting Decoupled Drupal?įully decoupled Drupal has several advantages, but all new technologies come with downsides, and headless is no exception. Content is created and published through one system, and delivered to readers through another. It is easier for system administrators to limit access to areas of the infrastructure. This changes the typical web server / user connection relationship, and also means that content is delivered much more quickly, even when online.ĭue the restructuring of the CMS / front-end relationship, security is also improved. Site contents can be downloaded and rendered quickly through the “application” front-end itself. Each of these are able to render and display the same information in unique ways.Īnd when it comes to apps and widgets, headless also allows for offline access. There may be one desktop front-end, one mobile front-end, a widget front-end, and an app front-end. This is especially true when a developer wants to implement multiple front-ends. ![]() There are several reasons to adopt headless Drupal, the most common of which is because site owners and developers want to integrate technologies and designs that are otherwise incompatible with a standard Drupal installation. What Are the Benefits of Headless Drupal? We’ve displayed ReactJS above as it is currently one of the preferred technologies for headless implementations. ![]() What this front-end application runs on is different depending on the developer. In the example below, that application runs on ReactJS. This allows for an added layer of functionality and customization. ![]() Rather, a separate application decides how data from the Drupal instance is displayed. This means that a Drupal instance does not decide on the styling for a website. Headless Drupal instead allows content to be delivered to users through a separate front-end application.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |