 Hello? Good afternoon. Good afternoon. Okay, okay. So I think some of you are sleepy because of the time but yeah. Okay, so thank you for the good introduction. So you can call me Ian. So I'm from the WordPress group from Philippines. So yeah, we also been doing this some sort of word camp. So okay, so much for that. Let's go to the topic. So have you heard about Headless WordPress before? Who is here first time to hear this feature of WordPress? Okay, thank you. How about for those who have heard about this? Okay, so later maybe we can do some sort of a sharing. So I will just cover all the necessary points if you want to add more. So feel free to raise your suggestions, okay? Okay, so that's my face. Okay, so let's, before we start, so let's take a short lookback or throwback on how really WordPress started. So you know, oh, we all know that WordPress started as a blogging platform. So, but that's way, way long before. Then pass forward 15 years later, WordPress is the number one CMS choice for developers and undevelopers. So any hand for WordPress? Okay, so now estimated roughly 30% of top 10 million websites run on WordPress. So technically from being a blogging platform, WordPress has evolved really maturely. Not really it can do anything, but somehow it can accommodate any request or functionality you want to integrate on your website. So let's move on to the next topic. So let's do the introduction for the API. So who here have been using WordPress since version 4.4? Okay, so are you reading the release notes or not? Or you just update, update, then done? Okay, so the API functionality on WordPress was released on version 4.4. As because they want to go to a direction that it's being a fully pledged application framework. So meaning it is not just a CMS or just a simple blogging platform. They want it that it can now create applications. So how would you create applications? So first thing you need is you need to have APIs that would supply the application. So WordPress introduced REST API that enables the platform to interact with just about any sites or any web application. You can use WordPress as your back end. And then for your front end, you can freely use any framework that you want. Either if you want to use a JavaScript framework or just a basic HTML CSS with some integration of jQuery. It's up to you. So that's how powerful, how they envision WordPress to be with this API. So how does that work? So we all know that this is the basic setup of WordPress. So you have the teams that would act as the front end. Then you have the functions and the other built-in things there to be your back end. So example, you want to display the post title of Hello World. So before interacting to database, so we had a server and a PHP that would process the request. Then get it from database then displayed it on the web page that you are working. Next, please. So now comes the front end framework. So how does this happen? Next. So we have the Hello World application. So let's say that the Hello World is being used. You are using any of those front end frameworks. So how this WordPress comes to the picture? So next. So WordPress would act as what I said, your back end. It would get all the contents, it would perform the crude operation, create, read, update, delete. Then it would get what you feed into that. Then next, display it to the application. So sounds simple, right? So simple, right? Or it's too complicated to process. So let's put it this way that you are now separating front end, the main web application from WordPress. So basically you have now two working applications, okay? So next. So let's now get into the main topic. So there are two types of structure that you can use when building a headless WordPress. So any idea? What is the two structure that you can use based on the pictures? So what do you see on the first picture? What? What do you see? From WordPress. So what does this costume portray? So this is, we know Halloween, so trick or treat. So this is headless. So the first structure is the word itself, headless WordPress. How about the next structure? What does the girl doing to the boy? Saying goodbye. If you said goodbye, they have breakup. So they call it, that's the next structure we call it, decoupled. So sounds funny, but that's how they call it. Because before, as I said, the front end and back end, it's coupled in the WordPress installation. But since we're separating it, so the term they use is decoupled. So I don't know why they introduced that term. So let's get into the definition. Next. Okay. So for the decoupled, the back end where the content is created and the front end where the content is deployed is hosted separately. So technically you have two applications. So the first application is WordPress which serves as your back end. And the next, the front end is anything that you specialize at any front end framework you are free to use. As long as WordPress is your back end, you have no problem integrating this. The next is, the thing of this one is you have still the benefit of content preview. Because WordPress, they have this content preview where before you publish, you can check the draft first. Then see everything goes on how you want the layout to be before publishing. So with this, you can still do that thing. But the thing is you're not getting the power of the live preview of WordPress. Instead, you're utilizing the preview of any application. So I've used some JavaScript based frameworks for front end. So once you have changes, it automatically reloads. So still you can get the benefit of having your content viewed on how it would be displayed. The next is implement one is to one relationship. So it's like, you have this front end thing that would just serve for this specific front end stuff that you want to do. So it's not like you created a back end, then you can use it anywhere you want. So if you use a decoupled approach, it would follow a one is to one relationship. But comes next now, the next is structured, which is the headless. So headless is a totally independent back end. It's not like the decoupled that somehow it's dependent on the front end. This one is the subset of the decoupled. So you're just isolating WordPress as your main back end. Then that back end would implement a one is to many relationships. So example, you are maintaining couple of apps, but just displaying the same data. It's just in this app, the layout is different from the other applications. So if you implement this structure like just a headless one, then you can just have your front end developers that, okay, I give you this end points of API then up to you how you would lay out it. Okay, so they can create several apps up to them up to your front end developer. So any questions so far? So are we clear with the structure? Okay, so next is we're going to go now to the pros and cons. So next, the first pros you can get is a full speed ahead. So you have a fully optimized application because you see in WordPress, this is the first problem for beginner, the optimization. Because the optimization of WordPress is really hard for beginners because beginners just tend to plug in, plug in, plug in, plug in. So it becomes the site heavy. Unlike if you use a headless approach, your website would not be dependent on any external libraries all built in WordPress which is fully optimized. You can get the information very fast. The next is flexibility. So as I said, we have two applications back and forth WordPress then the front end which is up to you what you want. So you have now the flexibility to integrate it to different platforms regardless of what would be the front end as long as it can support the response, the JSON response from WordPress. You can have the flexibility to seamlessly integrate it. Then if you have updates, it would not be also too difficult to handle since the two are acting independently. Next is bullet proof. So another issue, security. So we'll tackle that later. But technically, you've been hiding your back end from public access since it's a separate application. So what they just see is the front end application. So the back end, they don't know where you're getting the data. So it would be somehow not really too hard but at least you would give your penetrators some challenge on finding where you are getting your data from application. So if there are pros, there would be cons. So you can't have all in one. So next is you need to be jack up all trades. So why? Because as I mentioned, unlike on WordPress, you're maintaining just one instance of application but now you're maintaining two. So two different applications. So you need to know how both of those is functioning. If you would be the one who will develop and maintain it. Because if you don't, because I believe if you're a back end developer and you don't know how the front end works, it would not make sense for the API's applications that you're doing. So because what would happen is example the front end, guys, hey, I need this, I need this. You would just do, you would just do, you would just do. You need to understand why they need it. Because a good back end developer, it gets all the logic. The front end just consumes everything ready. Example, I have this experience with my developers that we have this, we're displaying the price. So now the tendency is we first launch the application for Singapore clients. So the currency is $5, right? Then we also have a business entity in Kuala Lumpur and you know the currency there is Malaysian ringgit. So now they don't put the logic of getting the currency in the back end. So they put it on front end. When we deploy, so it's reflecting $5 even we are selling an item in Malaysia. So that's why you need to, you need to get to know both. So at least somehow the basics. So you know what you need to be included on your back end, on your WordPress. How you would structure the response for the front end. The next is, as I mentioned, being a jack of all trades, there would be a learning curve. So new technologies meaning new challenge. So example that when you want to integrate on a different framework for front end. So as I mentioned, you also not really need to master it, but at least get the concept, get the idea. So you know how you would build your back end. Then next is, you would be the utilizing WordPress. So you telling me I would be the utilizing WordPress. So why would I still go with the headless thing? So the only thing, that's why I mentioned you would be the utilizing WordPress is you would be losing the power of the VCWG editor and the live preview. But if that is not the case on the application you're making, then even it is a cons, you can still proceed doing this structure. So having said that, so I prepared some short demonstration on how you can implement WordPress a headless structure on your application. So this is actually, I'm not trying to do live coding. I already made the final output. So we just run through each component, the front end and the back end. Then we see how this would be beneficial or not to our applications that you are doing. Okay, so access me. Okay, so and here, familiar with the hero app. Hero app for Angular. So for Angular beginners, this is the first tutorial that you would be making. So I created this simple application that would list out all the data. Okay, would list out a set of heroes together with the short description and their logo. So basically, the layout is made up Angular. Where do we are getting the data? We are getting the data from here, WordPress back end. So the first thing I did, I do is I created a custom post type which is hero. So then from this post type, our application, our Angular application is receiving and displaying the data as is. So how that does happens. So let's make a quick review on the code. Okay, so oops. Okay, wait. Okay, so I created a plug-in. Why I created a plug-in? So because okay, so okay, by default, this is the endpoint of WordPress. All the data on your WordPress installation is here. You just use your domain then slash wp-json. But do we need this bunch of data? Not, right? So if you give this to your front-end developer that hey, you want all the data, okay, come and filter it there. So it would not really make sense for them. First rule of front-end developers, you just give me what I need. You don't give me this kind of whole bunch of things. So what we're going to do is, so first is we created a plug-in. So this plug-in would hold, I created a master class with these heroes that would hold all the functions. So first function is I registered a custom post type. So if you would see, it's just like a regular custom post type, your regular custom post type code. The only difference is this one, show in res. So meaning it would include this on your when you request for API in the WordPress. So if you remove that, those bunch of data that you see earlier, it would not include this post type. So next one is I just created the custom taxonomy just for presentation purpose. Then next is the custom endpoint. So let's go back to this API. So technically, we have this, oh, sorry. We need to give the front-end developers the exact data they want. Which is when we look at the app, the name of the superhero, the team, the logo, and the short description. So how do we do that on WordPress? So we will be creating a custom function and put it on a hook. So first is this hook register res route. So meaning you would be creating your own routes for this one. Since we don't want to use WordPress it has a bunch of data. We just need the specific portion of that. So we use that hook. Then the first parameter you put in there is the URL that you would be needing. Then next is the method which is if it's a get or post. So I think I don't need to elaborate what's the difference between get and a post. So for this request, we need to fetch the data. So technically the method we will be using is get and then next is why do we have a callback? So the callback would give you the structure of your response. So if you see get all heroes, so I created a separate function here for that one. Then if you would see I made a WP query function here to query all the post type with the publish status and the permission is readable. So this one is a self-explanatory thing. So we created the JSON response here. The first response would have the parameter of title which would be fed with the get the title function which technically gets the post title. The next thing is getting the post content. So get post filled, post content. So I put it in the description parameter. Then next is we need to get the image. So I just use the wordpress pictured image so we not introduce a new custom field since it's already built in there. So I just get the URL from that. Then next is the tags which team this superhero came. Then this would be the sample response. Okay, let's go back to the query. So here you go. So from a bunch of very big data we were able to filter out what we really need. So the title, the description, the thumbnail and the tags. Then now, you just need to give this endpoint from the you need to give this endpoint to the frontend developer. So when he started to code your application, so he just need to integrate this. Okay, so you see, he just calls this function and then it maps whatever output do we want it. So we see the hero. So if I change Superman's name, let's say okay, let's edit. Let's say X-Men. Oh, what happened? Wait, I'm not running my angular up. Sorry. Okay, let's come. Let's run our angular up. Okay, building, building. Okay, so you see from Superman it became X-Men. So that's how headless WordPress is being implemented. You would be just utilizing your WordPress just for those back-end things like updating the basic crude operation, create, read, update, delete then for display, you work out a separate framework either angular or whatever thing you need. So now having said that, so okay, let's go first to the security. So I just have here two points that you need to do. This is just the basic so I think we have a separate talk for security. Maybe you can chat, you can channel your questions to the one assigned to that. But these are just the basic that you need to know when integrating headless WordPress. First is the course. Are you familiar with course? Cross-origin error. So this is happening when the request from a certain endpoint is coming from a different domain. So it's a basic security of servers that it's implementing. But if you put this certain code on your application so it would allow accessing of your application to whatever domain your front-end application is hosted. Then next is this one. This is the most important. Having your API tokenized. So the one I made I showed you last earlier was not tokenized. So if that has a post method, so if they know the endpoint, they might abuse it and post redundant or unusual things to application, feeding your application with malicious information. But if you have this tokenization that before processing the request, it would match the token from the source to your WordPress site. Then if the token matches that's only the time that it would process the request. If it's not matching, then it would reject the request. So to be specific that is JWT or it's the meaning I forgot who knows about JWT JSON Web Talk that one. Habahan for him. Thanks for saving my ass. Anyway, so those are the two key points but that are just the basics so you need to ensure other stops, basic stops on WordPress like hiding your WP admins would still be followed. So next so having all that information on your hand now, should you go to headless WordPress or not? So here are the three things you need to consider. First is the cost. So having maintaining two applications meaning you need to spend more because let's say first on the developer if you are not good at front end, then you need to hire a front end developer then if your server can relate to applications, you need to buy or create a new instance of server for your front end application. So those are the things that you need to consider in costing. Next would be the multi-channel publishing. So this is the one I'm mentioning earlier that if you want to publish your information or your API through multi-channels, so headless WordPress is the best approach for you. Then next would be the maintenance. So basically if your site depends on daily maintenance performed by users and familiar with coding basics you may prepare to stick with the original implementation of WordPress or better hire a developer to help you set everything up and prepare your hands to get dirty. So it's up to you if you want to this is an exciting feature of WordPress. So it's up to you if you want to explore it or not. But still it would depend on the needs of your clients. So I think that wraps up my talk. Salamat it's thank you in English. So remember WordPress code is poetry. So thank you very much. Anyone want to send questions for again? For this approach. So this application is, I mean this implementation of WordPress is more up on the back end. So for SEO thing, if you're asking about SEO thing, so when we try to do this on one of our applications, so it's a main issue with I will not name the framework, the front end framework, but if you're using a JavaScript based framework because we all know JavaScript is client-side rendering and Google can't crawl or read that. So it would be a big issue with SEO. You need to dig in some technical knowledge in order to overcome or implement a successful SEO campaign if you would be but would still depend on the front end framework that you choose. But for WordPress, let's say if you install the basic plug-ins for SEO, it would not be really essential since you would not be using WordPress as a front end. It would be merely isolated as a back end. So for SEO, it would depend on the front end application that you would be using. I'm Carl. What's the JWT plug-in could we try and use if we want to organize? Okay, so for the JWT plug-in, not to brag about but I'm not letting my developer use a plug-in for that one. We are using our own tokenization just to be secured because it's not that I don't have trust using security plug-ins out online but let's say that if you are publishing any sensitive contents on your application, so I might recommend that not going through a usual plug-in if you can create your own tokenization better. It's just an easy one. You need to actually you can use WordPress for this one. You can extend that one. So you don't really need to do plug-in. As I mentioned if WordPress gives you this and you're doing development, then you can utilize it. So at least it's like WordPress is giving you this so why not utilize it. But if you can suggest any other, if you are using any other plug-in, so no issue about that as long as you find it secure, then the thing is you're getting your connection with the API calls securely, no problem with that. But for me when it comes to security I'm so-so with using plug-ins, okay? Okay. I was just about to suggest no questions. I thought Ian just now said he wanted to get in position. I'm a silly question which is not really a good question. Which tools you use for making this slide? Actually I was using Prezi Prezi, Prezi. P-R-E-J-I because I find PowerPoint boring because naturally it depends on how the speakers approach but that's what I observe when I present things. So if I'm just using Microsoft they just tend to okay. Okay. And like on Prezi, you get DC looking everywhere. Sometimes the slide goes up. So just use it just to get attention of the crowd. So at least they are when you see things are moving so you also get the attention of the people. P-R-E-J-I when you deploy the WordPress for Headless, the front-end of the course that are for WordPress are still there, right? Or how do you do that? Okay, okay. So for that one, so basically we are not really killing the teams we are staying as is but the server we're deploying it is an isolated one so it's not available for public viewing. So if they tried to view the domain, so they would be redirected to the front-end. We're doing that kind of mechanism. So you can really take away the front-end part because it's part of the WordPress installation. So essentially you can stay the normal. That would be beneficial if you would also be using multi-channel publishing example. You have a website and you have a mobile application. Because I have this one client before that he has a work. I'm developing his WordPress website. Then he hired the external mobile app developer. His goal is if I publish something on the website, the mobile app should do it. Then I don't know, he has a very lazy mobile app developer. He told me you create API, I just consume it. It's not that every time he updates I also update. So I find it sensible but then lazy guy I'm doing all the work. But then seriously speaking you can retain the front-end for your website. Then if you want to publish on applications. So that's the time this headless setup would be working. Because you need to update on just one instance then everything. Website, external, mobile or whatever applications that needs that information to be updated would also get the information. Can you remove it? I'm not really sure on that one because I haven't tried it yet but maybe let's see. Hi, this is Hassan from Bangladesh. I have a question like this is mostly about API, right? So is there any built-in feature for red limiting or throttling or anything like that? Actually there is something like that but it's kind of too technical. That's why I don't include it. It's a built-in in WordPress. Are you familiar with transients on WordPress? You would utilize that functionality of WordPress because the main issue is if you're getting a big chunk of data so the response would be really not really too slow but kind of not acceptable to the standards. So that comes now this transients and caching thing that WordPress has built in. You can fully utilize that one. So developer need to go to stress these things first? Yup, yup. Any more questions? No? Okay, three more minutes to guess what time it is. So we're waiting for this. So it's tea time now. We're ready to go.