 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, so that's my pace. Okay, so let's, before we start, so let's take a short look back or throwback on how really WordPress started. So you know, oh, we all know that WordPress started as a blogging platform. 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 that 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 hello, okay. 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. Meaning 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 ask 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 display it on the web page that you are working. So but then, okay, next please. Okay, next, next, next. Okay. Okay, so now comes the front end framework. So how does this happen? Next. So we have the Hello World application. Okay, so let's say that the Hello World is being used, you are using next 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. And 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 do you see? From WordPress. So what does this costume portray? So this is a, we know Halloween, so trick or treat, so this is a 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, 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, hello? So anything that you specialize at, 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, hello? 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 your any application. So I've used some, so this 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. Then next is implement one-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-to-one relationship. But comes next now, the next is structure, 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-to-one relationship. 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'll give you these endpoints 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. Next, the first pros you can get is 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 put plug-in, plug-in, plug-in, plug-in. So it becomes the site heavy. And like if you use a headless approach, your website would not be dependent on any external libraries all built-in in WordPress which is fully optimized. You can get the information very fast, okay? The next is flexibility. So as I said, we have two applications back-end for WordPress then the front-end which is up to you what you want. 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. Okay, next is bulletproof. 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. Okay, 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 APIs or 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. 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 on getting the currency in the back-end. So they put it on front-end. When we deploy, so it's reflecting $6 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 at least get the concept, get the idea. So you know how you would build your back-end. The next is, you would be deutilizing WordPress. So you telling me I would be deutilizing WordPress. So why would I still go with the headless thing? So the only thing that's why I mentioned you would deutilize WordPress is you would be losing the power of the VCWIG editor and the live preview. Okay, but if that is not the case on the application you're making, then even if it is a cons, you can still proceed doing this structure. Okay, 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 your 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 of Angular. Where do we are getting the data? We are getting the data from here. WordPress back-end. So the first thing 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. So 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. So but do we need this bunch of data? Not right? So if you gave 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, then those bunch of data that you see earlier, it would not include this post type, okay? 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, okay? 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 default because 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 build, post content. So I put it on the description parameter. Then next is we need to get the image. So I just use the WordPress so we cannot 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, very big data we were able to filter out with what we really need. So the title, the description, the thumbnail and the tags. Then now, just ananga, you just need to give this endpoint from the superheal because you need to give this endpoint to the front-end developer. So when he started to code your application so he just need to integrate this. Okay, so you see, 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? Waita, I'm not running my Angular app. Sorry. Okay, let's run our Angular app. 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, 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 channel your questions to the one who 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 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 your 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? Jason Webtoque. Yeah, that one. Habahan for him. Thanks for saving my ass. Anyway, so. 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 accommodate two 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 unfamiliar 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 or 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. Okay? So thank you very much. Can anyone send questions for him? I think he just want to ask you for this approach so this application is I mean this implementation of WordPress is more on the back end. So for SEO thing if you're asking about SEO so when we tried 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 a client side rendering and Google can crawl or read that so it would be a big issue with SEO you need to dig in some technical knowledge overcome or implement a successful SEO campaign but would still depend on the front end framework that you choose but for WordPress let's say if you install the basic plugins 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 plugin could we try and use if we wanted to organize? Okay so for the JWT plugin not to brag about but I'm not letting my developer use a plugin for that one we are using our own tokenization just to be secured because it's not that I don't have trust security plugins 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 usual plugin if you can create your own tokenization it's just an easy one actually you can use WordPress for this one you can extend that one so you don't really need to do plugins as I mentioned if WordPress gives you this and you're doing development then you can 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 plugins no issue about that and 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 plugins okay okay I was just about to suggest no questions, I thought Ian just now said you wanted to get in position I have a silly question of which is what we are doing at WordPress what tools do you use for making this slide actually I was using Prezi Prezi P-R-E-J-I because I find PowerPoint boring because based on my 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 Prezi you get dizzy looking everywhere sometimes the slide goes up so just use it just to get attention of the the crowd so at least they are when you see when things are moving so you also get the attention of the people thank you Peter here when you deployed the WordPress for Headless the front end of the course for WordPress are still there how do you do that okay okay so for that one so basically we are not really killing the teams we are staying at but the server we are deploying 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 because we are doing that kind of mechanism we take away the front end part because it's part of the WordPress installation so essentially you can so that would be beneficially 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 I'm developing his WordPress website then he hired the external mobile app developer so 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 ya I just consume it 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 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 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 and I have a question like this is mostly about MDI so is there any built-in feature for red lifting or twirling or anything like that? actually there is something like that but it's kinda too technical that's why I don't include it but do you want to use any WordPress plugin or is it built-in in WordPress? are you familiar with Transients on WordPress? you would utilize that functionality 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 not acceptable to the standards so that comes now these Transients and caching thing that WordPress has built in you can fully utilize that one okay, so developer need to go to strive these things first yep, yep any more questions? okay, three more minutes till we guess what time it is that's my video, we'll be waiting for this so it's tea time now, we're ready to go bye bye to the next channel, bye