[00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox has a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, how Headless WordPress works.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcast players. If you have a topic that you’d like us to feature on the podcast, well, I’m very keen to hear from you, and hopefully get you or your idea featured on the show. Head to WPTavern.com forward slash contact forward slash jukebox, and use the form there.

So on the podcast today, we have Lax Mariappan. Lax is a web developer based in the Philippines. He’s an open source enthusiast and lover of all things WordPress. Lax has been tinkering with websites since high school. But it all changed when he discovered WordPress in 2010. Lax currently works as a backend engineer at WebDevStudios.

We talked today about Headless WordPress, and it’s a complex topic. Headless is the concept of decoupling the WordPress admin from the front end of the site. WordPress will continue to work as expected, but the presentation layer will be done by a different technology. React Gatsby and Remix being some popular choices.

This implementation of WordPress is complex, requires technical knowledge above and beyond that needed for a more typical WordPress install. But it has its benefits.

Lax talks through all of this in great detail. How keeping on top of all the additional dependencies Headless WordPress requires can be time consuming. How it can create difficulties for content editors who don’t always get to see what their work will actually look like in real time. Why this approach to WordPress can take more time and resources during the build.

Lex explains how these problems typically crop up, and how it’s possible to plan ahead and build in solutions for all the problems that you might encounter.

If you’ve ever thought about going headless with WordPress, then the podcast today is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to WPTavern.com forward slash podcast. Where you’ll find all the other episodes as well.

And so without further delay, I bring you Lax Mariappan.

I am joined on the podcast today by Lax Mariappan. Hello Lax.

[00:03:30] Lax Mariappan: Hello, Nathan.

[00:03:30] Nathan Wrigley: Very nice to have you with us on the show today. I have to commend you for your staying power, because Lax and I have tried to record this episode a couple of times and he’s been incredibly, incredibly thoughtful about getting his, all of his equipment and everything working. So thank you, first of all, I would like to express my gratitude for you staying the course.

But before we get into the podcast, Lax, I wonder if you wouldn’t mind spending a moment just introduce yourself. Tell us who you are, where you are, who you work for, how long you’ve been using WordPress, all of those kind of things.

[00:04:06] Lax Mariappan: Thank you. It’s good to be on WP Tavern, it’s one of my favorite publications, and also the favorite podcast. So I’m Lax, Lax Mariappan. I’m from India, and also I’m from Philippines. So I would say I live in both countries, and I use WordPress since my school days, like 2009. So I was looking for a platform to build a website for an event or something, and then I found out Blogger versus WordPress, and I liked WordPress more even that time.

So since then, I’m using WordPress almost every day. And my first job I got started working as a PHP developer, I would say, and then fully focused on WordPress. And I wrote my first plugin in 2011. It’s a very simple one. It’s now kind of obsolete because Facebook changed it a lot. So I wrote a plugin for something to fetch Facebook feed. So, and then my journey goes on. Right now, I work as a backend engineer at WebDevStudios. So where I get a chance to learn and work more with headless CMS every day almost.

[00:05:09] Nathan Wrigley: Your work at WebDevStudios, I don’t know a great deal about the company, but my impression of the company is that you work with, how should we describe it? Enterprise clients. You’re dealing with fairly large projects. I would imagine sizable budgets. Those kind of things, right?

[00:05:27] Lax Mariappan: Yeah, yes. Enterprise level.

[00:05:28] Nathan Wrigley: So when we decided we were going to have this conversation, Lax introduced the subject to me of headless WordPress. Now this is a word which I imagine some of you have heard before. Maybe some of you have never heard the word before. Perhaps there’s a subset of you which have experimented with it, but I’m expecting that the majority of WordPress users have not.

So, first of all Lax, would you mind giving us a very, in depth I suppose is the right word. Give us an analysis of what headless WordPress is because I’m sure many people think they know what it is, but perhaps they don’t.

[00:06:06] Lax Mariappan: So headless, or decoupled CMS, so first we all know content management system, right? So WordPress, we are using WordPress now as a content management system. It started out as a blogging platform. We used it mainly for blogging. And then WordPress introduced custom post types, taxonomies and all that sort of stuff.

So we are now using WordPress to build simple to complex websites. Forums. Some people use it for their colleges, universities as a social media platform, and some of them use it for a job board and everything, right? So we have plugin for everything and we can customize it and we use it.

So when it comes to the traditional CMS, we call that as monolithic. I hope I’m not using too much jargon here. Monolithic in the sense it has everything into it. So for example, if you go to a website, the header, footer, the sidebar, and the content that you see and the forms and everything that comes from the same CMS itself. So it is going to be, let’s say, in the case of WordPress, it’s built mostly with PHP and JavaScript.

So everything is going to be PHP template with a bit of JavaScript and CSS to it. But when you say on the contrast, headless CMS, it means, so you can consider that as a, I would not say person. Maybe something like, you can imagine something that doesn’t have a head. So in the sense the body is the same, head is different.

So you can imagine that as, you are going to use the same admin panel and you are going to have the same WordPress features. You can add the content, you can add menus, you can edit anything, you can add users, all that stuff. But when I view the website, so it’s not going to be your theme. So it’s not the typical way of how WordPress gets rendered.

So instead we will be decoupling it. So that is WordPress admin will stay on another site. It can be on a subdomain or a sub folder, but the front end is going to be a different platform. So it’s going to be hosted in a, mostly a JavaScript based stuff. So you can use either React based frameworks like React itself or Gatsby, Next.js or Remix, or anything that you like.

And also you can either go in another route as well. So you can make it like a fully static website, or you can render it on every time as a server side rendering as well. So every call will go to the server and renders.

Okay, so now we can call that a small intro about headless. You may already know this one. It became a buzzword a couple of years ago, right? But now everyone wants to go as headless. I see that company goes headless, or my competitor goes headless. So I want to go that way. But, unpopular opinion. Maybe you might hear some other people say that too. Headless is not for everyone, or I would say not for every use case.

It depends on how much content that you publish. What are your goals and what you want to achieve. So headless is good, it’s performant, it’s fast, secure, and it gives you more freedom and flexibility, especially in terms of performance it’s really good. But I would say it’s not the something like you should go headless. It’s not the answer.

[00:09:10] Nathan Wrigley: So essentially you’re saying that there are scenarios where this is desirable, but there’s going to be other scenarios where WordPress, in the traditional sense of the word. The regular WordPress that you download, perhaps use a hosting company and it’s all driven by PHP. The normal way of doing WordPress. That might be the best solution for lots of people.

Okay, so we’ve got our WordPress website, which we can interact with, and then the content that comes out of that website is pushed to something else. And probably we’ll get into what the options are there. But let’s take the use case of a company which comes to you and says, okay, we’ve heard this buzzword. We think that we want to go headless.

What are the benefits of going headless? Let’s forget about all the problems that might be associated with it. Can we just iterate through the things that you will gain if you manage to pull off a headless WordPress website. Now, I know there’s going to be all sorts of different scenarios there, but maybe just pick out the low hanging fruit. Some of the things which you believe are really beneficial.

[00:10:17] Lax Mariappan: Yeah. The first and foremost, or the popular one, is the performance. So WordPress uses PHP templates. We will do everything with PHP and Javascript and also a little bit of caching to render our traditional CMS like traditional pages. If you use a normal WordPress installation with a theme. So that’s how it’s get rendered.

So there you can see it depends on the hosting company as well, and also how much plugins that you use and how you configured them. So that affects the performance of a site. But when it comes to headless everything is going to be bundled, and there will be how a normal JavaScript based application gets rendered.

So it’s going to be a modern web application where you have control over, for example, if your page doesn’t use certain CSS classes, those CSS will not get loaded for that page. So I would say the assets that are loaded, it will be less. And the images will be more optimized. In either case, like in traditional too you can optimize images, but it’s like the performance is the first one, I would say.

It’s going to be both developers will love it and also the site owners, and also, let’s say marketers, Everyone will like the performance aspect of it. And in terms of headless, I would say developers will like it, especially in terms of, so you can repurpose the content. So if you are having a CMS, WordPress as a headless CMS, you can use that same endpoint, get the data and display it in a different formats quickly.

Other than a WordPress theme. So for example, if you’re using a WordPress theme, you have to create multiple templates. So this is a template for mobile, and this is something that, for example, if you want to use it for a landing page, you may have to do some small or extra changes. But when it comes to headless, you can just customize it in a way that you want to.

For example, I want to have a landing page. I don’t want certain stuff to be there. So you can turn on, off certain components, that’s it. So it’s like you can render the blocks and render the content faster. So developers and designers will like it. And also, in terms of the security, that’s where I’m more interested in cybersecurity especially. When people say WordPress sites are not secure, that triggers me actually. Yeah, I do get angry.

So it’s like, you don’t have to worry about that. So you don’t have to worry about changing your login page url. Adding captcha to your login form, all that stuff. Because that URL is going to be safe and secure. No one knows where you are hosted your CMS.

[00:12:49] Nathan Wrigley: Can I just interrupt there? So could you explain that, because I imagine there’s a bunch of people scratching their head at this point. Because normally, let’s say you have a website, it’s example.com. You’re going to go to example.com/wp-admin, and there is your login page. But there’s something in between here. I’m not sure that we explained that quite. So just explain why the login is secure. Explain where it is and why it’s not normal WordPress.

[00:13:19] Lax Mariappan: Yeah, so I mean, normal WebPress is also secure but people can guess it, right? Say example.com/wp-admin, so they know. They can see from the source code and the page source, they can see oh, this looks like a WordPress site. And then they can guess the admin url. So slash wp-admin, it’ll redirect them to the login page, right.

But when it comes to headless, the example.com will be hosted somewhere, and the front end that you see will be different. So for example, let’s say CMS is your WordPress installation, all WP. So you can call that like wp.example.com. So that’s where your WordPress stays in. But when you go to the example.com, that’s your front end, so that’s just JavaScript and html. So it’s like, if somebody wants to hack your site or somebody wants to, just guess what will be the admin url. So they cannot.

[00:14:10] Nathan Wrigley: It’s a difficult concept to understand if you haven’t encountered this before. But what you’ve got basically is a WordPress website, which is the container for the content, but it isn’t the website and we’re not used to that in traditional WordPress. You go to example.com/ wp-admin, get redirected, log in, do all the things, and click publish, and as soon as you click publish, it will be present on the website. That’s not the way that this is working because the WordPress website is completely decoupled from the thing which is presenting it to the world, right?

[00:14:48] Lax Mariappan: Yeah. Yeah. Completely decoupled.

[00:14:50] Nathan Wrigley: So given that, there’s no connection between, okay, here’s my website at example.com and where I might log in. And because of that there isn’t the capability to just guess the login page and then bruteforce an attack and so on. So in terms of security, it offers that benefit. The thing which people are most worried about, somebody getting your admin password going in and spoiling your site. That’s highly unlikely because they simply won’t know where to look.

[00:15:23] Lax Mariappan: Yeah. And also, so for example certain normal pages like comments, so that’s where we get a lot of spam, right? So comments will go to comments.php. When you submit a form without any data, or maybe if it’s spam data, it just goes there, right? But when it comes to headless, we will be using some extra customization for the comments and everything.

So it’s not going to be the data will store as comments in the database, and it’ll be, you can view them as comments in the admin panel. But when you are viewing it in the site, so you are reading a blog post, you have a comment form, so that form is HTML and JavaScript. So that’s not how a typical, a normal WordPress form, normal comments form.

So that’s where you will get less spam as well. So you don’t have to worry about that too. Like people submitting spam data and also any other form. So that’s another thing. And you don’t have to worry about any other security related stuff, because it’s just static.

So people cannot do anything or manipulate data. So it’s going to be just HTML stuff. Whatever they can do is just view the data. So I would say in the headless, so if you are viewing some pages or we are in a archive page and post archive, news archive, any archive page or any other page that does the data and fetches the data from the database, all that stuff.

So all that stuff will be protected routes. So people cannot easily guess. Sometimes you might encounter database related attacks, right. So you may hear cross site scripting attack or any other stuff like, somebody trying to get data either they pull your data or they want to insert some other data to the database. That’s not the case.

Everything is going to be static, like just html, and it’s only read only. So people are not going to input any data. And the input will be just maybe a comments form, contact us form, something like that. And that will be handled. It depends on what form provider you are using, or how you configure it, but still it’s more secure that way.

[00:17:25] Nathan Wrigley: So just to reiterate the point one more time, just in case anybody hasn’t been paying attention. We have our WordPress website. It is used by the developers, by the content creators, by the editors. They do their normal work inside of WordPress, but the thing which is being viewed on the front end by the population at large is completely separate.

You’re just sucking the data out of WordPress and putting it into whatever you like. The security’s fairly obvious, you’ve explained that really well. The performance, obviously, if all that you are showing is static html, essentially. That’s going to load really, really quickly. Nothing needs to be built at the time that the page is viewed and so on and so forth. It’s already been created.

This all sounds amazing and of course that raises the question, why aren’t we all doing it? And you have given us, in the show notes you’ve given me, three different things which we perhaps should talk about, and some of them, you explained the problem and then we’ll get to the solution.

So the first one that you talk about is dependency hell, you’ve described it as. And, I’m guessing that having a headless site is not straightforward. We’re very used in WordPress to, novices can install WordPress incredibly quickly. You basically upload a zip file and unpack it and connect it to a database, and these days, you know, you go to a hosting company and not even that. You just click a button and, wow, there’s your WordPress website 30 seconds later.

I’m guessing that this is not the case for headless. There must be all sorts of complex layers of things going on in the background, and you say that in many cases it can become very difficult. Dependency hell. So describe the problem of all the dependencies.

[00:19:13] Lax Mariappan: So when you have a WordPress installation, we will be installing plugins, right? You might be, if you are using WordPress for a while, you are already aware of the jQuery migrate plugin. All that stuff. So WordPress uses jQuery even now. So jQuery is a dependency that WordPress requires. WordPress depends on jQuery in admin panel, and also on the front end.

So if you want to get rid of jQuery, it’s kind of, WordPress may not be the same, if you want to eliminate that. Because WordPress depends on it. So it’s something like, let’s say you cannot say that as a oxygen, but it’s something that we all need it. So we need that to survive. So WordPress needs jQuery to work normally.

So similar case, when you are building a headless site, you will be requiring a lot of frameworks, libraries, and also packages. So for example, if I’m going to choose Next.js as my front end platform, front end framework. So Next.js is built with React. If I want to use Next.js, I may want to use some other Next.js related libraries.

So it is something like if you are on Android, you may want to add extra apps on your phone. If you are an iPhone, you’ll be adding some more extra apps to extend, right? It’s the same case. Similar to plugins. Instead of that plugins, we will be adding packages. So that packages helps the developers to add extra features that we need.

So the problem here comes in is, everything gets stacked in and one will be dependent on another. So, for example, if someone is installing a package like for SEO, and maybe that package will require something else. And let’s say if Nathan is maintaining SEO package and I installed it, and for example, for whatever reason, Nathan becomes a musician and he doesn’t, he is not interested in SEO anymore.

So he may not be more active in maintaining that dependency, maintaining that plugin or that package. So what happens is I’ll be waiting for him to fix the bug or some errors. Or I will waiting for him to upgrade to the lightest version. But it’s not the case, right? So, my Next.js package will be waiting for Nathan, so it’s like I’m depending on him, but he’s not available. So in that case, I have to go and do that work as well. So that adds to our development timeline.

And then, so this is just one package and one scenario. So this happens with multiple packages and stuff. And this is not just Node or NPM packages. It also happens to WordPress stuff as well. So, for example, let’s say we have a popular forms plugin, or we have a popular slider or any other plugin.

So you will install that plugin and you want that plugin to work with headless. So how we are using headless, it’s the data is stored in the WordPress, and we want to get the data through either Rest API. It’s a method that we, you know, you go to a url, you ask the WordPress, hey, give me this data and it’s going to give. Or you’ll be using GraphQL. It’s the same. You go to an endpoint and you’re going to say, hey, I’m looking for this post. I want five posts from this date. So it’s going to give that data as well.

So either you use Rest API or GraphQL. The problem is a plugin that you are using, your popular forms plugin, your popular slider, or any other plugin that you’re using. LMS plugin, E-commerce plugin or any plugin, like a payment gateway. So you have a plugin and you want to use it with headless. So that plugin should work with the Rest API or Graph QL. So if that doesn’t work, if that doesn’t give you the flexibility, and then you are still stuck there.

Because you cannot go and create everything on your own, right? So we cannot reinvent all the wheels. We don’t have time to create everything from scratch. So that’s where it’s like that becomes a bottleneck. So you are like, hey, I found the plugin. I started working on it. It works up to this mark, but it’s not a hundred percent. So it’s like it does its job 80%. Now I have to go fill in that 20%. It adds to the budget, it adds to the development timeline. So that’s the dependency hell.

[00:23:15] Nathan Wrigley: Yeah. So in the case of all of the technology, which is in the background if you like, which we haven’t really talked about too much, but like you said, the things which you are requiring from third party developers. There’s a dependency there, and it’s very similar to the dependency that you may have on plugins, you know, you want them to be updated and so on, but you are adding extra dependencies. And of course, the more dependencies you’ve got, the more costly, time consuming it is.

I’m guessing that most of the things that you are depending on, in addition to WordPress and you described what a few of those were, you could, I suppose, do some due diligence and figure out which projects have been well maintained, updated frequently, and so on. And I guess in the open source world, much of the dependencies that you’re using will be open sourced, so you could fork them. But again, you are creating probably a large amount of work for yourself and your team.

[00:24:13] Lax Mariappan: Yeah that’s true. Well said. So it’s like, since it is open source, it’s good. Like lot of reviewers. We have a lot of eyes on the code, and you can fork it. You have the freedom to do whatever you want. But still you are looking for a solution and that becomes a problem. You have to fix that as well. And that adds to the, another dependency, another dependency. It becomes a cycle that you cannot escape sometimes.

[00:24:36] Nathan Wrigley: I guess this is a bit like a seesaw. You know, on the one hand you described all of the benefits, performance, security, and so on, of headless. And then on the other side is, is all of the things that we are now describing. You know, the dependencies and so on. You’ve got to weigh up at the beginning of the project whether one thing is worth all of the time and effort that may be required to do it.

And I’m guessing in many cases, certainly at the enterprise level, the answer’s going to be yes, because the budget is there, we can put enough bodies to work to make all of this happen, and if we need to fork things, there’s enough people on the team that can do that and maintain the project, which has fallen into disuse. But for a little project the seasaw may tip heavily against something like headless just because of the things that you’ve described there.

Okay. So that was our first thing, dependency hell. The second thing that you wanted to talk about was the fact that in the WordPress world, especially in the last five or six years or so, we are really used to what you see is what you get, WYSIWYG. You save something in WordPress, you publish something and you have almost a hundred percent certainty of what it’s going to look like. The backend looks like the front end, especially with things like page builders and so on. But you say that that’s not always the case with headless solutions. Why is that?

[00:25:55] Lax Mariappan: We will be creating custom blocks. So, either there are a popular way of building now custom blocks is with ACF. So you all might be aware of and using it, even though you are not a programmer, you might be using it, right? So ACF is easy to install and create some custom fields. So you can use ACF to block, to build blocks for the site.

So those blocks can be used or you can build your own custom blocks. You can use any block starters like, frameworks that are available now. Or you can just follow our, WordPress comes with packages that you can on build command, so you can just build your block in a matter of seconds.

But still, all this stuff. So for example, if you are having custom blocks, I’m not talking about just normal blocks, like where you add a paragraph or image or something very simple. That is easy to build and that’s easy to see. That’s different. But I’m here talking about something complex.

So for example, you can imagine that as an Elementor widget or, some other items that it comes with the page builders. So, let’s say a slider, maybe tabs, accordions, all that stuff, right? So that can be added through the blocks itself. But you cannot preview them, because when you add them in the admin panel and we add them in the content. Those content gets, you know, you can choose like, oh, this is the tab title, this is the content.

And you can keep adding the content, but you don’t know how it’s going to render in the front end. But let’s say if you are using some, there are a lot of free blocks and also even premium blocks available. So if you are using a block to build them, and then using the normal WordPress installation. Or you can use WordPress with the full site editing, the modern themes, or the hybrid themes, like old plus full site editing themes.

Still they both work well. Like you can preview, oh, okay, this is the tab I added this content. I can’t view this one. But when it comes to ACF blocks or other certain custom built blocks, you cannot preview them.

So when a editor or a user adds content, they may get lost. So I have a slider. I want to add three, four images to it. I may get lost. Oh, what’s the third image? What I have added there, and how it looks? Is the images correct? Is the text rendered properly or should I reduce any title or text or anything, right? So all this stuff becomes a little tricky. And also sometimes it becomes a pain for the content writers, content editors, and also the site owners.

[00:28:24] Nathan Wrigley: So in the normal, traditional WordPress, let’s say we’re creating a page, we add a page, and we use whatever tool it is that we want to use for that. We add in some blocks. We are perhaps using Elementor, whatever it may be. And we click publish and then we are able to immediately view that because WordPress is working in the traditional sense of the word. The page gets pushed through the templating engine and it’s rendered with its template and we can see it right away.

But because that’s not happening here. And the mechanism for rendering that page is entirely different. You can’t necessarily view it immediately. Have I kind of encapsulated that? What you are doing in the backend, because it’s decoupled with the presentation layer on the front end, you can’t necessarily always see it?

[00:29:16] Lax Mariappan: Yeah, so that’s the challenge. So the solution here is to customize the way you built. So for example, we can give them a preview button so they can preview what are the slides, and how they look. And they can see that immediately in the editor itself. Like when they are adding content in the block editor, they can see it.

And also the other way is to have a button, a preview button. So that will preview before the content gets published. So, you can change the workflow. So if somebody hits, instead of publish, you can have like a preview button or keep it as a draft. So that way it’s like nothing goes to the front end without your approval or preview, right? So you have to preview it and see, oh, make sure everything looks correct, and then you can say, hey, I want to publish it. Yes, confirm, publish it, and then it goes to the frontend.

[00:30:04] Nathan Wrigley: That’s fascinating. That’s really ingenious. So, because we can’t necessarily see it on the frontend, you and your team have built a custom preview system. So on a block by block basis, you can see what that block will look like when it’s rendered. So in the example of your slider, presumably where we’ve got three or four fields. We’ve uploaded maybe some text, we’ve uploaded an image, and it’s just a bunch of fields. Normally we’d click publish and we’d go to the page and preview the page and we’d see it right away. But in your scenario, you are going to hit a button inside the block to show what that block and that block alone will look like. Have I understood that?

[00:30:48] Lax Mariappan: Yeah, that’s what we did. Because the users, they are used to the traditional WordPress. And especially that was with classic editor, I mean the old editor. So if you insert an image, they can see it’s an image. And if you insert something, you can see. And we are all used to the page builder era, right? So if you add a accordion, you can see how the accordion is going to look.

But when it comes to headless, all this stuff is going to differ. So, the tabs, accordions, sliders, and also anything else, any other custom stuff that we built, we added a preview button, and when you click on the preview, you can see that right away.

Then you can make sure like, oh, the colors are correct, the image is correct, and everything renders properly. Because sometimes if you are not looking at the content and adding content, you might miss some data, right? So you might have missed a small setting that says full width, or you know, boxed. So then you feel like, oh, why this looks so awful. Oh, I’ve missed this full width button. So that’s how the preview button works.

[00:31:49] Nathan Wrigley: So if I’m looking at the block and it’s a, let’s stick with the slider just for the sake of it, and I’ve uploaded my images and whatever fields were required and I click the preview. Does it literally happen inside that block? Or is this some kind of modal which pops up and shows things? Or is it, is it literally taking over the block itself?

[00:32:09] Lax Mariappan: Ah, it’ll be within the block. Like it will replace, so for example, if you have a block and you are adding some content to it, and when you click on the preview, it’ll replace where you are adding the content, right? It’ll replace the form. Form of the block where you are saying like, hey, this is the title, this is the subheading, this is the description. Instead of that, it’ll just render the titles, heading and description.

[00:32:32] Nathan Wrigley: Right, and then you toggle that off again once you’re, once you’re happy. So, ah, that’s really interesting. So the workflow there is really very different. And I’m presuming that after a period of time, the people who are editing, creating this content, that just becomes part of the process? They just understand that, okay, rather than viewing the whole page or whatever it may be, post whatever, I’m just viewing this little bit, and I’ve done it several times now and I’m confident that if it looks right inside the block preview, then I can click publish, wait for everything to happen, and hopefully that page will go live. And, it’s just a different workflow that you have to get used to. But once you’ve done it several times, it’s, familiar and normal.

[00:33:14] Lax Mariappan: Yeah, it becomes part of the workflow. And also, like we discussed earlier, your site will be like, CMS.example.com. And the front end will be on example.com. Sorry, every time you have to go to example.com/about, example.com slash contact us. Instead of that we will have a preview button. So, you can preview each block and you, if you, or feel like, hey, I want to see how the whole page looks like, you can click that preview, and that will take you, or that will show you immediately, oh, this is how the front end, like example.com/the page will look like.

[00:33:45] Nathan Wrigley: Yeah, that’s a good point. We’re so used to the preview button being connected to the URL in question, because it’s being rendered by WordPress. You click the preview page button or whatever it may be, and it takes you to the correct place. In this case, there’s no connection between what the URL will be and where you currently are, so yeah, that’s fascinating.

Just as a bit of an aside. We haven’t got into this, but I think it would be a good topic to discuss for a couple of minutes. If WordPress is separated from the presentation layer, this sort of headless notion. How often does the website get regenerated, if you know what I mean? So for example, if we click publish in our headless WordPress website, what is typical there? Are you going to generate the page immediately and store it as static html? Or do some clients have different expectations there? You know, for example, if you are a, a site which needs to publish things regularly, perhaps you need that capability.

I click publish. I want that page to be live within a matter of moments. Or it may be that you’ve got a website where it doesn’t really matter if the pages are not built, I don’t know, three hours, six hours a day, whatever it may be. Do different clients have different expectations there?

[00:34:56] Lax Mariappan: Yeah, that depends on how the publication frequency is. If you want to publish immediately, we can do. If you are okay with publishing the changes after two, three hours, still we can do. So it’s about how you want to set, how you want to build the things.

So here, few things to consider. You can go with static, fully static website. That’s just static and only when a page gets updated. So for example, you have a hundred page. All of them are static and those pages will not be regenerated. So if you change just the about page and only that 99 pages will remain the same. Only that about page will get regenerated again. You can go that route.

And also you can go with, every time in the page gets rendered, you can go server side rendering. So every time that’s new, so you can go that route as well. So that depends on how you want to render the data and everything has pros and cons. The normal way is like how Next.Js does now. Because it is like, keep everything static and if you want to render something, you can still regenerate the specific page.

So this way it’s like you don’t have to build everything all the time. So you can build what has changed in the WordPress. You can see that in the headless frontend. And also you don’t have to wait for it. So, for example, if I go make some change and click update and you can see that immediately.

[00:36:21] Nathan Wrigley: Really interesting, because there is no exact way of doing this is there? You can just build it in whichever way you think is most beneficial, or whatever the client needs. You know, if, if it’s a newspaper website where, really I need to click publish, and within a few moments I need that page to be live because the content that we’re creating is tremendously important to be fresh and new and so on. But it may be that, yeah, you don’t have that expectation and you’re quite happy to have it work in a different way and publish on a, a much less frequent basis. I can’t really imagine a scenario where anybody would say no, I’d rather it was published less frequently, but maybe there are scenarios where that’s beneficial. I don’t know.

Okay, and the last point that you wanted to talk about was, the whole conversation has proven to be really interesting, but it’s pretty clear that there’s a lot more work involved in this kind of website. And so your first point was about the fact that the dependencies, lots of dependencies. Your second point that was that you don’t always get to see what you see is what you get in operation. And the third one is basically the amount of time it takes, the amount of resources it takes. You’ve described this as headless asks for more. Tell us about that.

[00:37:34] Lax Mariappan: Yeah, so when it comes to creating a normal WordPress, like a standard WordPress theme. So what you do is like, you start with your prototyping tool. Like it can be Figma, Adobe XD or anything. So you have your design ready, right? You are creating mock-ups, discuss with the client, and then create a mock-up and then find the variations, all that stuff. And you are settling in, hey, this is my design. And now I’m going to create the theme.

So, I want to create this many templates. I want to create this many menus, all that stuff. When it comes to traditional stuff, it’s like, you don’t have to consider too many things. So it’s kind of straightforward process and like designers and developers can, the engineers can work hand in hand. And it’s, you can follow Agile like, build stuff, reiterate and just deliver it.

So that’s how that works. But when it comes to headless, so you have to consider a lot of things. I would say the first thing is the knowledge or, you know, expertise. With WebDev Studios, we are, I would say kind of one of pioneers and also experts in WordPress plus headless stuff. So we have launched, it’s a open source like we have Next.js starter template. So if you want to try out Next.js a headless frontend for your WebPress site, you can just take a look at WDS Next.js starter. It’s free and it’s in GitHub, so you can just start using it.

So, expertise comes one, like whether you should be, have sound knowledge in that. So you can go and fix stuff. You know what you are doing and you know what to expect and all that stuff. But this requires something like, for example, I am a backend engineer. I have limited React knowledge. I’m now catching up with React, Next.js, all that stuff. But I would, I would not say I’m an expert at it. I build stuff, I still use Next.js every day, but it’s like, I won’t say I’m an expert at it.

So expertise is one. So your team should have sound knowledge in the framework or anything that you do. Or even if you don’t have sound knowledge, let’s say if you are doing something like, something very new, like Remix got released only one or two years ago, right?

So if you want to go use Remix, You should be an expert in React and you should play around with React. So that’s the time. So my point is like time, it asks for expertise and it asks for time. So when it comes to just normal WordPress theme, probably you might finish the theme, let’s say, in a few weeks, or at least a few days even sometimes. With page builders finish it in few days or few weeks, right?

But maybe if you are building it from scratch and you are doing a lot of customization, it may take a while. But when it comes to headless, may take even longer. So more expertise, more time, and all this adds up to more budget.

This may sound like, oh, well should I do all this stuff? It’s kind of worth it. So you don’t have to, for example, if you have your, the front end components ready you may be having your storybook, like where you want to see how the button should look like, how the elements, how the panels are. Let’s say how each component will look like and how they render, all that stuff, right? So when you have all these parts ready, you can go from, for example, today I’m using Next.js, sooner I can move to something else, like I can use Remix. Or I can use something else that’s going to be hot in the market in future.

But when it comes to the typical WordPress, you are going to change everything from scratch. So if you want to add a new theme, so maybe if you want to change the look and feel, that’s different. So everything has pros and cons, but the short answer is the headless CMS ask for more.

[00:41:13] Nathan Wrigley: Yeah. It does sound like not only do you need more time to develop all of this for the reasons you’ve just described. It’s more complicated, so it takes more time. There’s more moving parts, shall we say. And it may also be that you need to spend some of that time not just building the thing, but learning how all of this hangs together, because there’s an awful lot going on in the backend here. And if you don’t have expertise in that, presumably things could go pretty wrong.

With that just before we end. You’ve obviously decided at WebDevStudios that this is an approach. I don’t know if you build the majority of your sites in this way or subset or a proportion of them, not sure. But, typically what is the amount of time longer it would take to get a website out? Let’s say, for example, that if you were just going to use WordPress as is a normal WordPress website, and you built an exact same website, but did it headless. And let’s imagine a site with, I don’t know, several different custom post types.

It’s got hundreds of pages. I’m just kind of making up something off the top of my head. But typically, you know, does it take twice as long, three times as long, 50% longer? What, what are we looking at?

[00:42:28] Lax Mariappan: I’m going to answer just like other engineers do. It depends. But it’s like, I would say it takes a long, maybe you can say, maybe you can say double, but it should not take more than double or something. So that’s where I would say start with more of research. So you should not change frameworks or libraries in between. Like once you started as React, go with React. And if your team is, they are very comfortable and they’re knowledgeable in React, use that. If you are going to use Vue.js or Astro or any other framework. When you start with something and you can go with it.

So, it is a matter of discovering what the client needs and where the goals meet. How we can achieve it. And once we are very clear on that, you can start developing. And during the development phase itself, we can see what are the possible, you know, the bottlenecks or what causes the issue, what could be a problem, and we can figure out other different approaches and solutions.

So, for example, you don’t have to let’s say, PayPal is not the only payment provider right now, right? The payment gateway. So we are using so many different stuff and they do the payment integration quickly. But before those days, let’s say 10, 15 years ago that case was different, so now we have more options.

So similarly, you don’t have to create a form and you don’t have to wait for someone to, the third party or some other open source in a package or something to be ready. So either you can build something on your own if you have time and budget, or you can fork something and then you can adjust to it.

Or the other way is, I would say you can go with some existing third party or SaaS or any other solution, which is just already there and you can see how you can use it with WordPress. So these are the stuff that can reduce your development time.

So when you say if you are, I don’t know exact hours or something, let’s say a thousand hours. So if you say a thousand hours for a normal WebPress installation, so headless may take a little longer, 1,500 or 2000 or anything. But it depends on what the client wants and what framework you choose and your expertise, like, I mean, the whole team’s expertise. And also how well we plan, organize, and go.

So sometimes it’s like just the client takes so long to respond, or sometimes it’s just like, even the client is clueless or what’s happening. So that adds up to some stuff. And I would like to also highlight, when you hear all this stuff, somebody listening is, they will be scratching their head like, so headless is yay or nay.

So, recently, I cannot say the client name and stuff, but I would say, how we figured this out and how it is kind of helpful. So we had to publish more than 20 websites. That’s for a single client. And all of them are different, and all of them are headless, but that’s for a single parent company.

So what happened is, we had the architecture ready, right? So we, we know what happens when you publish. We have everything ready. I mean, the back end and the front end ready. So things become more easier that way. The development time is actually just for one site and then other sites, it’s just like, it was fast.

But we had enough configuration and enough options we given to the client. So every site is not going to look exactly the same. They have their own customizations. But still it’s like amount of development time is the same or is actually less when you compare to traditional. But it depends. It depends on what’s the use case? How, what you are trying to build and everything.

[00:45:52] Nathan Wrigley: Yeah, it really does sound, there were so many good perspectives at the beginning where, you mentioned performance and so on where this is definitely going to be worth it. I guess if the client is willing and the budget is available and the expertise is there, then this sounds like an incredible option. Steep learning curve probably, but a lot of benefits on the backside of that.

Lax, just before we round it up, if somebody has been thinking about playing with headless and they’ve listened to this and they think, okay, I’d like to take that a bit further. Couple of things, firstly, where can they get in touch with you? But also have you got any guidance about resources that they may find useful?

So that could be a website or a book or whatever it may be. So let’s start off with resources and then we’ll turn to you to finish it off. So what resources do you recommend to learn about headless in general?

[00:46:49] Lax Mariappan: In general it’s like you can start with WP Engine has their own blog. They have stuff about headless WordPress and they also have some of packages and stuff they maintain. They have Atlas. It’s a platform they are planning to go full fledged on headless stuff. And also you can read about GraphQL, WP GraphQL. Their team is more active and they share a ton of stuff on how to customize and maintain stuff with headless.

And also you can, like a shameless plug. So I’d also highlight about our WebDevStudios blog. So you can see a lot of headless related articles, tips, and tricks. If you want to play around like, you know, you don’t have to spend something to test it out. So you can go with a lot of free starter templates.

So we have, WDS has like WebDevStudios has a starter template. We have Next.js starter. So that’s a headless thing. All you need is your WordPress, and then you can install that on a locally in your laptop or machine, and then you can just test it out, how it looks, compare the performance and everything.

And also, like other developers and writers have their own stuff. Like Colby Fayock is a popular WordPress developer. He has his own Next.js starter. So you can just simply Google WordPress headless starter, and you can find a lot of starter templates. If you are a developer, go this route or if you are a, you know, site owner or you are just hobbyist, you want to just try or understand a little bit more?

You can still do that reading the resources, right? You can actually check our blog as well. WebDevStudios blog. We have, I would say a couple of headless related stuff. That’s one of the popular article last year. Why headless WordPress is trending. So you can see why it is trending, what to expect. You can read more details in that blog.

[00:48:40] Nathan Wrigley: Thank you very much. And then finally, just to finish this off. Where could people get in touch with you? Are you available on social media? Maybe an email address? Whatever you’re comfortable with sharing.

[00:48:50] Lax Mariappan: Sure. You can find me on, you know, Lax Mariappan. I’m on all the social media like Twitter, Instagram, Facebook, and everywhere you can find me. So you can reach out to me as an email as well, laxman.0903@gmail.com. Anywhere like GitHub everywhere is the same. Luckily I got my name on all the social media, so you can find it.

[00:49:10] Nathan Wrigley: Lax Mariappan, thank you so much for chatting to me today. I really appreciate.

[00:49:16] Lax Mariappan: Thanks Nathan. It’s been great. So I’ve been listening to WP Tavern Podcast for a while. Especially, I like to catch up with what’s going on. The new stuff with WordPress. So it’s good to be on the show,

[00:49:28] Nathan Wrigley: Well, you are most welcome. It’s been a really interesting and informative episode. Cheers.

[00:49:34] Lax Mariappan: Cheers. Thank you.