 Awesome. So 18 months ago, Newscorp Australia started its journey over to WordPress. Both one here and myself were on that software engineering team as part of that migration project. So we had often heard at the start of this project that some people were saying, WordPress doesn't scale. Well, our talk today is to prove them wrong and to demonstrate that WordPress provides a really good base. It's a really solid platform. And if you implement the correct technical solutions to extend WordPress, it can scale really well for large and high-volume traffic websites like ours. OK, so historically, people might have interpreted Newscorp Australia to be a little bit like this. We're over 90 years old and potentially focusing a lot on our newspaper side of the business. But over the last 18 months, a few of the people that you can see, plus a lot more in Newscorp, migrated 19 of Australia's largest sites, like News.com.au, The Australian and Fox Sports, over to WordPress VIP. We've imported nearly 3 million posts into our WordPress sites, and we're getting around 16 million visitors a day to our WordPress sites. So why did we move to WordPress VIP? First of all, what is WordPress VIP? WordPress VIP is a hosting option for WordPress sites that it's powered by WordPress.com. This is for enterprise level. We needed to escape our old CMS, which was unscalable and very, very expensive. And WordPress was chosen because it's a very reliable tool. And most of our journalists already are familiar with this tool, making training and upskilling easier. We just have to find a way to scale WordPress to meet our business needs. Lastly, and possibly the best part of it, with WordPress VIP, we don't have to worry about this. WordPress.com manages our infrastructure. So updates to the core just get directly deployed over there. So we don't have to worry about updating core or server patches or things like that. We just worry about developing new features and having our customers happy. At a high level, we have developed 45 custom WordPress plugins along with 22 WordPress themes. Apart from that and our infrastructure, our production infrastructure, we run 58 AWS non-production environments. It's a combination of EC2, RDS, and SQS, in which we try to mimic as much as possible the WordPress environment, the WordPress.com environment. From a deployment point of view, we run around 25 deployments to production each week through our CD and CI platform. And we love our unit tests. We have around 5,000 unit tests to date. So our journey started on November 2014. And when we look back at those 18 months, there are five key factors that causes grief. We wish we had known this before we started the project, however, encountering these challenges and discovering their solutions were part of our journey. And a great team-building exercise. I'm not going to lie, it was a very, very tough journey. We wanted to share this story for two main reasons. First, to demonstrate that WordPress can scale for the enterprise. And secondly, to share the challenges that we faced and the solutions that we implemented. So we're going to come in on five key areas that we noticed are the more important. And it was site build, front end, content, content ingestion, authoring, how we create new stories in there, how we manage our continuous integration and continuous development. Here we're going to talk about the challenges and how we find a solution for all of them. So the first talking point, site build, we really needed the most simplistic way for our WordPress admins to manage and organize the content on our sites. So Customizer was a great start to this. It provides a really, really good base, but we just needed to extend it and add a bit more functionality into that, which is what we're going to take you through. So working really closely with the XWP team, who I can see a lot of at the front here, we added a lot of functionality into Customizer, a fair bit of which has been moved into WordPress Core already. And this is a short little video just demonstrating how just a few of the key features that have been added in or maybe already now exist in WordPress Core. So all of our, once it buffers all of our sites and utilizes multiple content areas, which is pretty standard stuff, and within each of our content areas, we have this concept of default widgets or global widgets which will render out every single page. So we're currently on the business page and we're just looking at the right hand rail and it's just a list of stories. And if we move across to the news section in the navigation, you'll notice now that the widgets we just saw are actually the same widgets being rendered. So we can spin up a lot more pages that have a very similar structure very quickly. And then to extend that, there's a plug-in which we developed which allows you to override the widgets on a specific page. So we're on the home page now and by checking that localize to the current page, it allows you to add a completely set of new widgets for that specific content area just for that page. So you can have a very different look and feel for your home page or for any other page. After that, the next challenge, actually, we store this in, we call these things overrides, sorry, contextual settings, and they're stored in this JSON data structure in a custom post of in WordPress. The next thing you're going to see here is our home page. And that's the next big challenge we had. We have a lot of widgets that keep scrolling and scrolling. And maybe it's a little bit too much content and that's what caused us a few challenges. So by default, WordPress, as I'm sure a few of us know, stores all of the widget data inside bars which is then stored in WordPress options. Because we had a huge, huge home page, it meant that the amount of data we were storing in WordPress options was more than a megabyte. And we leveraged, because we're on WordPress VIP, we leveraged memcache quite extensively for performance and one megabyte, unfortunately, is that limit for memcache. So as soon as any key has more than a megabyte of data, it's no longer getting cached. So this meant that for every single page request, we were no longer caching WordPress options, which was huge performance issue for us. So another plugin was developed and we call this widget plus. Essentially, it's a new custom post type and it stores all the widget data now in its own custom post type in WordPress. So this means that we can store everything relevant to just a single widget in isolation and cache it in isolation. We don't need to worry about caching everything as part of WordPress options. Within our previous CMS, it took us hours, sometimes a day to create a relatively simple page. Within WordPress, we only showed you the very small part of it, but we can build really complex pages in literally a matter of minutes and it's a huge efficiency boost for our business. So the next topic was we had, after a few months, our solution for site build. Now the front-end architecture was really key for us. We needed to make sure that all the sites were moving across into WordPress, we weren't going to end up with a massive spaghetti front-end code. I'm sure all of you here, like us who are developers, front-end or back-end know that PHP is a templating language, isn't necessarily the best approach, it gets really messy really, really quickly. So we said we needed a templating engine to ensure we sort of decouple our front-end code from our back-end. So Twig was our templated engine of choice and there are two plugins that power this implementation. The first one's called VIP Twig and this one is responsible for integrating Twig simply into the WordPress core. It's a very standalone plugin. Our next plugin, template integration, is responsible for exposing all those core WordPress functions into our Twig templates. It basically bridges the gap between WordPress core and the data our templates need to render out posts on the front-end. The good part about this is if we want to implement a new templating language because Twig is no longer the language to use, we can keep our template integration plugin, it's all reusable and we can just simply build a new VIP Smarty plugin or VIP EJS plugin to manage that integration for that new templating engine. So we have built already our sites and we have a templating engine in place. We need content now. We have been working in content ingestion functionality for around six months in parallel and in May 2015, we're moving to beta testing in a VAP production environment. We're planning to launch our first site the next month, June last year. As you can see on the top, our body in there, it's nowhere close to the right site, which means we're running some problems in production. In our first attempt, we have two major problems. First, our posts are creating a different platform. They are not creating to WordPress. So we had to put a benchmark of 60 seconds from the moment that somebody saves the story or the post and it appears in WordPress. Secondly, we're facing some rare race conditions in there. So it was some content was being duplicated in the site. We're having the same story appearing twice. We don't only have these two major problems when we move into production, but as well, we had to create new sites. Like we said, we have 19 sites now in VIP. We had to do our first import of content in there around 300,000 posts per site from our old CMS. So we didn't have SQL access. Of course, it's hosting in WordPress VIP and they don't give us SQL access. So it was another problem in there to be able to import all that kind of information. After that, we're going to have a constant stream of data flowing into it, which is updates, new stories coming in. We have to keep on pushing information into the sites. So we need an architecture that supports all these kind of features that we needed in there. Here's a simplified diagram of what we have done. It's a very, very simplified diagram, actually, and it can be read from bottom to top. First, our journal is in the bottom. We'll create a story or update it in one of our editorial tools. Then these posts will be sent to our APIs, which manage all our content and we'll organize it and categorize it and make it available so that other systems can actually read it and consume it. WordPress is also being one of them. On top of that, we have, as soon as a message arrives into the APIs, the API sends some notifications to SQS, which is our QN system, saying, hey, there is a new post. There is a new update. Please ingest. With the help of WordPress VIP team, we developed an ingester daemon in there. We call it Turbo because at the beginning, it was built using WP crons, but WP crons are not meant to work in that way. We were, like I said before, we were doing 18 updates per second and WP crons were not coping with it. They're not that fast enough, so we have to develop this multi-thread daemon in there for that one. This whole process that you're seeing here is what we call end-to-end publishing. So with this architecture in place, we have a single entry point for content imports, even if we're doing 300 updates or 18 updates per second, 300,000 updates. We also have, with SQS, we have reduced the amount of duplicate content that we're getting there. Actually, it went up to zero. And finally, we can ingest now content with less than 60 seconds. We're basically ingesting content in less than 10 seconds. It's as soon as somebody saves a story, it appears in the website in around five seconds. That's most of the time that it happens. Another challenge that we face was the amount of fields and data that we have in our JSON post. This is stored in our APIs and that's the object that we get from our APIs. As you can see, there is a trimmed-down version of how an object looks. It's massive, it's a really big object. And at the beginning, we thought, okay, let's use this object, let's split it out into pieces, save most of them or everything into post-meta variables, and then build it up again to be able to send to our APIs. We thought, why are you reinventing the wheel if you're already using this JSON object? Let's just save it in a database in WordPress and consume it from there and read it from there. So what we did in there, we stored this object in the post-content field. With this, we had to change, of course, how our templates or teams work and how our plugins work with that field. So we're actually not reading a text field, but a JSON object, we have to convert that thing. Saving this JSON object, there gave us the ability of having revision over the whole object. And also, when we were just doing, we need to render an image or a page, sorry, with this JSON object, we just do with a database called, we're getting all the information necessary. We finally kept a simple rule in there. We were gonna use only post-meta for searchable parameters in there. That way, we're just using that functionality just for searching information. All this gave us a huge performance benefit by more than having the amount of database calls. After all this, you can probably guess that June came and passed and we didn't launch our site. But they stayed in beta testing for a couple of months. Our internal team, with the help of XWP and also the WordPress VIP team work for around two months to implement all these problems that we're having in there and these solutions that I just spoke about. And one night in September, very late night, we launched our first site in WordPress VIP. It was a night filled with anxiety, too much pizza. And then a site of relief and satisfaction when everything switched on and it just worked. By now, we have successfully implemented a simplistic site build process. We have our front end, it's clean. And we have quickly data flowing into our website. Now, we need to use WordPress that it's meant to be for editing and creating content. So we developed these screens. I hope you can see, yeah, no, they're massive screens because of our JSON object is really big, we have so much data in there that it has to be exposed so people can edit it in the most simplistic way. In here, you'll see that we leverage on meta boxes and we just changed CSS and added more JavaScript around it. We didn't try to deviate much from core, tried not to deviate at all, so that any updates that happen in WordPress.com, we are not getting affected. Here's another diagram called another image of what we're doing in there with images. We're levering off the whole media element from WordPress and we are allowing them to crop edit images very simply in the UIs. Our category manager, it's also a little bit different. Our stories, that's a business rule for us, our stories they have to have in the permalink, they have to have the URL by a specific category that they have to leave. So we had to have a primary section in their primary category that they have to select when they're creating the story and then you can put that story in multiple, in multiple categories to appear of. All these changes are now in production or our team is testing them and they're very happy with us. So within the last, well the first week of February in 2016 we launched our last four sites onto WordPress in just one week and everything just rolled out really, really smoothly. Then gradually over the next four months until pretty much last week all that authoring functionality that Juan just showed you we rolled into a production environment. So we needed to maintain this complex WordPress platform that we'd set up and we also needed to ensure at all costs that it was impossible for any cowboy coders to rise up and try and take control of our code base. So for this it was really critical that we had a solid continuous integration and deployment platform set up. We needed to make sure that a developer could get his code or her code from a local environment all the way up into production in the most stable risk free way. So for us at its core it comes down to feature base branching and feature base deployments. So every feature for us sits within its own feature branch branched off the master branch of Git. It's always developed in isolation. It's always tested in isolation. It's always deployed in isolation. Our team chose to never bundle up more than one feature and deploy it at once just because that for us added too many risks and too many dependencies. Then our team then utilizes pull request to control any code motors into master and this is where code is happening which is one of our favorite pastimes. Every single line of code is code reviewed by another developer. No single line of code reaches production without being developed, code reviewed by at least one or two or some of the three other developers in the team. We then utilize Bamboo's continuous integration platform to manage all of our automation and this is where on every code commit we run PHPCS to make sure all of our coding standards are met. We run PHP unit to make sure all of our unit tests are passing and there's no regression issues that we're aware of. And then once all those tests pass we package up the application running any front end build tasks in goalful grant. We compile our tweak templates and then we deploy that to all of our 50 plus non-production environments. This is when testing happens. So manual regression testing or we have a suite of Selenium based automated tests using the robot framework to run all of our automation. So once all manual testing and Selenium tests have passed and we're good to go, we deploy this feature through our continuous integration platform all the way into the WordPress VIP environment. We celebrate with a few beers and then we kick that process off straight away. The best part is this isn't the process we started with 18 months ago. This evolved over countless retrospectives, team huddles and big issues with our previous process to what it currently is today. So with a solid continuous integration platform set up the only other challenge we faced was with VIP you can't control the exact time your code's deployed to production. And if your feature has changes in three, four or five different code repositories you can't guarantee the order that those repositories are always deployed in. So we needed a way to be able to turn features on and off in a production environment. So welcome to the feature toggle. So this was looking a bit flaky, but this was developed by one of our developers called Roman back in Australia and it's an implementation of the feature toggle technique from Mountain Fowler and it abstracts all the complexities around feature toggling. So with just a few lines of code here you can set up if you can actually see it. You can set up a new feature you can give it a nice descriptive name and then you can on the last parameter the true or false bullying and you can define if it's active or deactivated by default. Then all of our themes, then all of our themes and plugins have access to check if this feature is enabled or not. And if it is enabled you can execute a certain chunk of code. And lastly, this plugin that exposes a WordPress admin screen that lists all of the features that we've currently got available to us. It's deactive and activated state. And this is where you can toggle a certain feature on a certain site. So this feature toggle has allowed us to for our really big features to roll them out to all of our sites from a deployment perspective and then gradually toggle them on one side at a time so we can really stagger the regression testing. So we've come to the end and what have we really learned? First of all, as Juan pointed out migrations are hard, hard work. No matter how much planning you do you're always going to run into unknowns. So for us it was really critical for us to get our code into a beta version of the WordPress.com infrastructure so we could test our end-to-end solutions in their environment rather than our non-production setup. To all those people that said to us that WordPress isn't gonna scale for what we're doing well if you just download WordPress core and install it on a single server and try and support three million users no it's not going to work but if you implement the correct solution architecture with things like memcache with elastic search asynchronous content ingestion it scales really really well for sites like ours. And lastly us partnering with two really awesome teams with XWP who really put a lot of effort in the start of our project. Their expertise in WordPress was absolutely priceless to us. They were pivotal in our project and especially in the first 12 months and a lot of us actually all become really good mates with the XW team. Secondly with WordPress VIP team they just kept going and going and going just like the energizer bunny. They never stopped and no matter how many issues and challenges they threw their way. So at a very high level that was our team's journey. Thank you. Thank you.