 did you manage to get coffee, yeah? Excellent, yeah. All right, so then we can get started and yeah, talk about the REST API because it's been raising a lot of noise in the past months, even a year, but as non-developer, I've always been a little bit, you know, very curious, like Frantz had, but very insecure about it because all the talk about the REST API includes a lot of code, a lot of words that I don't know, so what I decided to do is just dig into it, like get out of my comfort zone because it's gonna be important to know about it. So quickly about me, I'm a PM and event organizer at HumanMade. I also do a lot of contributor work for WordPress. I work with the polyglots who translate WordPress to a lot of languages and I organize WordCampure, which if you got a ticket to, that's amazing and if you don't, sorry, it's sold out. So HumanMade is an enterprise WordPress agency that does very big projects, including using the REST API. These are some of our clients and this year, for the first time, we also organized a conference that is dedicated solely to the REST API and teaching developers how to work with it, how to extend WordPress using it and we're also preparing a week-long workshop for developers as well called the Week of REST which will come later in 2016. A little bit of my backstory because this is important for you to get why I'm talking to you about this. I came to web development from communication, from marketing and PR and in 2009, somebody took me under their wing. I was like a control freaky, a little bit nervous and very hard with receiving feedback, marketing, brand manager and they actually decided that my enthusiasm and curiosity and like my drive were more important than that and taught me a lot about working with web developers and working with designers. That was for a big publisher back in Bulgaria where I was part of a web development department which transitioned traditional media like newspapers into the web and it was very challenging for me as a communication person because I had no idea about code, about the ways that developers brought websites to life. So my job consisted of telling developers what to do and how things should look without me even realizing how they will actually do that. That all changed with WordPress. WordPress changed all that for me. In 2011 we left the company with a couple of colleagues formed our own agency and I discovered that I can actually do a lot of the things that I thought I needed developers for myself. So that was so awesome. I didn't need developers to change menus. I mean with WordPress core a theme and like a few lessons in CSS and HTML I could actually do reasonably looking, nice websites all by myself. That made me feel really great. And I thought that anything was possible with WordPress until I found out that that's not really the case. So 25% of the web that's a huge number for WordPress to be powering so much. Projects online and it's actually powering everything from blogging platforms to huge media sites with like millions of visitors every day, right? And that gets you thinking at some point because like we're all grownups one platform fits all is like that's not really that's not really possible. And can there be something that powers a cooking blog and like the complicated, multi-layered, 100 journalists built, like you know, powered build of the sun that has millions of millions of users every day. So in this talk we're going to see how the WordPress REST API will actually help WordPress get out of its comfort zone like much like I'm doing right now. And how the WordPress REST API will help WordPress grow bigger and how it's the next milestone and what are the challenges and the opportunities and what are some of the difficulties and what will change for all of us, not just developers. Cool. So WordPress has grown over the past decade a lot and the way people perceive and use it has changed. And it started as a blogging platform as we all know and then in 3.0 it started transforming into CMS custom post types were introduced. In 3.8 the whole redesign of the admin and the new media manager and everything. So it started being appealing to big publishers who loved the UI for their editorial teams, right? And then the ecosystem around WordPress started growing as well. And there were services and SaaS products appearing to kind of compensate some of WordPress's flaws like speeds, speed optimization and security, SEO. And at some point people started using it as an application framework. This is a slide from the 2014 State of the Word where for the first time we see kind of a growth in the usage of WordPress as an application framework and like the decline of how people use it as a blogging platform. So WordPress 4.4 introduced infrastructure for the REST API with the endpoints being planned to go with the 4.7 release. And the REST API is the next phase and will allow WordPress to be considered as a key element in a bigger, larger technology stack. How is it going to do that? It's going to do that by providing a clear path for added technologies to the content created in WordPress. Why is this important? Why is this such an important milestone for WordPress? Can it grow indefinitely the way it is right now? The answer is no, and this is important because if we think about WordPress as a real creature, like a real living, breeding creature, we need to admit it's got a lot of responsibilities, right? It's very friendly, so it has like millions of friends, it needs to pay attention to all the time, it needs to be nice to everyone, it needs to be modern hype, and it tries to fit with the other cool kids, you know? It needs to be really badass and powerful and strong and sophisticated. Also needs to be very easy going to like people it needs for the first time, you know? That one to just say hello, try it out and then go. It's got a lot of responsibilities and it's not very good with delegating as well. If it considers something it's core kind of responsibility, it like sticks to it and tries to deliver everything. And it hosts huge parties for a lot of people every day and tries to do everything alone. So for example, it's expected to be able to feed everyone and prepare hundreds of thousands of pieces of food and different styles of food for its international friends as well. It also needs to deliver the food and very fast. Otherwise, you know, people will just go eat somewhere else. You know, it has to be very, very solid to the back end and like provide all the technical equipment for the party, everything itself. It has to make sure there are no unwanted guests in the party, right? It has to look gorgeous in the meantime, you know, being very flashy and everything for very modern private guests. And even though these days it has a PhD, some people still want to talk to it as if it's in kindergarten, right? It's like, hmm. So if what first was a creature, like a living, breathing creature, probably be super burned out, you gotta admit. Stretch and like the verge of breaking down with the expectations towards it and because it's trying to execute everything itself. All right, coffee. I mean, I got tired looking at this. I don't know about you guys. It's just, I feel for it. Cause like it's something of a similar to how I cannot delegate and I am a little bit of a control freak as well. So WordPress right now is not very far from like, gifted, kind of experienced, knowledgeable control freak that feel they need to do absolutely everything because they think that they know the best way to do it. And even though somewhere you're deep, deep down, you realize that there are probably others that are more skilled at some of the things that you're trying to do yourself. And if you let them in, you'll deliver better results for the guests at your party. So the REST API is for WordPress. That's like strike of genius that comes to a control freak at the moment, the verge of breaking down that actually finally allows them to let go and learn to delegate. So the REST API will help WordPress learn to delegate. With the help of the REST API, WordPress will be able to focus on what it does best, provide an incredible UI for authors and editors, be strong at the back end while allowing all the cool kids to do the work at the front and be very, very friendly to users. One of the biggest strengths of WordPress is how easy to grasp comprehensive at the back end is for publishers. That's why publishers love it. That's why big media likes WordPress as well. Authors and editors love publishing with WordPress. They love the visual editor. They like the distraction free mode. They like the formatting tools. The what you see is what you get editor. There are very, like a lot of small gems in the WordPress visual editor that authors just love. It's like a writer. I really love the WordPress backend. WordPress is great for that. So what the REST API will do is it will allow developers to start using WordPress for just that while decoupling the front end and the back end. A traditional CMS like WordPress is, it deals with data collection, delivery and display. So WordPress has a backend and a database and PHP deals with delivery and the theme deals with displaying the content on the front end, right? So a headless CMS is something that doesn't deal with the front end at all. It's, you know, the data storage method in the backend for authors and editors remains while the data is delivered to the front end using the REST API and the technology of the developer's choice. And one of the things that this will do is it will allow developers to build projects that can power multiple front ends. Like using the REST API developers can get the content from one WordPress install and deliver it to many different applications. So the other thing that it will do is it will allow WordPress to be a part of a bigger technology stack. This is a diagram from the REST API White Paper, my good friend, Siobhan, wrote with Tom and Joe from HumanMate and it shows how WordPress can be used as just one module in a bigger technology stack used for something a lot more complicated than we're used to. That's all great diagrams and things, but let's see some examples, some real-life uses. This is Nomad Base, which is a service for digital Nomad workers that allow them aggregating geodata to track their trips in different places all over the world and to also connect with other Nomads. So Nomad Base uses WordPress as a platform and for the API and as a kind of database storage unit and it uses a React app to display the content and Leaflet, which is another, it's like a map technology to generate the map, but the data is sent over the REST API to a React front-end and displayed in the browser. It's a browser app and the next phase for Nomad Base is going to be a React iOS app, which will use the same content as the browser app and will be available on mobile phones and it's one of the use cases that I really like and when Joe and I built Nomad Base, they decided to go with WordPress because it allowed them to build the site immediately. It's like very, very quickly, they have a lot of WordPress knowledge, so that was easy for them to use WordPress as a central of the infrastructure. Another really cool base and this is like a classic example of the use of the REST API and WordPress as a headless CMS. Us too, our digital studio is like creators of Monument Valley, do you guys know Monument Valley? It's a pretty cool game, right? So us too wanted WordPress for its very usable back-ends and they wanted the platform that was stable that were there to stay and they decided to go with WordPress and build their own single-page app on the front. So they used React as well and Node.js for some of the server stuff that I don't really understand, so I don't see why I should explain to you, but the result is a brilliant, really nice visual on the front and they used WordPress to actually publish content. This is what they did, React front-end, Node.js, server that enables server, site rendering, whatever. Yeah, that means, I'm so sorry. Yeah, but it's a cool website, right? And it's WordPress. The New York Times uses WordPress for a lot of their blogs and like several of them actually also use the REST API. The New York Times uses the REST API and WordPress to power their life coverage platform. So they combine technologies, using the REST API and WordPress, they combine technologies to provide journalists with a custom back-end to enter live data during a live event and have developed their own solution for saving the updates real-time so that the screens don't refresh every time and they can actually use it very quickly and despite shaking internet connection and things like that. So journalists sent updates via the WordPress back-end and also via Slack, apparently. The New York Times digital team is just awesome. And front-end technologies ensure that the updates go up real-time, fast for the end user and easy for journalists to monitor as well, right? Wired is another example of a company that utilizes WordPress and the REST API. They have a live blog which uses data delivered from WordPress via React.js front-end and then text and images are rapidly posed via a third-party mobile platform bold and safe to WordPress post-meta and then made available using a custom WordPress REST API endpoint. So it's pretty cool watching this live blog like just automatically refresh without refreshing the browser. It's just you see all the new updates immediately after they happen. So that said, let's sum up, quickly sum up the opportunities the API provides before going into serious conversation. So developers are no longer limited by technology to create the projects their client needs. They can create context-specific solutions and bespoke solutions for their clients, extending current WordPress functionality without worrying about the flaws of the WordPress platform. The content can be used for movable purposes, right? You have reusable portable content and you can power apps, mobile apps, websites, parts of websites. You can use the data and send it to be used wherever you want. The separation of concerns allow developers to focus on the back-end and extending that back-end to deliver greatest results and then it allows front-end developers to focus on delivering the best display of the content. Authors and editors keep the interface that they love and they can use it, you know, they know it, they can use it successfully to publish content. And then WordPress becomes a part of a bigger technology stack and can be used as just a part of a large, large build. But does any growth, it doesn't come without pains, you know, growth pains. So what are some of the challenges that we are facing right now? The biggest one is the loss of core functionality. And what this means is that with separating the front-end from the back-end, we lose, like especially side builders, we lose the ability to control the front-end. Everything that we're so keen on doing, everything in the appearance section, basically, customizing the front-end, all that, it kind of gets lost on the back-end. And it needs to be custom-built into a kind of REST team, JavaScript or React team or whatever technology developers are using to allow authors and people from the back-end to actually control the front-end. So that disempowers the WordPress side builders. One of which, you know, is me and I'm not really happy about that, because, you know, control freak. And also, I will tell you in a second why. We kind of, I kind of found that out the hard way. The feelingrestful.com website is the website of our conference, Dave REST, that we had to build last year at the end of 2015, actually, to promote the event that was held in January. So, me and my colleagues, you know, Siobhan is over there, he's one of the organizers at the back. So, like Siobhan and I, we're like the do-it-yourself kind. We're used to building WordPress sites using, you know, all the things that the ecosystem offers. So when the time came to organize Dave REST, which was our responsibility, we had to decide how to, you know, structure the website, how to create a site. So at that time, the development team at HumanMade was super busy. I mean, they're always busy, but we kind of had failed to allocate resources for development. So the straightforward thing to do was like, just grab a theme, you know, install WordPress. And like, we just needed a couple of post types. We just needed like, we didn't need something very complicated. We could do it, both of us. So we did it. We created the first website using a premium theme, especially curated for events. So it had all the necessary post types, you know, we tweaked the CSS a little bit so that it can fit the brand colors. We did everything that, you know, every WordPress site builder does, you know. And we did it in like two days, three days. It was up. It was running. We could announce it. We could like, you know, keep doing our thing. But it wasn't ideal. And you know, it had its downfalls. We received some, you know, mocking feedback on Twitter and they were right. Why would the website of a conference dealing with the REST API build a theme that doesn't use, you know, a site that doesn't use the REST API? We're absolutely right. So Joe rebuilt it, rebuilt the team. Like we got rid of the premium team and Joe rebuilt the website using the REST API and a React-powered theme designed by Noel. And he also like open sourced the codes and created that cute little widget at the bottom that like, for every page, it shows you the REST API requests. Some people thought that like, you know, the site was broken in the beginning but actually developers loved it. Developers really, really loved it. Brilliant, right? And then Joe posted to explain why we rebuilt the site. And how we're open sourcing it, how everybody can learn from it. And also he posted about what's missing from the current team. And that's when Siobhan and I realized that we had lost a huge part of the control over the website. So overnight, we ended up unable to preview posts so we had to like send links to the back end to each other when we wanted to, we couldn't see how a post would actually look at the front end because the visual editor didn't reflect what was in the front end. We didn't manipulate menus anymore. We didn't, we couldn't add a link to the menu. That was like, ugh. And we waited days for developers to kind of do small things like as small as adding a link to a page that we didn't have access to. That was like custom built. So I need to mention how the control freaking in me felt at that point. It was like somebody tied both my hands behind my back. So for years I've been able to figure, with WordPress you figure something out. You always figure something out. You can think like you get a plugin, you do a little CSS tweaks, you know, you even like God forbid go into the editor and like modify the code. But this time I couldn't do nothing. I could do absolutely nothing to get a link in a menu. Siobhan was a little bit more blunt. So in a WordPress company consisted of 90% developers, nobody had really figured that they needed to communicate to us that there would be something that we would be losing when we build a REST API powered theme, right? So going back to that particular challenge, this is one of the things that I'd like you to take away from this talk. Be sure when you're dealing with projects that include the REST API in any case, even if no matter if you're a developer or non developer be sure to prepare the other part of what they should expect. Setting expectations is really important. Don't let clients believe that just because it's WordPress it's going to have all the core features. If it's the REST API some of the endpoints are not. Most yet some are not going to be merged for a longer time. So be aware of the decoupling of the front end and back end. Otherwise you end up being angry, you know, with your developers and that yourself and like for a good reason. So one of the next challenges that the REST API serves is that necessity for like structured portable data. That means that the data, literally it means that the data that you enter in the back end needs to be clean of HTML, CSS and all that. So that can be transferred to multiple devices. So this is one of the things that is going to change where we'll no longer be able with the REST API powered themes. We'll no longer be able to use the what you see is what you get editor for building layouts in the back end. Short codes, columns here, columns there. The data needs to be clearing. So your content needs to be on your website but you may want to use it later in a native app. That's why when created the content needs to be completely front end agnostic. What are we on? All right, I already said that. Next, progressive enhancement. My very good friends REST, how many of you know REST from Twitter at least? Yeah, he's very grumpy. He's very, very grumpy. And when we build the REST API and the feeling REST will sign, he wrote a huge post just saying how that website just didn't work if JavaScript was not enabled in the browser. And even though our circumstances were a little different, you know, we build a website very quickly, we didn't have time. He's right, we cannot ignore progressive enhancements if we want to keep the web accessible. And one of the main things for developers as a challenge with the REST API is going to be just this, finding a way to ensure that the website is available even if browsers have JavaScript disabled. This is as much of a challenge as it's an opportunity because the knowledge deficits of the WordPress development community in terms of JavaScript and like the modern technologies, front-end technologies also mean that they can concentrate on the back end. They can be stronger there or they can move on to, if they want to control both front and the back end, they can move on and like start learning, which is always good. So what will change? WordPress becomes a part of a larger stack. The new approach to project management is going to like developers are going to independently focus on different aspects of the website or application, working with the data retrieved using the API. And separation of concerns, we already went through that. And finally, WordPress will probably start being adopted by the larger technology communities. It will go outside of the PHP communities, which is a good thing because we're hearing a lot of hating of WordPress, right? And we don't want that because we know how much effort is put into creating that software just the way it is. The back ends are going to be a little flashier. So the rest API will allow developers to create funneled administration experience just for the client's needs. Like this HEP tables, which is a human-made product for building restaurant websites has a completely custom administration. And the rest API will make it easier for developers to enhance functionality in the admin as well. They can create client side features that are more advanced and more performant that can be achieved right now with PHP. Well, we'll not change. We'll still have themes. They're not going anywhere. A huge part of the WordPress ecosystem consists of side builders. So those guys will need things to keep going. Theme shops are here to stay. WordPress will still be used for blogging. That's not going to change. Small size and size that we can create ourselves. Backwards compatibility will not suffer. WordPress's mission will remain democratizing publishing. And quickly, some important questions that you might be asking yourself right about now. Is the rest API getting merged into Core? It will be merged into Core, but it still needs to be worked on. And you can follow the Core channel to keep up with the developments there. It's very interesting. It's also a little dramatic. It's perfect. It's very entertaining. So how do you use it in production if it's not merged in Core? It's available as a plugin. And it has its own theme. The theme is amazing and they have no, you know, no intention of abandoning the project. Is it safe to use in production? It is. We already saw that large media like New York Times and Wired use it. We use it human-made. It's perfectly safe to sell to clients, products using the rest API. A lot of outside of the WordPress ecosystem companies are looking into it as well. Will I be able to use the rest API? Well, I won't be, you know? But that's a good thing because I can go back to being a project manager and I can go back to actually thinking deeply about things instead of executing smaller tasks and knowing about the WordPress rest API will actually help me figure out how to communicate with developers better, which is a little bit like the answer to this question. Why do I need to know about it if, you know, I'm not gonna be able to use it? Because it's the future of WordPress. It's the next important milestone and if you want to do kick-ass work with WordPress, you have to know about it. What are endpoints? Sorry. This is as far as I go. But here are some resources you can use. This is the amazing, very comprehensive WordPress rest API white paper that I totally ripped off for this talk. That was created by Tom Wilmot and Joe Hoyle. Joe is on the rest API team and created by Siobhan. It's a really good source. Just read it. It's about 30 something pages, has a lot of diagrams. It's very nicely comprehensively written. This is the official rest API website and you can download the plugin from there and you can read about it. You can read the changelog. The rest API team is amazing at documentation. They're really good and very, very responsible in that way. This is the core rest API channel. Remember the drama? It's like, yes, it's there. Or you can follow around McEwen Twitter. He's one of the co-leads of the rest API project and he's very, very funny. And if you have a question, ask him. He'll be happy to answer. So, thank you. And just before we finish, I want to say a huge thank you to Scott who's over there who created the amazing Panic Twapu. Can we just please give him a round of applause? I don't suppose you have any more questions, right? I mean, I kind of, I don't know. We might have some minutes for a couple of questions, so. One there. If you're going to be able to create your own backend on WP Admin with the rest API, what implications is that going to have for accessibility? That's a good question. I don't know. I honestly don't, but I know accessibility is one of the big challenges for the rest API. So, when something is in development, there are topics constantly coming in that need to be covered. I know that the rest API team is very open to working with the WordPress accessibility. So, I'm pretty sure that they will be able to figure something out. Any other questions? Right, Jan? I'm looking at you. Anyone else? All right, thanks for the great talk. I wanted to ask, what do you think are the challenges? Because this is, I think, a theme that will emerge more and more and a couple of slides actually touched upon these points. What are the challenges that using a rest API and will bring into SEO optimizations? Because, of course, if it's going to be an AJAX request... Yeah. Google is going to... It's going to be challenging for SEO. There's the challenge, you know. I know there are ways to actually present the text to the search engines. This actually opens up one of the other themes that it seems like at least in the next couple of years, the rest API will be used for a little bit bigger projects, like projects with bigger budgets that can actually afford to have development time allocated for dealing with things like accessibility and things that are the downfall kind of. And SEO is going to be one of those. I know that the rest API kind of mentions a way to deal with introducing the text to the browser. I cannot repeat it, because it uses language that I don't understand. What I got from that was that it will just need more development work. It will also need expertise that is not necessarily generally available to the WordPress development community. So it will need developers to learn about it more and to put more time into creating a solution for it. I can look it up for you and show you the solution, that one of the possible solutions that the white paper actually mentions. I can't repeat it myself. I need to be a photographer for that. Last question. Oh, there we go. Hi, very interesting and thank you very much. I might have missed this, but when can we expect the end points for controlling the menu? So, for controlling the core end points, don't, like unfortunately, don't include controlling the menus. But this is the discussion around merging the rest API into core. How much of the admin functionality that needs to be available for users for the rest API to actually be merged? And I'm not entirely sure what the current state of the decisions are, but I know that they are postponing merging the end points right now to work on that, to work on adding as much of the admin functionality into the plugin before they merge it into core. So currently 4.7 is the data allocated. I'm not entirely sure. I need to check if the, like dealing with the menu includes that. Siobhan, do you know that? Yeah, they're gaining, like they're kind of trying to get more contributors into the team and more people like, as any open source technology it requires somebody to spend consistent amount of time working on this. And this is a complicated project. It requires a certain level of expertise, different kind of set of technologies than we possess right now. So it requires people to spend a lot of time testing and developing those end points. 4.7 is for the core ones right now. And hopefully there's a, like we said, there's a team working on menus. So just follow the blog on the make with results or slash core and it's going to give you some answers as time progresses. Is there a question over there? Yes. Thank you for the talk. I'm just wondering if you do a lot of work building something that uses the plugin when in the future things get merged into the core? Does that mean you have to restart all over again? I don't, I don't really think so. No? Dennis? No? Let's get developers to actually answer the questions better. Yeah. You should be, you should be okay. Right. Okay. Well, thank you everyone. Thank you. Bye-bye.