{"id":3346,"date":"2022-08-26T15:29:00","date_gmt":"2022-08-26T20:29:00","guid":{"rendered":"https:\/\/n8finch2024.local\/?p=3346"},"modified":"2024-02-26T15:32:00","modified_gmt":"2024-02-26T21:32:00","slug":"how-to-headless-defining-ways-to-decouple-or-use-static-wordpress","status":"publish","type":"post","link":"https:\/\/n8finch2024.local\/how-to-headless-defining-ways-to-decouple-or-use-static-wordpress\/","title":{"rendered":"How to Headless: Defining Ways to Decouple or Use Static WordPress"},"content":{"rendered":"\n
This post originally appeared on the Strattic.com<\/a><\/strong> blog on April 28, 2022<\/em>.<\/p>\n\n\n\n Over the past few years, you may have heard phrases like:<\/p>\n\n\n\n What the heck is all of this lingo?! \u200b\u200b<\/p>\n\n\n\n The web has come a long way over the years, and there\u2019s plenty of vocabulary to show for it, and our WordPress corner of the internet hasn\u2019t been unaffected. Today \u201cstatic\u201d, \u201cJamstack\u201d, \u201cheadless\u201d, \u201cdecoupled\u201d, and even \u201cserverless\u201d are all words to describe a way of building websites or applications, including by using<\/em> WordPress. I\u2019ve italicized the word \u201cusing\u201d because they are not fully or completely only WordPress experiences. These sites utilize WordPress to deliver content, data, assets, and more to web sites, web and mobile apps, and even desktop applications.<\/p>\n\n\n\n In many cases, these headless\/static\/decoupled sites use WordPress as a backend, and some kind of framework (often React) for the frontend. Because the JavaScript (JS) ecosystem has exploded in the last decade, it\u2019s often the technology used for frontends, and there are many solutions for WordPress interactivity using JS or a JS framework. Likewise, because WordPress is so extensible, flexible, and customizable, WordPress can interact with and exist alongside these JS solutions.<\/p>\n\n\n\n Sounds exciting, right? But does that mean you should go this route for your next project?<\/p>\n\n\n\n How do we start to wrap our minds around what\u2019s possible here? <\/p>\n\n\n\n A quote I love:<\/p>\n\n\n\n \u200b\u200b\u201dYour problem isn\u2019t the problem, your problem is how to think about the problem.\u201d<\/p>\nDan Sullivan<\/cite><\/blockquote>\n\n\n\n Let\u2019s define a few terms so we can better understand what\u2019s possible with different approaches and see how they interact with WordPress.<\/p>\n\n\n\n When Matt Biilmann (CEO of Netlify) coined the term \u201cJAMstack\u201d several years ago, it was meant to describe a philosophy and approach to building web sites and applications. The first part of the word was an acronym:<\/p>\n\n\n\n The idea was that if you were building out a front-end solution to handle data from other sources in a structured way, that was the Jamstack. <\/p>\n\n\n\n Specifically, in Biilmann\u2019s case at Netlify, it also meant serving up the solution from a global CDN for speed and scalability. These Jamstack sites would be statically generated sites, meaning everything was compiled, processed, and stored in a pre-rendered file before the user ever gets to the site.<\/p>\n\n\n\n It should be noted that Jamstack was never a \u201cstack\u201d in the sense of a LAMP, LEMP, MEAN, MERN, or any other grouping of services we\u2019re familiar with in web development; Jamstack always referred to an approach to building websites and applications.<\/p>\n\n\n\n Since the term Jamstack was coined, it stopped referencing JS, APIs, and Markup (HTML) specifically since they are actually found on the vast majority of sites on the web today, including regular WordPress sites. Every site uses markup (HTML is markup), APIs are incredibly prevalent, and pretty much every site today is running some form of JS. <\/p>\n\n\n\n You probably heard the term \u201cstatic\u201d used if you were building \u201cweb pages\u201d in the 90s. At that time, \u201cstatic\u201d described the method of building sites using only standalone HTML and CSS files to define the structure of your site and give it some style. <\/p>\n\n\n\n If you didn\u2019t hear this term, it\u2019s most likely because that\u2019s all there was, kind of like asking a fish to describe water: Blub static blub site\u2026 <\/p>\n\n\n\n Nowadays, when we talk about \u201cstatic\u201d sites, we\u2019re talking about sites that are generated with a more sophisticated process using tooling generally known as \u201cstatic site generators.\u201d These tools use a templating system to generate sites that are also solely comprised of HTML, CSS, and probably JS files, but their management and deployment is more robust than the sites in the 90s, and they are served from a CDN for fast loading times everywhere in the world, and greater reliability. These sites can also include technologies like edge and serverless functions for bringing some dynamic-esque functionality to static sites.<\/p>\n\n\n\n There is a subset in this world of static site generators, which is known as \u201cstatic WordPress.\u201d This refers to sites that are fully static replicas of a WordPress site, and have been pre-compiled by loading and scraping said WordPress site to get the rendered markup, styles and scripts that are distributed via CDN. These static sites use WordPress as the \u201csource of truth\u201d for editing and managing the content and frontend theme on the site, but is nowhere to be found on the public-facing live domain, which relies solely on static files.<\/p>\n\n\n\n Static sites served in this fashion are infinitely scalable, very fast, and super secure because \u201cthere is no spoon\u201d 🤓 \u2026 I mean database or backend to hack into. <\/p>\n\n\n\n On top of this, because the site is being scraped for the generated markup, you can still use most page builders (like Beaver Builder, Elementor, Divi and even the Gutenberg Block Editor) and plugins to construct, arrange, and style your site. <\/p>\n\n\n\n This is how we do things at Strattic, so we obviously think static sites are pretty rad 😎 \u2026but more on that later.<\/p>\n\n\n\n In standard headless WordPress setups, typically WordPress is the CMS and \u201csource of truth\u201d but has a custom \u201cfrontend\u201d and does not use a \u201cclassic\u201d PHP-based WordPress theme. This frontend is probably heavily reliant on JavaScript as mentioned above, and given the current layout of JavaScript land, it\u2019s typically built with React, though there are plenty of Vue, Svelte, Angular, and other options out there.<\/p>\n\n\n\n This also means that visitors are not reaching WordPress itself, but rather the JS application that is connected to your WordPress. It most likely also means that your WordPress and JS front-end are in separate \u201clocations\u201d:<\/p>\n\n\n\n This is really neat because you can now use WordPress as an API to get content and other data, as well as use it to send form submissions, comments, search queries, and more to your backend. With a tremendous amount of effort and developer resources, you can even run headless e-commerce, membership, or educational sites with this approach and generally on a better scale that you could on a typical single WordPress install.<\/p>\n\n\n\n So it sounds like headless implementations of WordPress solve all the problems, right?<\/p>\n\n\n\n Well, not exactly.<\/p>\n\n\n\n One of my favorite quotes related to development is: <\/p>\n\n\n\n \u201cSome people, when confronted with a problem, think \u2018I know, I\u2019ll use regular expressions.\u2019 Now they have two problems.\u201dJamie Zawinski (who did not like Perl)<\/p>\n<\/blockquote>\n\n\n\n Many folks want to go headless because they\u2019re confronted with slow page speeds, plugin or theme bloat, overloaded shared hosting services, and malware. They think, \u201cI know, we can implement headless WordPress to solve all that.\u201d <\/p>\n\n\n\n As an astute reader, you might have noticed that with this approach, there are now two separate applications to manage: your WordPress and your JS application. More fun, right? 🤓<\/p>\n\n\n\n Perhaps. But also \u2013 more problems. 😉 <\/p>\n\n\n\n Don\u2019t get me wrong, as a web engineer, I love these types of problems, they are fun to work on and implement. However, not all technology stakeholders might appreciate the extra complicated nature of:<\/p>\n\n\n\n And then there are the other stakeholders, who are equally important: marketers, website owners, web designers and even some developers who are not going to appreciate this new configuration. In a headless setup, a lot of core or plugin WordPress functionality goes right out the window:<\/p>\n\n\n\n On top of this, if your WordPress is still up and running all the time in order to serve as an API, it is still vulnerable to attack. A recent report<\/a> identified API attacks as the next biggest security threat. Routing API requests from the JS app through a serverless function or third party so it\u2019s not communicating to WordPress may partially solve this concern, but it also adds more complexity.<\/p>\n\n\n\n Speaking of complexity\u2026let\u2019s talk about \u201cdecoupled\u201d sites for a moment.<\/p>\n\n\n\n Why go headless, when you could incorporate even more services? This is where \u201cdecoupled\u201d WordPress architectures come in\u2026<\/p>\n\n\n\n Generally speaking, \u201cdecoupled\u201d takes the \u201cbest tool for the job\u201d approach. While you might start with a headless WordPress implementation, you may also add in some of the following options for additional functionality:<\/p>\n\n\n\n In this scenario, you might use WordPress solely to author content. 😱<\/p>\n\n\n\n Pulling data from multiple sources and using multiple third party APIs is often referred to as the \u201ccontent mesh\u201d. This is generally the recommended approach when using WordPress since you should use the best tool for each job, and while WordPress is by far the best-in-class CMS out there, it\u2019s not the best at everything and therefore shouldn\u2019t be used for all purposes.<\/p>\n\n\n\n You can see how \u201cstatic\u201d can build up to \u201cheadless\u201d which can branch out into \u201cdecoupled\u201d WordPress. This isn\u2019t to say that there is a stair-step approach or a hierarchy, only to note that it can seem that each of these methods informs and influences the other.<\/p>\n\n\n\n You might say: \u201cBut wait! Can\u2019t we already do this with WordPress on a server? I\u2019m already using Hubspot and Shopify and [fill-in-the-blank-service]. Is my site already decoupled?\u201d<\/p>\n\n\n\n Yep, it sure is!<\/p>\n\n\n\n It is possible to use a decoupled approach with a \u201cclassic\u201d hosted WordPress setup. This could involve using multiple third party plugins and services that live on your WordPress, but don\u2019t rely on your WordPress install to handle their functionality. <\/p>\n\n\n\n This is in contrast to using plugins that do rely on WordPress to function for their services. Here are some Decoupled vs. Native WordPress comparisons:<\/p>\n\n\n\n (Note: we\u2019re not endorsing one plugin or solution, these are just examples.)<\/p>\n\n\n\n We take a lot of services and integrations for granted in WordPress; we get so much easy functionality out of the box. The difference is if you\u2019re already running headless on the frontend, you will lose a lot of that native functionality and need to build it out to integrate with your WordPress site or third-party services. There may be some NPM packages that make this more straightforward, but it will still be something you will need to wire up to communicate with those services or your WordPress.<\/p>\n\n\n\n
\n\n\n\n\n
\n
Jamstack (psst, it\u2019s not really<\/em> a \u201cstack\u201d 🤫 )<\/h2>\n\n\n\n
\n
Static: Just the files, ma\u2019am 😎<\/h2>\n\n\n\n
Static WordPress<\/h3>\n\n\n\n
Headless: now we have two \u201cproblems\u201d 😏<\/h2>\n\n\n\n
\n
\n
\n
\n
Decoupled: the more the merrier\u2026 right? 🥳<\/h2>\n\n\n\n
\n
Function<\/strong><\/td> Decoupled<\/strong><\/td> Uses WordPress<\/strong><\/td><\/tr> CRM<\/td> Hubspot<\/td> MailPoet<\/td><\/tr> Forms<\/td> Basin<\/td> Contact Form 7 or Gravity Forms<\/td><\/tr> Search<\/td> Algolia<\/td> SearchWP, Relevanssi<\/td><\/tr> Comments<\/td> Disqus<\/td> WP Comments<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n