 I'm Christy Bonjaro, I am a WordPress Innovation Director at SiteGround and I've been working here for 15 years and for the past years we've been developing more and more things with headless WordPress systems. So today I want to talk to you about headless WordPress, different ideas to consider and I will hopefully help you out decide where going a headless way is for you and probably give you an idea about something that you can use to improve the way you do things, to improve your businesses and your flows. So to begin with I think one of the most important things when we talk about pretty much everything in general is that you should evaluate whether this is for you. For example, headless WordPress, what is headless WordPress? Basically you have a WordPress core system that supplies data via an API to a different application. It may be a React single-page app or some other system and it's a way of doing things, doing systems platforms that gives you a lot of flexibility but adds to the complexity of your system, of your platform, you need to spend more development work to it. So it's important to ask the right questions and to figure out whether this is the way you should do things. And the first thing I ask when I start working on such platforms is that is this a standalone project or you need to integrate it with something else, something existing? There is a lot of chatter on Twitter, on Slack, on everywhere about headless, headless, headless is not one solution for everything. Yes, you can build very fast systems with going headless. You can use all sorts of technologies but we can have a super fast, regular standalone WordPress website. You just need to have a proper team, proper hosting, proper caching, a good developer and you can achieve the same thing. So the first question is do you really want to invest that development time going headless and doing those things? And sometimes the answer is no and that's perfectly fine. WordPress is great out of the box and if you don't need to integrate it with your own existing stuff or with a different system that you're working on, you don't necessarily need to do it. So you need to have this in your mind. Really WordPress headless is very applicable when you have an existing use case or an existing system. For example, this is the site ground client area and we have WordPress powering our entire knowledge base of answers like tutorials, articles and this is, and we show this in a contextual manner. Our client area is a React application. It has tons of business logic in it, all the renewals, all that stuff that's already there. We can't rewrite that in WordPress and it doesn't make any business sense for us to do that. But on the other hand, I just can't make a WordPress website with all the support articles there and make it look like the client area. Our site tools, which is another application built in React which manages our entire hosting system. But I need to show that data to our clients. So we have a headless WordPress powering all that. Basically the React app here hits a WordPress API and says, hey, I'm on that page. We have a custom plugin that gets the page on which the content is requested and gets the client language because we have Italian, Spanish, French, Deutsch and serves the data through the API. So for us, it makes a lot of sense to do that. On top of everything, we can cache this in React, we can use front-page caching. This is very fast way to serve data from WordPress. You can integrate it seamlessly into your existing system without doing a lot of work. So for us, this works very, very well. And on top of it, if you have a centralized place where you host your app that you integrate with WordPress, you can cache very, very well that system and you don't need to have some very powerful server to host WordPress to power that. Those two pages are getting millions of hits weekly or... I'm sure it's somewhere in the tens of millions per month. But it's hosted on a super cheap cloud server that's just isolated. It's like 50 bucks a month or something at the cost. And another important question when we talk about this is, do you need to use any third party integrations that provide you functionality out of the box? Because for example, this was a very simple use case. We have posts, it's a WordPress multi-site actually in different languages. You have posts, you get the data, you render it. But if you have something more complex that you rely on, like learn dash or member press for courses or some sort of customized, let's say, ticketing system or whatever, and you get a certain functionality that is out of the box ready for you coming from a plugin that you have purchased that you rely on, you need to take into account that if you can't just use that functionality out of the box, at least you have to style it again to make it work for your application. So I'm not advocating against going headless, but you need to take these things into consideration. And this also sums up to the question whether this will pay off. For example, if you're doing a single thing, maybe it's not worth spending a lot of development time and money at the end of the day to build a very complex react application, backends, et cetera. But for example, how many of you are doing sites for clients? Can I see some hands? Ooh, that's a lot of people. And how many of you are sort of kind of embarrassed to give your projects ready with the default WordPress backend? Okay, that's quite a few less hands. But at least the feedback that we're getting from most of the people we're hosting is that they get a bit confused with the WordPress backend. And many big agencies, for example, invest into their own admin stuff. So this is another way of another very good use case of headless WordPress. If you're launching more websites to clients, it's worth investing the time in building your own admin panel. And it will be much easier to build a beautiful React app and give it to the client with their branding with only the menus they want to see than styling and WordPress admin panel, which is, I don't know how many of you have done this, but it's not an easy thing to do. And once you consider that, hopefully, headless WordPress is for you. And there are a lot of benefits from it. And one of them is performance. WordPress can be very fast if you cache it properly, if you host it properly, if you optimize it properly. So I started with that you don't need to go headless to have a fast website. But React apps are very well performing. You can host them on a CDN, you know, you can have a lot of your functionality cache on the front end. So here are some alternative ideas. If you have decided to go that way, that may give you some suggestions about what else can you do. Because the standard way is like you have an app, you do an HTTP request to the WordPress API, you get some data and then you render it. But the thing is that you don't even need to use the WordPress API. Like everything depends on your use case. For example, if you have a symphony framework of something, you can just include the entire WordPress in it. And then in your symphony code, you can use every WordPress function, every filter, everything you want, as if you're working on WordPress. And then you can get that data and use it for your own needs. So when going WordPress, when going headless, it's important to properly analyze your needs and do things depending on them and not just for the sake of doing something. And this is a very fast way of doing it. Probably it's not the most orthodox way of doing it. But it's very fast because you're saving a lot of HTTP requests. If you already have, let's say, middleware software or something like that that connects to a front-end, you don't need to add another set of requests to go back and forth, which inevitably adds to the loading time of your pages. Another thing that is not the standard way of doing things that we've been paying a lot of with is using doctrine or another object relational mapping system to basically map WordPress database to the ORM and then use the ORM to fetch data from. This way, if you need to get a query to the database, you can get it from doctrine, for example, because it has included object caching. It's really fast. And the beauty of it is that you don't call, you don't fire up the entire WordPress framework when you want to get a piece of data. And avoiding to load the WordPress framework saves a lot of precious milliseconds. And especially if you're doing something that is more traffic heavy, this is a good idea that you may consider. Using custom handles or filters and actions is something that you should know exists and it's very useful. When you get, for example, some error coming from an API, it returns the error message or the success message in a certain way. Feel free, don't be afraid to interrupt that and have your own message displayed in the way. And this way, you may save another millisecond for, depending on the actual message itself and you will get it in the proper format. And since we talked about front-end cache, about React apps, all sort of JavaScript frameworks use front-end caching as much as you can. It's your best friend. You're offloading your cache on your client's computers, which is the fastest place to get data from. And with headless WordPress, that's React, for example, or other frameworks that's much easier than going the classic way. Another benefit of headless WordPress systems apps is that they can be made much more secure than a standalone WordPress. I'm not saying that WordPress core is not secure. It's a very mature project. It's been for 20 years now. We rarely see any hacking or vulnerabilities that come from the core. But you all know that plugins are out there. They're not developed the same way that the core is developed and often we have vulnerabilities. So going headless allows you to easily isolate WordPress completely from the public. You can have it on a separate host name. It limits its access only to your application, no matter what it is, what it is written on. And this way, you'll be safe from all those attacks that target WordPress systems that target certain plugins no matter which one is it. And you still get the benefit of using that functionality through the API. Now one downside of doing this, we do it. It's great both for speed and for security because you're cutting off all the bot traffic, for example. But another something that's important to consider is that you may need to rewrite your URLs when isolating WordPress because it will live on a separate host name. That's just an example of how to do it. It's not a big thing, but you need to have it in mind. That WordPress doesn't know the actual URL it's working on. Another idea is to replace the WordPress login system. Again, that is something that depends on your particular use case. Big fan of Jot authentication. I don't know why it's spelled Jot. It's JWT, but it's Jot for some reason. But Jot tokens are very scalable. Big fan of it. Link your plugin at the end of the presentation. The beauty of it is that you can scale it very much. You don't need to have a large session storage for all the user sessions to store them. Tokens are super fast. But there are two ways of doing this. Now, if you want to know, if you need the information about the particular users, you may need to map the users coming from your application to the ones from at your WordPress database. If you don't need that information, if you're a business logic user, specific logic is somewhere else, you don't need to do it. You can make one admin account, one admin user that talks through the API to the application. Otherwise, you need to do user ID mapping for sure. Again, on the same topic a bit, you can replace WordPress access controller or integrate it with something external or integrate the microservice for this. Again, in case of our client area, we don't have any complex ACLs for our clients. We only want to know which is their language. But for example, if you're building, let's say, a custom admin panel and you provide it to your client, you may need to consider whether you are going to use the WordPress roles and capabilities or you have to map, again, something external. Next, I want to talk a bit about plugins and integrations because plugins are a big part of WordPress. Nowadays, I don't know a website that works only with Core. People sometimes are afraid to go headless because they're like, oh, I really need this plugin but it doesn't have APIs. Well, you can register custom APIs. It's very, very easy. If you haven't explored this way, the WordPress API is one of the best documented APIs out there. The guys and girls that have done this have done tremendous work. It's very well documented. Even if you rely on a plugin that doesn't have API endpoints, you can make it yourselves and you can make them provide the data in the format you need. Another thing to consider is that, especially when you're isolating WordPress from the world, you may need to make some sort of a middleware or gateway app to handle external requests, to handle webhooks. For example, if you're connecting, let's say, an online store to PayPal or to Stripe or some shipping provider, whatever, when you send them an order for a payment, they need to call you back and say, hey, that order was paid successful or the payment failed, et cetera. And if your WordPress is working from a hidden hostname behind a firewall that has access only to your app, you can just hit the webhook that's provided by WooCommerce, for example. It's not a difficult thing to do, but it's something that you need to develop and organize yourself just so you proxy those requests to the actual systems. And another thing is that you can modify plugin endpoints and responses to better fit your needs. Nowadays, most of the well-developed plugins have APIs, have endpoints. It's OK if the plugin does not return the data in the way you need it. It's very easy to modify plugin responses in a way similar to how child teams work. So don't be afraid of doing that and modify it as much as you can to best fit your needs. And that's the beauty of going headless WordPress. You can use WordPress not in any particular way and not necessarily the way we are used to use WordPress. And I hope that I have inspired some of you to try to build their next project in a headless way and improve the way you work with your clients and the way you build apps, systems, and websites. Thank you. Thank you very much. I think you still have time left. I have some time left for questions here. Shall we do a Q&A session? We have some mics over there on that side on that side. So if anybody has a question, you can line up. I was a bit fast so we can have more time for lunch. OK, that's great. But the problem is the lunch only started at 1 PM. So if you go there before that time, there's no lunch. So we have to entertain the people a little bit, I think. I'm a bit disappointed. Yeah, I know. But that doesn't matter. Now we have an angry, hungry crowd. Yeah, that's why we have to do our best to don't have an angry crowd. I hope we have a question. So are there some people I know it was very technical? There's a microphone over there and over there. Could you line up at the microphone because then it's easier for us? Maybe we also have an online feed that our people are watching us online and they can ask a question in online feed. And if everything works, then my mobile will get a message and I will ask that question also to his stroke. So let's go ahead. The first question, please. Hi there. Thank you very much for the talk. I have a question because you've mentioned that your admin area handles the setup via multi-site. And you've mentioned also the multi-language setup as well. What's your take on that? How do you handle this? What's your solution? Is that on? OK, so there are different ways you can go multi-lingual. Unfortunately, we don't have anything in core that's standardized and covered by the core API. But that may be good or not. But still you have to figure it out for your use case. What we do have is we have English, German, French, Spanish, and Italian. We have five languages. And the content is the same in the majority of articles. But some are not the same. For example, we have specific content for people in Italy and Spain that care about European stuff, others in the United States. We show them proper billing information depending on where people are. On top of it, we have different people who work in the content team, who manage those. And for us, it's very easy to have basically WordPress multi-site in which we have subsite in Spanish and Italian for every different language. And it's basically it's just a small middleware symphony app that gets the request from the React app. And it proxies the request for the article to the proper language subsite. And for us, this works pretty well because I can give the Italian content team access only to the Italian website. They don't need to do stuff. It has downsides. We've spent a lot of development. Not a lot, but we've spent development. We're doing, for example, when we add a new language. We recently added French. What we did is we migrated the English content in French. And then we had the team of translators, the French content team, translate that. So they don't have to open different tabs, copy-paste stuff around. We made it easier. We've been playing with automated translation, which is very easy to. You can use AI. Some people have to drink water. Somebody says on Twitter that every time someone mentions AI, you have to drink water and stay hydrated. But we use external microservices to translate. And it's very easy to move data from here and there. But we have different URLs, which is why multi-site works great in that case. I mean, my question was also related to a plug-in solution. That's why I asked about that one. But you've sold it via multi-site, right? I don't need to use a plug-in for that. Because I don't have a front-facing interface that users switch between languages. This is my React application. The client area, site tools, or other interfaces. That logic is there, the switching. The simpler you organize it, the simpler it is to maintain it. I have another one then. Because I have been playing with Headless lately a lot. And the biggest problem that I see right now, at least, because of lack of experience with building more and more applications like that or more websites, shops, whatever, there is a huge overhead or there is a huge difference during the development time between going headless and doing this the classic way, I would say. So how would you comment that? Or what would you recommend? I mean, of course, there is this basic question that you have stated on the very beginning. Do you actually need to go headless in the first place? Yeah, that's a decision that only you can make. And I believe it's more of a business decision rather than a development decision. If you're comfortable with working with APIs, if you can build yourself or you have a team of people, you can calculate how much that will cost. And if it's financially worth it, go for it. If you can provide a better experience for your customers from now on, go for it. Build your own branded admin panel for the websites you're doing. Most probably your clients, if you're an agency, for example, won't need to use 60% of the menus we see on the left side of it. And then they won't see the annoying advertisement but every single free plug in that now and then tries to jump over each other and show you even more and more and more and very important stuff. And so I believe that's worth it. And if you see big agencies like HumanMate, for example, this is what they're doing. They're building their own framework, headless framework. So when they provide, they have big customers, they charge a lot of money. So I believe that if you can invest, if you can spend that development time, depending on where you're doing yourself or hiring people, it doesn't matter. But if you can make that investment, it's worth it because the product that you're selling will look, will feel more professional and you will be able to charge your clients more. Thanks very much. You're welcome. Yeah, we are all here to learn more. So please don't hesitate to ask questions but I see we have another gentleman over there. Can you talk a bit about JWT authentication? WordPress has application passwords built in. And is there any kind of benefits to using JWT over application passwords and what do you kind of see those being? Again, as everything headless, it depends on the particular use case. Like for me, I'm building a number of products that are powered by WordPress. And if you already have some sort of a login system, it's much easier when you have an existing login to issue a JWT token and then authorize it at WordPress. And JWT tokens are very scalable. You don't need to store sessions. Hopefully your projects will reach millions of visitors daily or weekly. And JWT tokens are very fast, especially when you get it issued from something that already exists. I'm not saying that if you're building a standalone WordPress, you need to go and replace the entire login authentication system altogether. That would be meaningless and we'll waste a lot of time. But in case of SiteGround, I already have my clients logged into the client area. I just issue another token and they're authorized and they can get the information they need. Cool, thanks. I had a second one as well, which is just you talk a lot about obviously the REST API here. Have you used GraphQL at all and do you see any benefits with that? No, I haven't because on my projects, I don't have a need for it. There is a very good blog post on the WP Engine blog about that. You can Google it and despite the fact there are competitors, they have done a very good work in that blog post. And it's actually about Gutenberg and how the couple of ways that you can make Gutenberg render HTML. And you should take a look at it. It's a very well written piece of content to give you pros and cons about that. Thank you very much. You're welcome. So on the custom backend, which you suggested that it's a good idea to make, it is possible for us to load the Gutenberg. So that is the right thing. That should be the main reason why we will be using Atlas WordPress admin. We'll be able to include somehow that into our custom React application. Yeah, you can do that. Gutenberg is written in a way that, actually the idea as far as I'm aware is that other applications use Gutenberg, not just WordPress. So it's pretty easy to use it and implement it into your projects. But because that's just the page building part, right? Everything else is there too. Users, settings, all that stuff, dashboards. What about custom plugin blocks, for example? If you load Gutenberg once, then you can benefit from all the custom plugins that are written for it. It's not limiting you. If you need to accommodate it, they have some interface outside Gutenberg, for example, but that depends on the plugin and whether you wanna show it at all. Because you may want to have, you may want to have, let's say, the Yoast plugin working for your SEO content, but then you don't want to show their settings because you're configuring all the settings for the titles and keywords and stuff like that. You're doing it for your client. You just don't render that interface and give them a better user experience. As you're still using, you don't have to maintain an SEO plugin. I hope that answers your question. Yes, thank you. Thank you. I'll see you next, gentlemen, lining up. Hello, hi. Hello. I was really interested in what you said about symphony and doctrine. Could you please explain it more about the use case? Well, the use case of doctrine is when you have a big WordPress database for us, for the way I've used it with my team. When you have a very big WordPress database that you need to query, basically you map that WordPress database to doctrine, like clone it and synchronize it. And then you fetch the data from doctrine, which comes, it's a PHP library, it comes with Object Caching and everything, and it's very easy, very well written. You don't have to write queries. It's not a big of a learning curve. I urge you to take a look at it. It's a great piece of tech. And what you're doing is you're getting the data directly from that database, and it's very fast to get the data from there. And you're not hitting the WordPress database, which maybe, which has a lot of other things. You're building an index only of what you actually need to query and query it in a very, very fast way. As for the symphony, our use case is for a product that's not launched yet. So I can't really speak in details about it, but basically we're building a product that sends emails, which is written in symphony. And but we need WordPress for content, for permanent storage and for other things. And we have a React app for the interfaces, which talks to the middleware, to the symphony app. So in that case, if you want to add WordPress to this existing infrastructure, you would double the amount of HTTP requests if you have your app making one request to the symphony and then symphony making another request to WordPress and you get all that back and forth. And this adds up a lot, because every time you do that, you're losing milliseconds and it's not performing well. Well, it's a bit of a, it's a bit of a not canonical thing to do, but if you just include WordPress, it works. I've tested it, we have really good cases of it. And you can use all the functions, so the data directly in your existing symphony app, for example, and then have only one call that you can't avoid between the interface and the backend. Thank you. You're welcome. Okay, thank you very much. Okay, I think we are almost coming to the end of this talk. And yeah, you will see, Risto has a lot of knowledge about WordPress and skilled airplanes and... I didn't talk about airplanes at all. Maybe that's the next talk on WordCamp for you to talk about that, and we do some team building out about it. But before, we always saw you at every WordCamp, but now you slow down a little bit, you're becoming a family man. And I think as a family man, it's also important that you learn new skills like cooking. So we have here something with a recipe for you. And... Thank you very much. You're welcome. Thank you. Thanks, everybody. Thank you. Risto Panjaro.