 I'm Scott Taylor, as she said. I think she covered most of this stuff. I'm Wonder Boy Music on pretty much every social music platform. The story behind that, I always tell it, because people don't know. It was a fake booking agency for my band. So I would always send mail as Wonder Boy Music. Anyways, I live in New York, and I've been working at the New York Times, I guess, for two and a half years now. Before that, I met a lot of you for the first time at WordCamp San Francisco in 2011. I was at a company called Emusic then. I was there for about five and a half years. Yeah, so WordPress at the New York Times now has some legacy blogs. We used to be a much bigger blogging ecosystem there. And I'll go into some of the history of where WordPress has come from in going to the New York Times. But we have some legacy blogs. Lens is our photography blog. It's a WordPress property. First draft is the Washington Bureau's daily live stream. And it's a newsletter that comes in your email every day. We use it for some internal corporate sites that aren't very cool. NYT Co., which is the sort of brand site, Women in the World. Or women, yeah, so it should be Women in the World. That's not correct. But it's a conference site. Tina Brown has this conferences program that highlights women. That's a joint partnership with the New York Times. Times Journeys, which if anybody knows Eric Lewis, he was a contractor for us before we started working at the Times. And he built out Times Journeys, which is kind of like this travel cruise website, New York Times branded thing. Check it out if you have some time. And then we do something called the live coverage platform, which is the reason we're sitting here today. And in the future, I'd say within a couple months, we're going to start launching some international-based projects that are going to use WordPress as the platform. A lot of people ask, how does the New York Times do WordPress? And this is literally, right now, the main goalpost for that. But the live coverage platform is what I want to kind of talk about. As was mentioned, I've been leading WordPress 4.4. I know a lot of you keep track of that, so I'm not even going to spend a lot of time talking about this. But these are some of the banner features that are happening in WordPress 4.4. REST API is half-in. It's the infrastructure where you can create your own endpoints. And that was the part that actually interested me the most, and the way I use it at the New York Times is mostly registering custom endpoints. So that's fine by me. But a lot of people make client apps. And those are slated for a future release. It's not safe to say 4.5 yet, but 4.5, 4.6, 4.7, who knows. Responsive images are pretty cool if you've never heard of them. WordPress is no embed provider, and then tons of under-the-hood stuff. So in the coming days, you'll see lots of press about WordPress 4.4. So I'm not going to use the time now to talk about that. I think it'll get addressed tomorrow in the state of the word. But yeah. So when I came to the New York Times, my job was to be on the blogs team. The New York Times has about 400 people in technology. And the blogs team was just one of several teams that works on making parts of the New York Times. The New York Times used WordPress very early. They were also an early investor and automatic. And they were one of the first users of multi-site, I think in a highly visible way. At the height of blog mania at the Times, which I'd say was nine or 10 years ago, to where WordPress was really this modern spaceship of a technology that allowed people to move fast and launch new properties quickly. There was about 80 blogs that were active. And many of the blogs, even as far back as 2008, used live blogging. So when I arrived, the blog's code base was a completely separate code base from the rest of the New York Times. A lot of the New York Times actually is built on PHP. But it's in the camp of no framework at all. Or the frameworks they do use would be proprietary. And it was kind of a strange environment we were in. Because the blogs still looked a lot like the New York Times. But they weren't in the same code base. So the way that happened was sharing a lot of CSS and JavaScript. And so the blogs would kind of import this global CSS. And then there'd be this blog's global CSS. And then there'd be specific blog CSS. And the fun part was that it wasn't all in the same place. It was actually across seven different SVN repos. So you were kind of working in this keyhole blog environment. But you were very affected by the rest of the New York Times styles and code base. It was also a universe that assumed in perpetuity that jQuery and prototype would live on in harmony forever. And when I first saw the code base, I think this is how I decided to phrase it, challenging amounts of what could generously be called technical debt. It was a strange history of the World Wide Web. So a simple way to say this, this is a simple example of the kind of stuff you would see in the markup of these pages. But there's prototype up there. We have a friend, jQuery. And then somewhere within the markup, we're going to have something that does jQuery and something that does prototype. What could possibly go wrong here? I mean, not much, right? Well, a lot of things. So there were some less than good practices that were happening. There was inline HTML in 2008 that was being saved in the post content. And that becomes a bad thing when prototype goes out of style and you have prototype inline code in your posts. There were widgets in inline code that would add their own version of jQuery or prototype, which was helpful. And then you would actually sometimes receive code from another team. WordPress is very extensible with stuff like widget areas. And so the interactive news team might give us a newsletter widget that we would put into our sidebar that would have its own version of jQuery. So at times, you would have stuff like this. You'd have whatever the top one was. And who knows what version was actually out at this point, but we were locked into 162 for religious reasons, I guess. And we have 171. There's this video code that, believe it or not, has jQuery and prototype in it as well, which is pretty cool. And then at the bottom, we have this namespace jQuery. I actually don't know where the namespace happened. But I know you had to use that. And that was one that meant it was the right one. So the problem here from a conceptual standpoint, I almost not even worrying about the details, is that we have two projects, and we have no shared modules. So the New York Times is a website that's going to have a header and a footer. And the blogs is going to have a header and a footer. Ideally, there'd be some scenario where it was the same header and footer. But typically, it was not. That stuff can get out of sync immediately. So if you have a separate project that's going to change their code, unless you're constantly looking at their GitHub repo, or sorry, SVN repo, you're not going to have much fun. And like I said, the CSS and JavaScript was split across, I think, like seven different repos. So to even run the whole website locally, I had to create this simlink factory that was like 17 simlinks of Troncon. It was pretty weird. Another challenge the New York Times was that we don't use WordPress comments. And the New York Times is a very heavily commented site. There's an entire team called CRNR that handles that. We also don't use WordPress media, which is ironic because I spent a lot of time on WordPress media. And we use none of that. And there's a whole different CMS of the Times called Scoop, and the media lives there. We don't use WordPress native post-locking. And when I was at the Times, when I started there in 2013, we were building 3.6. 3.6 wasn't even out yet. So post-locking came out while I was there. And we've actually yet to reconcile the two different systems, which is unfortunate. But that's kind of indicative of the Times being a very early adopter of WordPress. The Times was using WordPress before there were widgets. They were using WordPress before there were short codes. So the Times started using short codes, but short codes did not exist in WordPress. So there's a lot of very creative, regular expressions throughout the code base that I've tried to retire over time. But it's very hard when you have this amount of technical debt, we have stuff we're constantly working on. We aren't stopping every day to refactor all of our code based on what WordPress is doing currently. So yeah, and there's also a layer for bylines. We don't use, the users in WordPress are not authors. They're the people who are going in and perhaps producing the content. But there's a whole LDAP system that we use to authenticate users. And the users themselves exist in a different system. OK, so it was a tough four or five months, but what was good is that the Times was already working on something called NYT5, which was the next generation version of the New York Times code base. And so my arrival there kind of coincided with this project that was already happening. So to explain visually the difference between what they used to call NYT4 and NYT5, this was NYT4. And for the universe, this is what the New York Times looked like. And then one day we had NYT5. And when you go to the New York Times now, what you're seeing is what we call NYT5, which was the redesign. And if you see the new homepage, it's the redesigned homepage. NYT5 has its own new set of challenges, which your development on the platform demands this vagrant environment. And your GitHub repo for the app actually can't run as a website until you do a bunch of transpiling with grunt. And so what happened to me is I got tasked to do what they call the NYT5 theme. And I think some people thought, oh, it's going to be the same thing. We're going to have our version of the markup. And then we'll pull in these global styles and global JS and be on our way. Well, that wasn't really going to happen because the JS and CSS are SAS and Require. And they're dynamically built based on the app and based on your vagrant or build environment. And there is no one file you can just point at and have the global styles for the New York Times. And also they started using Composer and PHP 5.5 object-oriented magic everywhere, which is fine. But we have a problem with WordPress that WordPress cannot for a variety of reasons. So Require.js was an upgrade for us regardless of any challenges it presented because it fixed the jQuery problem. Require.js allows you to specify dependency. And then through dependency injection, give you that whatever was exported in a callback. So while I don't recommend you do this, Require.js makes it safer to do this. So that wasn't necessarily a bad thing to go to Require.js. But the deal breakers were we can't just point our domain at WordPress and let WordPress figure everything out. We actually had to point at our NYT5 blogs app, pipe that to WordPress. WordPress has to figure out what the content is supposed to be and then let this NYT5 framework trickle down and do its thing. I'm not going to go too much into detail on this. I'll show you a slide that kind of explains this. But our web server is eventually going to hit. This is a drastically simplified version. But app.php is going to load some initial files, bootstrap WordPress, capture the content, and then initialize the application. And the application will have access to whatever WordPress output. This is not an ideal setup, but it allowed us to continue using WordPress in an environment where brand new modern web apps were being created. And WordPress wasn't immediately suited to work that way, but I was able to find a way for the two systems to work. And the advantage is here, we have those shared modules. Our theme itself doesn't have to produce the entire HTML document. It's one of those things where if we're already provided a best in class wrapper for our content and we can, in some form, inherit that and not branch to our logic, let's do it. And then the irony is because everything else is namespaced, we actually don't have any collisions in global scope because modern PHP apps don't use global scope. WordPress uses almost exclusively global scope. So the strange thing is that in your NYT5 app somewhere, you can use any WordPress stuff you want. Yeah, so this is how we made WordPress work in this new environment. Globals, I just want to take a pause for a second and just highlight the fact that globals are not the future of PHP. I don't know if they ever were, but globals are a thing that is pervasive across WordPress. If you aren't familiar with them, globals can be created in a variety of ways. But number one is if you have top-level code, meaning you have a PHP file and you do $ something, you have just hoisted that variable into global scope. If you directly altered the global's super-global, you've created a variable in global scope. If you have imported a global, like I have in this function, I'd have to check, but I'm pretty sure that creates a global equal to null. But all of these things are a bad way to actually handle state, but it is kind of a benchmark of WordPress. So this could be solved kind of across the board, but we have a necessity to support PHP 5.2. PHP 5.3 introduced namespaces, and namespaces are great for this very reason. But even if we do go to PHP 5.3 the next day, we aren't going to refactor WordPress to use namespaces because nothing, no code written anywhere else is in this paradigm. And namespaces, if you've never seen them, I can declare WP. And then instead of having to have WP underscore query, I can create a query class. But another namespace could also create a query class within that namespace scope. Anyways, the NYT 5 was a necessary thing to not have WordPress eradicated at the New York Times because it actually would have been way easier to just ditch our old installation of WordPress completely and go with something proprietary that didn't involve blogging at all. But I didn't want that to happen. We made the NYT 5 thing happen. But blogs overall were in a general transition and kind of rightfully so. A good example of this is blogs were duplicating section fronts. Mark Bitman was a food writer. He's actually, I don't know if he already left the Times, but he's leaving the Times. He had a column in the paper. His column exists on the web as an article. He contributes to a blog. There's a section front for dining. He also has bitman.blogs.nytimes.com. Like, why? It doesn't make total sense these things were there. And a lot of times it was just an express lane for pushing out content. And in an ideal world, all content goes through the rigor of the New York Times editorial process. The problem here was that blogs and WordPress became combined in everybody's mind. And so when they go, blogs are going away. They'd hear WordPress, and they're like, oh, well, WordPress is going away. We're not going to use WordPress, which was scary. Which is why I put the hashtag dark at the end there. But we still had a few things that were uniquely suited to WordPress. First draft is, and I've read a long blog post about this about a year ago, things we take for granted in our systems, the NYT5 system, there's an app for article, which means URL patterns that match article. There's an app for homepage. There's an app for these collections type URLs. They don't have stuff like day archives. They would have to invent day archives in their system, month archives, date query. The ways we can kind of do these sophisticated queries based on all kinds of parameters. We had to build first draft in WordPress because the other system couldn't handle it. And it sounds kind of strange because for us, day queries are an afterthought. Who cares? But you get so much of this stuff for free. We have these things in New York Times called collections. Collections are actually just terms, the taxonomy and term URLs and rewrites we get for free. They've been spending months trying to figure out how to replicate that kind of stuff in the proprietary CMS and then represent it in a front end app that has to parse these URLs. These apps that render the content are not front end and back end. They're front end only that read JSON. And they weren't started with the paradigm of having a way to query this other system for this group of content. And the content itself may not have been logically associated anyways. We have Lens, which is a photography blog I mentioned that Eric Lewis actually worked on. And then we have what we call live coverage. If you've never seen first draft, this is first draft. We expect people to come here and get their Washington News fix, perhaps leave the page open all day. And there's a backbone component that will load in new updates. This uses the REST API. But it's kind of a very primitive thing. It just pings the posts endpoint. And if there's new items, it plops it in. This is the front page of Lens. And in 2014, the midterm elections came up. And they asked me to make changes to our existing live blogging tools. And our live blogging tools were written in 2008, kind of written before. That was kind of the dawn of jQuery, if you think. So they'd stop even thinking about backbone or require or something like that. We had code that was written two or three years before custom post types. And so at the time, it actually may have been a sophisticated solution where you had custom tables and you had code that may have duplicated what post APIs may have done. But it was one of those things. Are we supposed to launch a couple hundred live blogs? And then two years later, completely rewrite them, pause, rewrite them in custom post types, support all the old live blogs, and maybe port that content over. It's a huge undertaking. So yeah, I kind of mentioned this stuff. And then we tried a different thing where instead of doing that, perhaps we'd spend a, we're using multi-site, perhaps spend a new blog up when we would do a new live blog. But that kind of sucks because the event may only be four hours long. And a blog, every time we spend a blog up, you're actually creating 10 new database tables. So for every 10 events you have, you're going to have 100 new database tables. It's kind of hairy. So the question was, what if we could use stuff like custom post types and to create a new live blog rather than creating this huge thing or creating custom tables, maybe we'll create something called an event, which is an object type because we have custom post types now. And that event itself can have updates. Another custom post type. And even if you don't want to use WordPress for the front-end, let's say somebody wants to make a Node.js app or Rails app. Because we were aware of this REST API that was being created, back then it was being called the JSON API because this was v1, this was a great use of WordPress to be a back-end that was kind of bridging a gap for systems that didn't have this capability. So we could provide REST. We could provide self-service URLs, but we didn't actually care if we were the front-end or not. So I, over the course of kind of a weekend, built this screen, which is a different admin. This is a one-page backbone app. And the reason I picked backbone is because backbone speaks REST out of the box. On top of that, even when it was called WPJson API, there was already a backbone client that knew how to model the objects that the JSON API provided. And it was actually really easy to set up the boilerplate code to have some fields, save them to an endpoint, get the posts back in an editable form, et cetera. And then on the right over here, we're reading the stream of posts, and I have that using heartbeat as well to update when I ping it maybe every five or seven seconds. And it pulls in the new posts in whatever state they're in. Maybe they're in draft, or maybe they're in publish, and there's post locking. But it became very easy once I was using tools that spoke REST to each other to put this stuff together. So let's go over here. So yeah, what we did is we created a thing called Live Events. If you ever go to the newyorktimes.com slash live something, it's WordPress. It was a brand new admin interface. We used custom REST endpoints to handle processes. And WordPress serves the front end. I have a slide coming up that breaks it down a little bit. But we actually have a web socket on the front end too that once we're doing an event, it has a web socket listener, and we'll actually use React to put in posts. React is a big buzzword these days. And it's great for things like live blogging. I'm not so sure it's great for traditional blogging, because if you create a post about Apple Pie, that post isn't really going to update perhaps ever. But a live blog is by nature going to update all time, which is why React's a good thing to use. This kind of took off like gangbusters and is now the de facto platform for breaking news of the New York Times. Also for covering stuff like events that lend themselves to live blogging, like the Grammys here, great posts at the top. And then we also made it responsive. The website itself, the New York Times, is not responsive down to small screen sizes. But we made this responsive so that a lot of New York Times posts, when you hit them, if they can tell you're on a phone, actually go to a mobile website. If you're on your mobile phone and you're watching live coverage, you're watching it responsive on WordPress the whole time. So we also have something else we need to do when we have live events is we have to put modules on things like article pages. And the article page is, this is in our other CMS. We point it at one of our JSON feeds. And this will also live update. Anyways, because we did start doing this WordPress stuff that was less blogs related and more agnostic to technology, we joined the interactive news team beginning of this year. We have more freedom down there, and it turns out we want to use Docker instead of Vagrant. PSR0, which is being used by MIT5, is now obsolete because PSR4 exists. We're using Gulp for a lot of things instead of Grunt. Require.js is just fine, but we actually prefer to use browserify. PHP is cool, but why can't we use stuff like Node and React occasionally? So yeah, this team is very independent. You can use whatever language you want, and you don't have to use MIT5 for a lot of these projects. So live coverage platform, any URL in the Times that does this, nytimes.com live event. Request is served by WordPress with PHP markup, React wraps the post area, WebSocket. Updates can be added by WordPress, or they can actually be added by a client that was written by somebody else on our team in Slack. We actually have a workflow where reporters for an entire event may be in Slack, and the mod Slack extension we built allows WordPress posts or these Slack posts to be pushed into something called Invisible City, which is a service we created that uses Redis and Pusher, and that's actually what interacts with our WebSocket. And so whenever we get updates, React can update that content. So Elections Code became good for breaking news. So yeah, for WordPress and REST, we're not doing any rocket science. We're registering routes, and then we are handling the routes. A few things I want to mention that will be got ideas for this plugin developers in general is most plugins in the WordPress ecosystem. If you make a custom menu page and you want to handle a forms mission or something, almost everything just looks at post. And so it'll say, oh, if it's not a post, I must be a get request, just return or something. REST is going to speak all kinds of HTTP verbs, and so you may get delete and post and put requests. So those need to be handled as well. So if you were doing post. Not equal to server method, now you want to do if it's get return, so that you can actually receive any other kind of request. When using the REST API, WordPress becomes basically a REST service. And the WordPress code base is not, I'd say, the greatest thing to use as a web service platform. And that's something we're going to be working on as we look at adding endpoints to WordPress. But something you need to be aware of. Also with HTTP, you don't want to make a lot of those requests serially to the REST API. You have to look at concurrency using tools like Guzzle to do multi-HTDP. Another thing we're going to look at in 4.5 with Ryan McHugh and Dion is looking at overhauling our WP HTTP internals to support multi-requests. And one thing to know about the New York Times, some secrets I'll tell you, we do not hit the REST API on the home page of the New York Times. If we have a module on publish, we actually take the JSON response and throw it into Akamai, and we ping those Akamai URLs. This isn't always necessary, but for breaking news in the New York Times, it's been necessary for us every time. And finally, HTTP in general is time consuming. So you're going to want to build these admin interfaces that do things like safe posts, but then you're going to have plugins that are actually hooking into safe posts a bunch of times. Safe posts may actually make HTTP calls. This is pretty bad, because it can actually really slow down the number one, your page load in the admin. But your REST responses will feel real slow. We started using a technique called Fire and Forget, where we pass only the context we need to a remote request. And then we kind of make it asynchronously. We don't care if we get the response or not, because we want to let another endpoint handle this logic. I don't have enough time to go too deep into this. Anybody can grab me on the side and talk to me about it. But this is a big part of our custom end points in our admin. And I'm going to post all these slides. I think I'm basically out of time. But I think we have time for a few questions. Five minutes? Yeah, cool. So we have five minutes for questions. I guess that's the end of my talk. But if anybody has any questions about anything, let me know. That's also the first time I've ever made it through all my slides. I'm usually clicking like this. Just a quick, easy one. How does the REST API and the live blogging affect your analytics? Because I know that's going to be a question I'm asked if I pitch this. OK, you know what? Great question. You know what it affects more is the thing we had to spend the most time on was SEO type stuff, especially with dynamic sites like that. We do have URLs and linking that you can deep link to stuff. And even though live updates are dynamic, you can deep link to them. But for SEO, we actually had to start using Amazon SQS and do our SNS. And we created an SNS topic that we post to. So when we, and this ties into the fire and forget stuff I was talking about, when we save an update or an event, we actually send an event to an SNS queue that our search team listens to. And when they receive that message, they actually dynamically update stuff like site maps and stuff. And so when these live events are going on, we have an audience development team who's staring at Google and Google News and making sure that the second we do an update, it's very quickly at the top of Google, like we're thinking about that stuff constantly. And stuff like Google Rich Snippets and what's the mobile initiative, AMP, is the, yeah, we've already started working on that kind of stuff. Yeah, you have to be cognizant of, we're definitely cognizant of that kind of stuff. And we also do have tons of custom Google Analytics stuff firing for various things. Thanks. Anybody else? All right, thank you.