 Okay, can everybody hear me? Awesome. We might as well get started. So, welcome to Life on the Bleeding Edge, tracking new PHP versions. Thank you for coming. My name is Adam Harvey. I work on New Relics PHP agent team. I contribute to PHP itself and the documentation and the website and pretty much every other Git repository that we have. And I'm a really terrible cricket player. So that's about all you need to know about me. I also have an accent, I apologize. So the talk's really about keeping up with new PHP versions because it's really only becoming more important to. There are a number of reasons why you might want to keep up with recent PHP versions. The big one of course is for Drupalcon is that Drupal 8 is hopefully coming at some point soon-ish and will require PHP 5.4.2 as a minimum version. So all of a sudden, I mean, Drupal historically has supported generally quite old PHP versions. They've done a good job of kind of maintaining forward and backward compatibility. Moving to PHP 5.4 has certainly given Drupal 8 the ability to rewrite lots of code. The code base looks a lot better. You get to use traits and a lot of other new features. The trade-off of course though is that now you have to actually have your development environments and your staging environments and your production environments all running recent versions of PHP. Of course, there are other reasons why you might want to have more recent versions of PHP as well. PHP 5.4 was quite a bit quicker than 5.3. PHP 5.5 bundles OpCache, which allows you to do opcode caching and is bundled rather than having to pull APC in. It's also more stable than APC, which is a bonus. There are also of course new features in PHP and of course you would also want to keep up with new versions for security fixes. Although of course in practice, a lot of those dealt with by your maintainer, out of the packages where you're getting PHP. So PHP recently, and I would go gesticulate at this normally, but I'm locked to the microphone. PHP has a three-year release cycle. So when a stable release comes out, it is fully supported for two years and then it gets a third year of security fixes only and then it's end of life. What this really means in practice is that to track I guess the current stable version of PHP, you're upgrading every year. In practice, you can upgrade every couple of years and maybe try and amortize the pane a little bit, but of course it's a bigger change at that point. So being aware of the dates for which support ends for PHP versions is can be fairly important. PHP 5.3, for example, is about to have its complete end of life. It will no longer be getting security fixes whenever PHP 5.6 is released, which should be next month if all goes according to plan. PHP 5.4 is about to enter security fix only mode. So it's an interesting one because if you run the minimum version of PHP that Drupal 8 supports when Drupal 8 is probably released next year, the PHP version will actually be very close to its end of life at that point. So there is an incentive to track newer versions like 5.5 or 5.6. And 5.6 is currently, beta 4 is coming out tomorrow. So it's kind of getting to the point where you can play with it. As I said, distros usually backport security fixes into their official packages. That often only applies to security fixes, however. It tends to be on a case by case basis for bug fixes and it tends to really boil down to whatever the maintainer is having problems with will get backported. So you might want to actually not necessarily rely so heavily on the distribution packages. And I'll come back to that in a minute. As I said, there are also a bunch of new features in newer versions of PHP, some of which are actually pretty useful. I mean, things like the password hashing API aren't so important for Drupal because you obviously have modules in Drupal that will handle those sorts of details. But things like generators, things like finally, in PHP 5.6 we have PHP DBG, which is an interactive debugger that will now be bundled with PHP. So that's a useful thing. There are many new features that are worth upgrading if you can. But of course the question then is how do you do it? Well, there are kind of really two aspects to this. There's the question of how do I upgrade my servers, which is important. There's also the question of how do I know what's in the new releases and what got broken in the new releases and what back of compatibility issues there are. So there are a bunch of ways you can keep track of that. We write a migration guide for every new version of PHP, so going from say 5.4 to 5.5. These are in the PHP manual, they're in the appendices and they break down every new feature, every back of compatibility break, every bit of changed functionality, new functions, engine changes, it goes into a lot of detail. So looking at one of those and skimming at least the first three or four pages, which will be new features, deprecated features and back of compatibility breaks is a really key part when you're upgrading. There are also news posts, there are blogs, you can come to talks at conferences. I know there have been a couple of talks this week on newer versions of PHP. There's also of course the server side of it. So there are, I would say there are, well there are obviously a number of ways you can get PHP, but the two main ones realistically are going to be packages, which are what I think most people do and what most people should do. You can also build from source of course, and then there are other ways, you have C, you know, you have control panel, so if you're a managed hosting, you might have something horrible like C panel or a virtual min, which will give you a whole world of pain in and of itself, but will actually deal with one problem which is keeping PHP up to date. So the package situation is a little bit mixed depending on what you're running. If you're running CentOS or Red Hat, I'm very sorry. If you're running Ubuntu or Debian, it's going to depend on what version you're running. The thing that struck me when I was putting this together, and I actually was doing this today to make sure I had upstate information, the thing that struck me was only half of these actually have new enough versions of PHP for Drupal 8. So, I mean the theme of the week is Drupal 8 ready, as was said at the keynote yesterday. So if you're looking to be Drupal 8 ready, Red Hat and Ubuntu 1204 suddenly stopped being very viable options, at least with the mainline packages. There are also unofficial packages available for Linux district before the major Linux distributions, both the Debian and Ubuntu and CentOS and Red Hat ones that I've linked here. I will put the URL for the slides on Twitter and on my website after I'm done. These are actually maintained by the same people who maintain the distribution packages. So these are good ways to keep upstate with the current versions because you know that we package the same way as what you were installing in the first place. On Mac OS, Mac OS itself actually ships with PHP 5.4, which is nice. I was trying to find out state 10.10 ships with 5.5, I haven't heard yet, but we don't know who knows. There is also main, I mean, I think for probably Mac OS in practice, we're really only looking at development environments here. I don't really know anyone who deploys production code onto a Mac OS service, I don't think it does anybody. A lot of shaking because I don't know, that's good to know. I mean, you've got Mac, which is probably a good option for development environments. If we have Homebrew setup, which is awesome, Homebrew PHP repo includes every current PHP branch broken down with pretty much every package. So for example, this is every PHP 5.5 package available in Homebrew. If it's not there, it just doesn't compile. I'm not gonna talk about Windows. I really genuinely don't know what the state of the art there is, I assume something like XAMP is gonna be the best way to get going, but I think in practice, unless you're deploying onto a Windows and probably Azure, then it's hopefully fairly irrelevant. I mean, you're probably better off at that point using something like they don't have a development environment. I'm gonna talk more about that in a little bit. As I mentioned, another option is you can also build from source. This is not why it's as terrifying as it sounds, but it's probably not the first thing you want to do in the command line. It's a fairly standard completion process for most of the Unix programs. You basically must read the script, and you tell them what options you want, and you run them and you can hopefully get an executable at the other end. Configure dash dash, helping you break down everything you need. The problem is you're always getting the same ones that you're writing on now and then you're getting a bunch of cheat sheets because if you just give you every build, you're gonna need to provide for it to be HP packages, and generally, you're gonna have to give you another build, but you may want to have a lot of stuff that you don't care about. So building from source is doable, but it's just a little bit tricky, and I mean, I would say being stick with packages, it's a good way to learn, it's a good way to get a QAPS here itself, but what you're interested in is just kind of keeping up with the current 5.5.5.35 version for your drill for the types of sites you work on, probably not worth the time. Now, the last reason is the rest of it, you can pay HP and PM, that will basically support 7.8, on the HP 5.5.5.5.5, on the devian.1.2. You can see it clearly that hard, the trick is getting the libraries and rights, and knowing that you need the X and the X amount, knowing that you need APH and so on and so forth. Finally, you may need extension, such as MET, PAD, SH, IPC, CD, because if you use APC, you might want to go over, there are many reasons why you might want extension, as I keep writing, it's called KICL extension. If you have a package called KICL extension, you can use that, use that, if not, you have the KICL command line tool, which if you have IELI, IELI development, development and so on, you can use the news package and have it configured. You can download, download, tab or configure yourself, make it work, it works, it's going, going. It's also worth knowing when you're grading, particularly if you have to build from outside, if you actually build your own packages, you may need binary, binary, it's available on a single server, you upgrade your APH, it's from 5.5.5, you have to have to have, you have to rebuild your extension, like you pointed, you didn't install packages, you installed packages, packages that are scheduled for you. So we know, so we know, it's, you pay your PHP, but where are we going to need that? How do we have those environments? So, of course, all of us have these, all of us have these environments, like IELI development, testing, testing, So we have the same plane, same tank, and we have the same system and we have the same operating system. And you can use those new machines to try and replicate your production reductions for development and development. But we are never going to get exactly the same. Particularly if it's on production reductions, we are going to build everything that we are going to target, we are going to save the air, the air just to install a bunch of packages and really know exactly what happened, what happened. and I'm having an un-matching backstab to manage my urgency, sorry, I'm sorry. New sites are easier, easier to use and use. There are so many ratings for each one, there's this sort of thing, they use vagrants, they docker docker, to manage this, there's not a lot of talk, a little bit more about those in a second, second. You can manage your manageration ratio by using tools like Chef, Chef Hub, the Hub and Subments, and then you can actually actually round out a set of, the end basically, that's the developer developing and exactly matching the actual production environment. Provided of that you're using your meeting as a dedicated hosting host. Of course if you're using a managed managing solution and a lot of this becomes somewhat more difficult but also less relevant, I mean if you're using your hosting host, you're probably not going to be in their environment exactly, exactly, but also probably won't really want to mean at that point, what you're really trying to manage in terms of quirks. The fact that the PHP behaves differently on every platform, there's so much of PHP that's being wrapped around the C-standard library. So, at that point maybe you really need to use at least a natural SLSS, or match Windows versus non-SLSS at the very least. Vagrant may be a great use of this for this. So, very quick vibration. How many people know what Vagrant is? Before I go too far into this. So Vagrant is basically this way of defining and managing virtual machines. It's usually, usually development, you could build up virtual machines, deploy them something like EC2 if you really wanted to, but it's really a great developing tool because it means that you can, say you've got a site you're building for Linux server and you've got a bug that is only appearing on the production server and you think you've isolated it from being in the environment. So, you can do a file system handling on Linux or something like that. Even if you're running, say, a Windows machine or a Mac like I am, you can use Vagrant to build up a virtual machine for whatever Linux distribution or Mac OS or a bunch of other operating systems if you're deploying, say, joint and Solaris at that point. Good luck. So you can basically define how you want a virtual machine to be built and then you can share that definition around and give you an easy way of managing your virtual machine and managing development environments. The website is Vagrant.com. I would strongly recommend it, at least browsing it, just from the point of view of it is a useful tool. So in terms of testing, so I mean we've dealt with the development environment, now moving on to testing. If you have the developer time and the spare hardware, which is a lot of the time you don't, but if you do, it's always nice to be able to south your test suites, which of course, again, we all have, to run against newer PHP versions than the one you're actually deploying on. I mean obviously in actual production environments as well, but it gives you an element of future proofing. The last company I worked for before New Relic, we made SetOps. We did entertainment systems, and we actually did software for SetOps boxes, and it was all managed by a, actually it was a symphony back-end rather than the Drupal back-end. Pretend I didn't say that, but it was a symphony back-end that we were running on PHP 5.4. Anyway, PHP 5.5 came out last year, it had lots of new hot lists that we wanted to use. We were able to upgrade in basically an hour on our production environment because since about beta 2 of PHP 5.5, we had our continuous integration system actually doing tests on PHP 5.4, matching our production environment, but also PHP 5.5 for whatever the current version was. Now, I've got a little bit of self-interest in saying this as well to declare my hand. I obviously work on PHP. We really need more bug reports from people on PHP 5.6 and in development versions. So it actually helps us as well, but it helps you because the time that you spend to start with making sure it runs on the new version and reporting any bugs where we broke your code and it was our fault, then means down the track that when it is time to upgrade, you're upgrading your server's distro, you need to upgrade because the version of PHP you're on is about to become end-of-life, whatever the reason may be, you can then actually upgrade very, very rapidly and seamlessly. So I strongly recommend that if you have the ability to do it and not everybody's going to, and that's fine, but if you do have, particularly if you have dedicated QA people or if you have dedicated infrastructure people, this is a really good thing to do. There are a few ways you can get these multiple versions. You could, if you're building your own, you can give Configure a prefix and it will install everything into that directory. So you could set up an opt hierarchy like that. You can have multiple VMs and if you're using something like Jenkins, then you can just have multiple build slaves in your job configuration. You can use Docker containers. So Docker is an interesting thing. It's basically a way of building a container that contains a Linux server but which doesn't run in a virtual machine. It runs on a Linux host in using containers which are basically a somewhat similar to BSD Jails or to Solaris Zones in terms of you don't have the overhead of the virtualization. I mean, you can run this on a VPS and it's not a problem. But it still gives you a declarative way to have a consistent way of building out these containers and what you put in them and what PHP you put in them, for example. There are also hosting services now that are beginning to emerge for Docker containers. It's still a relatively new thing but what that means is that you can actually use, specify a Docker container and then basically you know you've got the exact same environment from development all the way to production, all through those phases. The nice thing about Docker is it's very declarative. So you can actually set this up very easily. So if you want to set up a PHP 5.4 Docker, I mean this is obviously just for the command line but you can extend this out to whatever set of packages you need. It's literally a three line Docker file. You run a build command and you run a run command and if that test.php is your top level test suite you've just run your tests on that version of PHP. And then if you want 5.5, I mean in this case all I've done is changed which version of Debian we're pulling in so it's a version that has 5.5, build, run. You just got test results on multiple versions of PHP for very, very little work. So moving into production, if you're on shared hosting you probably can't control the version of PHP you have. It's probably old and you probably really wish you were on a VPS already. So go to a VPS. I wouldn't... 10 years ago shared hosting made sense. Hardware was more expensive. Hardware was more expensive. I really have a second point. Nowadays it doesn't really make as much sense. VPS hosting is very cheap. If you don't have the in-house expertise to do VPS hosting or manage your own servers there are many, many fully managed options. There's Acquia, there's Heroku, there's Google App Engine. There's so many ways to skin this particular cat. So, you know, there's kind of... I would say if you've got the in-house expertise go for a VPS or a dedicated host or multiple dedicated hosts depending on your size. If you don't have the in-house expertise there are plenty of companies who will very happily deal with this for you. My marketing department would like me to note that you should also install New Relic. So to summarize, new versions of PHP don't have to be scary and you can get significant wins both immediately and down the track by tracking new versions of PHP and testing against new versions of PHP. There are so many new tools now I mean I've only just touched on these very briefly this isn't a tutorial but there are so many tools in the lay to have more environmental consistency and thereby hopefully reduce your bugs and reduce your testing overhead when you go from development into production for your awesome new Drupal 7 and 8 sites. That is all I have. I am happy to take questions and thank you very much. Are there any questions? Well, thank you again. I believe the next speaker will be up a solid Drupal person, so I'm just going to do whatever Drupal does. It's good to hear with some authority what PHP is. Yeah. Well, that's it. But it does have a library. Well, here, we'll fire this up. This is all hooked up. This should be good, right? Yeah, it will be. Yeah. We just got to swap one around and I can delete that other duplicate. Oh. Let's use... Oh, we... Oh. Do we have our laptop? Yes. Yeah, let's use it. Is this the wrong version? Nope. It's probably a fallout thing. Yep. Yes, please. Sweet. You just saved my bacon. Sure, it has a great one. Thank you very much. Should I swap out my Steven's path sticker with the form ones? Well, I mean... This is my favorite ski resort. 10% battery life is enough, right? No, I think it's what's up to this. We have power. Maybe, alright. No, I'm actually at 43. Look, everyone, it's my inbox. Except I'm going to find the file before I plug in. So far... It was just working. Yeah, I don't remember. Yeah, you know. In case the tab didn't actually go through and you're typing your... Did you just have your drive window go back to drive, I'll show you where it is. Those slides get switched. Oh, no, this is the live one, but I can actually go and delete. Alright, you ready? Present. Welcome to 530 on Wednesday. Welcome to 526 on Wednesday. Yeah, we... I don't know if folks are going to be flooding to this thing, so if... I do have a lot of slides. Yeah, let's go for it. And if folks trickle in. So this business showcase is a story that we're going to tell about a city, Seattle, and a surrounding region, Puget Sound, and a bicycle club. You typically would think a bicycle club is a little tiny organization. This happens to be one of the nation's biggest bicycle clubs. It's the Cascade Bicycle Club. And how they, over the past year or so, have revamped the way in which they're operating their business to use Drupal. They, like lots of organizations, their Lifeblood really is their website. They organize lots and lots of rides in the region. Have some 60,000 members and host some 95 races, and really it's the registrations for those races and the communications with their members through the site that is what drives the organization. So it's not just a website. It really is their operational business tool. And so this is a story about how Drupal has helped to for them to achieve that and sustain that kind of operational need that they have, which is to run the business and serve their members. I'm Kurt Velker. I'm the chief technology officer by Andy Heave and Andrew Morton. They were engineers on the project. Andy heads our West Coast tech folks. We have offices in Seattle and Washington, D.C. and I was Andrew Virginia. We're about 80 folks. And Andrew is a senior developer on the project. We should probably say also we typically do this presentation with some folks from Cascade. They're not here today and Andy's the active technical architect on the project and Andrew is working on the project actively now. Both of them came in later in the project. Just full disclosure there. Some of the things that we're going to show you, they didn't work on directly in the early days. And for those of you who don't know us, Forum One is a full-service digital agency. Like I said, we're headquartered in Alexandria, Virginia and have offices in Seattle and some folks in the Bay Area. We're about 80 folks. We craft solutions for what we think influential important organizations that are focused on health, education, the environment. Kind of the world's problem solvers is what we like to think about. So we're very mission-driven with the types of folks that we work with and we help them craft solutions to make them better at solving those problems. That's really our mission in life. I hope it's going to be an interesting conversation. I'm going to turn it over to Andrew at this point so we can share the story. Cool. Thanks, Kurt. Yeah, so I just want to give you a few more points about Cascade here. They are a cycling advocacy organization. They do a lot of lobbying. They go to a lot of meetings with the local Transpo groups to, you know, get more cycling lanes built. They're actually the largest cycling club in the nation. The satellites are very enthusiastic about their cycling, but they serve the Puget Sound region. They've got over 2,000 ongoing daily rides. Those are organized by volunteers. They kind of assemble people and take them around the city and do everything in between that just from the fun stuff to the lobbying and advocacy. They've been around for 40 years and over those years they've built out multiple websites and different web entities. But now they're kind of coming together. They're looking at what they have and they're like, let's clean this up a bit. Let's turn this into one solid site that does what we need. They have a long history in Seattle bouncing around to different vendors or even working with multiple vendors at once. But our partnership with them began in 2013. So, yeah, that's kind of the background on Form 1 and on Cascade. And so what did this project actually look like for us? It was a big project. We consolidated 12-ish websites, eight of which were pretty static, four of which were dynamic, database-driven websites into one. Those dynamic sites were on platforms varying from cold fusion to WordPress, some form software. And their Drupal 6 instance, which was running CVCRM and UberCart. So we had to consolidate all those sites into one. We had to upgrade the main site, get more updated, all the various components for that. And as you can see, the sites that they had previously were pretty dated. They needed some pretty substantial user interface and user experience work. So we had a substantial redesign task ahead of us as well. There were some technical challenges on the project. We're going to talk about three of them in particular today that help us tell this story. So, there was a lot of technical debt on the project. It was not surprising given the history that Andrew mentioned. A lot of people had touched this over a long period of time. And they had essentially all of their business logic encapsulated in a bunch of custom code on the site. It was roughly 15 Drupal modules, roughly 15,000 lines of code. Again, not surprisingly, that code was not very well documented. It was difficult to understand. And it was spaghetti code, basically. So it was a lot of technical debt that we inherited. Needless to say, maintaining those sites given that situation was a lot of work. Adding new features is a lot of work. And certainly a key goal of our project was to reduce those maintenance costs. So, we had this grand vision originally to just rebuild the site from scratch. We had a chance to sit down with them. We're going to start from scratch, apply all those lessons learned. We're going to rebuild the site completely. We're going to get rid of UberCart. We're going to go with Drupal Commerce. Obviously, go into Drupal 7. We're going to eliminate as much of that custom code as we possibly can and move it into contributed modules. Workhorses like rules, we figured could do most of the work for us. And the custom code that we did need to keep around, we would refactor as best possible. We would clean up and we would start with a brand spanking new bike instead of the old bike. But as we got into discovery, we realized that that was a gargantuan task. Just to understand all of that business logic and then try to rewrite it completely from scratch, was going to be a huge task that was going to exceed the scope of our work. I mean, we felt that due to staff turnover on the project over the years, all the custom, all the business logic captured in this custom code, but it was really the only record of this business logic. So to try to rewrite that from scratch was going to exceed the scope of the project. So our approach instead was to upgrade the site. To take all the various components, Drupal, Civi, UberCart, and upgrade them. We decided to stick with UberCart as opposed to changing over Drupal commerce. And that still gives us the advantages of cleaning up the custom code as best we could, refactoring where it was possible, certainly documenting it better along the way. This was a big pivot for the project. But thankfully at this point we already had a great relationship with Cascade. We were really a trusted partner of theirs. We talked with them about it. They understood the situation and they trusted our recommendation. So some lessons we learned from that challenge, upgrading can be less risky than rebuilding the site in certain situations. And again, we were able to still reap a lot of benefits of touching that custom code, again refactoring where possible, but certainly cleaning it up better documenting and providing ourselves a much better platform moving forward to iteratively develop on top of. The coder module was also a lifesaver for us as far as pointing out Drupal's 6-7 API changes and syntax changes. We really relied on that for porting over the custom modules from 6-7. So the second technical challenge we want to talk about was trying to upgrade and redesign at the same time. I'm going to tell you a little bit more about what I mean by redesign in a minute. But it was a bit like juggling while trying to ride a bike. Stick with the bike analogies. Not very easy to do. So again, after we came out of Discovery, we decided to upgrade all the major technical components of the site, Drupal, Civi, UberCard, port over the custom modules, and at the same time we were trying to do a substantial redesign of the site. We were going to build it responsively. We were going to add a whole new suite of page layout options for their editorial staff. What else? Add a bunch of new features. There's one other thing I was forgetting in there. Oh, entirely new information architecture. Not unimportant. So we were redesigning the site and upgrading, and our plan was to do that same time. That's a lot of work. So here are some of the problems that we ran into with that approach. First of all, we found that a lot of the redesigned decisions were dependent on the upgrade. So for example, if we had decided to move to Drupal Commerce from UberCard we would have needed to redesign the whole order workflow for the end users as well as retrain the Cascade staff on store management from an editorial perspective. We also found that the tech team's attention was split between trying to really wrap our heads around the upgrade and work hard on the upgrade, and at the same time talk to the Cascade staff, information architects, designers about decisions related to the redesign. And like I said before, there was enough unknowns in that business logic and the custom code that was really difficult for us to work with the team to estimate and prioritize redesign tasks that might come after the upgrade. So what we decided to do was pause the redesign completely and just focus 100% on the upgrade first. Called this our Uber Sprint. And the technical team essentially locked themselves in a room for a couple of weeks and just pounded out the upgrade didn't even think about the redesign. This let us get the really the most critical part of the project behind us and before we would move on, and the riskiest part of the project by far before we would move on to the redesign steps. So in retrospect we might have even pushed this a bit further and split the project into two and really push the upgrade all the way out to production before we turned our attention to the redesign. That would have let us take a less it would have been a less risky approach for sure. As it was to go through the full launch process was some 300 steps. Many of those were manual. It took over 8 hours I think on launch day it was 14 hours. It was a big process and for that reason we could only test it twice from start to finish before launch. So that's pretty risky. If we had split that into two steps it would have been definitely easier on the project team. Arguably it could have taken a little bit more time. Calendar wise it could have been slightly more work as well because we would have had to for example port the theme over but on the whole we felt like that would have been a smarter approach. And then lastly technical challenge what we talked about was staging content. That's a great picture. The Cascade editorial team had 100-ish new pieces of content. They wanted to be able to edit and refine using their full editorial workflow but have published at launch again in the new design in the new information architecture. Understandable. There was a lot of baggage laying around as far as their content from over the years. But we had to figure out how to do that because in the dev and staging environments that we were working on we were really hammering on the upgrade. They were pretty unstable. We were pushing a lot of new code often and we were testing the upgrade often. So what we ended up doing was actually spinning up a separate content staging server and we provisioned that for the Cascade folks so they could actually build out all their new content there all their new menu structure everything in the new design the new information architecture and we are in the meantime pushing code out to the dev and staging environment and doing our testing there and we created a system using Migrate and the Migrate Drupal to Drupal modules to periodically migrate content from the content staging side into those other environments. Because of how Migrate works we could do that iteratively we could do it often. It was a really nice solution for that problem. Are there any developers in the room? Kind of? I don't know if you all have worked with panelizer or Migrate before but one quick tip here when we were doing the migration so the Cascade site relies on panelizer quite a bit for per node panel layout settings when we were doing the migration we found that panelizer doesn't support Migrate so we had to work around that a bit here's the solution we came up with there was a little discussion with Mike Ryan about whether this DV set active was a smart thing to do but basically what we're doing is we needed an extra step of extracting the panelizer settings for the given node from the source database and then later injecting them into the new entity on the destination database. Cool, so we just went over a couple of the technical challenges but I want to call out some of the big wins we had mostly with but one of the items is our content layout options we were able to provide their editors because we were bringing in so many different sites into this one we were now responsible for serving a wider audience and you know hosting more content so just to recap on what we're coming from their design was a little bit dated and they also wanted to go to a mobile responsive layout as most of their members are in fact mobile this is just a cross section of some of their content on the left side there you can see how deep their menu goes this page shows a gallery of some of their major rides throughout the year it was just a really great way to show this all up front to some of their users and entice them to click through and find out more and here's an example of clicking through to one of those major rides you can see here in red on the left side how many additional pages deeper in the hierarchy we have providing just tons of information about this one particular ride and this is the Seattle to Portland bike ride which we participated in which was pretty fun and a quick recipe here this is a solution that we use a lot panels, panelizer fuelable panel panes and oh, menu block really does a great job of putting this all out there and it's pretty quick and easy to build but now I want to talk about performance so the websites really important to Cascades organization 80% of their revenue comes through this website and most of that comes through during two high peak sales periods in January February where they open up in two stages event purchases for the whole year and so what happens you have all these enthusiastic cyclists who are just lining up to participate they know the rides sell out and most of them are trying to compete to get low numbers on their bibs for some reason but long story short they knew that this had to work when we launched it so this shows you what those traffic spikes look like I know this has visits but that's actually concurrent users and this is transactional data this isn't just browsing static content so yeah the orders of magnitude difference we started off tackling this problem by ramping up to the largest single instance on AWS it's a C3 8XL it's massive it's got 30 cores 60 gigs of RAM and runs on solid state drives it was really kind of fun just to log into that thing but we went even further we did some testing we used a tool called load impact that allowed us to script a scenario through the site so I basically clicked through to the purchase workflow and then it uses that scenario to script multiple concurrent runs through that and we were able to ramp that up and kind of find out where different parts are going to pop over and tune those until we've got it optimized to the best weekend so some lessons we learned along the way there start early you'll need time to make improvements we launched the site in November and their high peak traffic period was in January so we had about two months that gave us enough time to get through all this testing and optimize now that we spent a full two months there was a lot of debate over what they wanted to do here when you do upgrades don't just assume that's going to give you a performance boost as we found out with our additional theming layer and additional features in the CVCRM platform and the uber cart platform I think Drupal may have gotten faster yeah didn't we still had to do this testing and optimization but the real key here is knowing what your target is and being able to question if your test is matching your target it's not enough to just say well the website has this many concurrent users therefore the test needs to support this many concurrent users the test is a simulation it is not always represent real life performance and you can do this by multiple tests and also tracking your performance in your analytics numbers and to bring you back to the title here Riding Tandem we really worked closely with Cascade there was a number of staff turnovers on their side which really led to some challenges but because we worked so closely with them and we kind of carried on the documentation of what we were building for them we were able to help them out with their staff transitions kind of bring some of their people up to speed especially their communications people and just to point out their executive director was transitioned during this build so you can imagine a new ED coming in during a project and just being like what's going on here but she was very good about letting us do our thing which is just amazing pro tip here do some co-location with them in their office about twice a week and just kind of sat alongside them it really made it a lot easier as we're going through this 6-7 upgrade code basically what happens is you start off nothing works and so as you're looking at the code and trying to make it work you're like what is this supposed to do and so having them right there to tell us what they wanted to do with it really helped get through that a lot faster and just to kind of point out a picture of launch day and we're all sitting here we've got content people we've got QA also the person who does the business logic we've got PMs developers, themers and tech leads both internal and external another tip check out a shared chat room program this is hipchat it was really easy to get them in and respond to our questions really quickly one key thing here their tech lead his name is Tim O'Connor he kind of wrangled a lot of their requests on their side so that we weren't getting just shotgun with request we were able to decisively go through what they wanted and make sure we were doing it at a rate that we could achieve another item so we had this feature for daily rides and when we originally scoped it out we thought it would be easy but once we got through discovery we realized that what they wanted was much bigger than what we thought we would get so we worked with someone on their team, Alan who he did a lot of their reporting so he did a lot of database queries and was familiar with certain aspects of their system and wanted to learn more and this was a great opportunity for us to teach them a little bit about Drupal, you know when you don't know what a system can do it's hard to know what to ask for but getting him and he actually came down to our office and worked alongside us we coached him into building out this daily rides feature and that was a pretty big success one more, get out in the field so this is us on the saddle the Portland bike ride got our sweet form one jerseys all happy to be there it's a little early for me, I'm a little less happy so the relationship was excellent the partnership is excellent, that's really the story we want to tell but we want to circle back to to demonstrate that on what did we actually achieve here so again they had a pretty disparate and dated set of scattered web properties in the beginning but it didn't really serve their audience or their business needs very well and we brought that together into one unified Drupal 7 platform they have a platform to sanely continue development forward now as well it's all redesigned it supports their full editorial workflow and redesigned in a responsive way as well and the site was received really well by not only Cascade and their stakeholders but the entire Puget Sound bicycle and community this is a tweet that we enjoyed from Seattle Bike Blog which isn't connected to them it's fancy and you can find stuff, it's great and crucially the site has stood up to support this mission critical revenue stream for them again 80% of their revenue through the website was that in two days basically and it stood up for them at the peak there were 1,000 plus simultaneous users they ran through 156 orders in six minutes I guess that was tops there but the site Andrew mentioned there's a long history in the tech community there had been problems on these days as you would expect and the site held up for them so that was absolutely crucial and ultimately the site's just given them this platform's given them a better way to engage with the audience groups that they want to educate, support and advocate for. That's all we've got Any questions? Is anybody in here a ride a bicycle? Sorry Ben, go Hold on we're going to repeat the question politely. The question was about the list of modules used for the page layout options that we were discussing. Yeah, that was panels, panelizer, menu block and fieldable panels, panes Also check out the pane module. It's written by one of the forum one guys What's really cool about it is it lets you capture the container and your content into features separately You can capture one or the other or both which can be really handy So you could like deploy the container stick the content in and then if they change the content it doesn't tell you that features is over written Yeah Well, we touched on some of it Andrew you can jump in here as well but it took a long time that was like the heart of the project really it was really difficult and as developers we're kind of like give us a code, let's see what's going on we'll figure it out and like I mentioned that was very difficult but really it was that partnership that had to facilitate it we had to get to know them really well when we co-located that was priceless because we could just bounce questions off of them right away but yeah, there wasn't an easy answer to that actually our former tech lead went into their office and got to sit down with them sat with each one and sort of walked through how they were using the platform the thing that we missed that it was hard to get was all the logic that was in the code that they just don't tell you when you're sitting with them so most of that came down when we were in the uber sprint and we were going through this code and just like what is this supposed to do sometimes it would be obvious and sometimes it was like really bad convoluted code that we had inherited and so we really needed to be able to ping them really quickly and find out like what do you want here and of course document along the way anything else that's a good slide right yeah I'll send it to you bitch alright thank you everybody