 thank you guys for joining us for our webinar today. We're really excited to host with Forum One and Cascade Bicycle Club and just want to do a little bit of housekeeping before we get started and jump right in. If you're listening from your computer we suggest making sure that your mic and speaker audio options are all set up. We wanted to let you know that you'll be muted during the call though we can answer any of the questions that you might have in the Q&A window. We aren't using chat this time around and we can take them as they come and then definitely there will be time at the end of the presentation to go over some of our questions. We'll have a post webinar survey that'll come out to you and it'll also have the video recorded of this presentation for you to look at further. Next slide please. So a little bit about the Drupal Association. I'll introduce myself. My name is Lauren Che. I work in Portland for the Drupal Association as the community outreach coordinator and you know it's been a really exciting time to be involved in the Drupal Association. Our mission is to foster and support the Drupal community so that we can collaborate and help innovate the project. There's so many ways that we can help the community. We host Drupal.org and we're building a tech team to improve the site. We provide grants for the community members to fund the way that they grow and further the project like starting new camps in different areas or running a multi-city roadshow energizing and invent evangelizing Drupal. We also host Drupal Cons which brings thousands of us together to work on the project and bond as a community and we provide scholarships for members around the globe to attend so if you have any questions on that please let us know offline and we can get you that information. And all of this is funded through our membership search Drupal Cons and our supporting partners. So you can see we also have some community programs such as our global training days which is a really exciting new program that we're doing as well as these webinars to help help let you guys know what's going on in the community what's hot what's being talked about and exciting things happening. Next slide please. So upcoming events we have Austin Drupal Con in 2014. We have our Drupal Global Training Days May 30th and our next webinar we invite you to attend. Microsoft presents Easy Drupal in the cloud using Windows Azure. Next slide. And we just want to thank Form 1 for being our supporting partner without our partners you know we couldn't provide a lot of the services and programming that we offer so thank you guys in advance for an amazing presentation. Next slide. Without further ado I'll present our introduce you guys to our presenters. We have Tim O'Connor with Cascade Bicycle Club, Bridget with Form 1, Stein with Form 1 and Andrew with Form 1. Thank you guys for speaking today. Thanks Lauren. So before we get started a little about the two organizations so Form 1 as Lauren mentioned we're a digital agency focused on driving progress on issues of societal importance such as health, education, the environment and international development. We do everything from digital strategy to branding, interactive design for web and mobile, accessibility and usability engineering. You can see some case studies at the link below. We're also going to be tweeting from this webinar at hashtag F1 webinar if you want to check that out and Tim. Thanks Bridget. My name is Tim. I'm the tech manager at Cascade Bicycle Club just tell you a little bit about us. We're a nonprofit focused on creating a better community through bicycling. We have many different programs. We do over 2,000 free daily rides around the Greater Puget Sound area. We do 15 paid events that fund a lot of our non-profit activities. We have advocacy or a lobbying effort to help get safe streets in place in the Greater Puget Sound area and a pretty comprehensive education department that through its efforts teaches up to 18,000 kids a year how to ride safely, put their helmets on and grow up in a healthy community here in the Puget Sound. We're about 40 years old. We have around 60,000 supporters, 15,000 paying members who help fund a lot of the nonprofit activities we put together. Around 900 volunteers really help us and the 40 staff members put on these great events or make a big difference in different communities around the Greater Seattle area. Our vision is to create a better community through bicycling and over the years, 40 of them, we've come up with a number of programs. We do just about everything you can do on a bicycle to make a better community and that means that over time we grew to have 12 different websites for various programs. The user experience was quite disorienting and we did need one website with one login. We're very lucky to find 4-in-1 communications in 2013 to launch this pretty massive web rebuild. Let me just go over the scope of that. We had Drupal 6. We need to upgrade that all to Drupal 7. We need to combine eight websites and four databases so people didn't have to remember four logins just to access the different aspects of Cascade Bicycle Club. We use CVCRM, which is a free CRM system that we had a lot of custom codes invested in. That needed to be upgraded significantly and so did UberCart, our e-commerce solution. And because we're combining so many websites and databases, a lot of design and thinking hard about how users navigate the site and how they find us. Not just a organizational chart for the higher level menu, but what they're looking to do when they come to our website. So that's where 4-in-1 also helps us have quite a bit. Now I want to pass it on to Stan from 4-in-1 to talk about the technical challenges. Cool. Hey everyone. So we had a number of technical challenges during the project that I wanted to talk about. The first challenge was technical debt. Cascade's website had a lot of it in the form of critically important custom code that served as the site's glue. Thinking data between Drupal, UberCart, and CVCRM. That custom code was in 15 different custom modules comprised of about 15,000 lines of insufficiently commented and pretty difficult to understand code. And that custom code contained large amounts of undocumented business logic. Maintaining that code, fixing bugs and adding features was proving quite expensive. So one of the key project goals was reducing the cost of maintaining that code. Our initial approach to solving this problem was to essentially rebuild the system, completely overhaul the bike so to speak, by replacing UberCart with the more widely used Drupal commerce, replacing as many of the custom modules and business logic as we could with contributed modules like rules, and then carefully refactoring and documenting any remaining custom modules, still necessary. But as we explored the level of effort necessary to understand and then reimplement the business logic contained in the custom modules, we realized the task was going to be too big for the scope of the project. So instead of swapping out UberCart and reimplementing large swaps of the custom code, we determined the less risky option was to simply upgrade all the components as is and get them working in Drupal 7, and huge credit to Cascade for rolling with what was a pretty major architectural or change to the architectural approach shortly after the project started. So we upgraded UberCart, ported all of the custom modules to Drupal 7, reformatted the code, added comments to improve code readability, and as time allowed started the task of refactoring some of those custom modules. So lessons learned. A key lesson for us was that porting or upgrading custom code to a new Drupal version is often simpler and less risky than trying to replace or rebuild them, particularly when the custom code contains a lot of complex undocumented business logic. A side benefit of choosing to port the code rather than completely rebuild or rewrite was that it gave us the chance to clean the code up, refactor a little bit, and better document the code, all of which I think will help make it easier down the road when Cascade decides to rebuild or refactor those modules. Lastly, the coder module was pretty helpful. It can help you automate the task of porting your modules by identifying the Drupal 6 specific syntax in your code and suggesting Drupal 7 equivalent, assuring you don't miss anything. So our next challenge resulted from starting a complex platform upgrade and redesign simultaneously. We quickly discovered it was like trying to juggle and ride a bike at the same time. It's possible, but it can make both tasks more difficult. Just as a reminder, we started out upgrading Drupal, UberCart, CVCRM, and porting those 15 custom modules to Drupal 7. And at the same time, we started the redesign on the information architecture, building a new custom response theme, overhauling the page layout and management, and adding a number of other new features in the backlog. We quickly hit snags with this simultaneous approach, however. A number of the redesigned decisions proved dependent on the result of the upgrade. For example, had we switched to Drupal commerce, we would have needed to design new order workflows. Another issue was the tech team's attention was split between figuring out the rather complex upgrade to Drupal 7 and advising and providing estimates to the designers and IAs on the time. So there was some inefficiency in the task switching there. And lastly, the upgrade of custom code was really critical. It had to be done, but there were a number of unknowns around it and we didn't know how long it would take as a result. And that made it difficult to determine how much budget would be available for the redesign and prioritize the redesign tasks accordingly. Excuse me. So we hit the pause button on the redesign and decided to focus 100% on the upgrade until it was complete. We ended up calling that upgrade period our big Uber sprint to get all of Drupal, the Uber card, CVCRM, and the 15 custom modules upgraded. By doing that, it allowed us to put the most critical and riskiest part of the project behind us and then turn our attention to the redesign. In hindsight, I would take it even a step further and not just do the upgrade tasks first, but launch the site after the upgrade, i.e. push the upgrade live before beginning the redesign, as this would simplify the launch and deployment process for both parts of the project. In our case, since the steps to execute the upgrade of Cascade site to Drupal 7 were quite time consuming, there were over 300 mostly manual steps that took over eight hours to complete. We were only able to fully simulate and test upgrade and launch of the redesign twice before the actual launch day. Our third challenge was how to stage all the new content Cascade was preparing for launch. Cascade had 100s of new pages that needed to be published on launch day, all within a new information architecture and design. Cascade needed to create this content ahead of time so we could test it with the new code and features we were developing as well as we needed to practice deploying it. So in addition to the dev and staging servers we used for testing new code and features, we spun up a content staging server for Cascade to use to write new content and build out the new menu structure of the site. We periodically deployed that new content to the dev and staging servers using a migration solution built on top of the migrate and migrate Drupal to Drupal modules, really great packages for migrating your data either from other systems that are not Drupal into Drupal or from one Drupal site to another. Having the separate content staging server ensured we didn't accidentally break or erase Cascade's new content with untested code changes and the migrate based deployment allowed us to repeatedly simulate the deploying of that new content on launch day and iron out bugs before the actual launch. One technical tip we wanted to pass on is around migrating overridden panellizer settings on nodes. Cascade's new Drupal 7 site and content make heavy use of panellizer. Unfortunately, panellizer doesn't support migrate out of the box but we discovered that it isn't too difficult to implement so this is more for the technical folks out in the audience but as you're building out your migration or migrate based migration solution, if you extend the prepare method on your node migration, you can basically just load the source node and copy the panellizer property on that node to the destination node entity about to be saved and that will bring over all of the panellizer settings and content for that node. Hey, this is Andrew. I'm going to talk to you about the content display on the website and some of the modules that we used. I think part of this redesign was so that we could give Cascade better ways to provide content to their users and their users are a very diverse group. They've got people interested in getting into cycling. They've got enthusiast cyclists and they've got people who are just an advocacy. These are some pretty common modules but we were able to leverage them to really give Cascade what they needed to provide a complicated hierarchy of content and also display related content. What we're looking at here is sort of a category page under major rides and we're using flexible panel panes to show underlying pages and it really invites users to get into the content and drags them into the deeper level pages where it's more relevant to that specific user. This is just a little more of that for an event page. We use panellizer so that if you put in a location, you'll get a map on the sidebar and you're also seeing a little bit more of the entity references in the event details here. Those are actually other pages that are referenced here. So that was talking about performance. So we've added all these bells and whistles and we wanted to make sure that we could get up the hill at the end of the day. This has been a problem for Cascade in the past as most of their traffic to their website comes in mid-January and early February. That's when they open up their ticket sales to their registered and unregistered members and really kind of sell out most of the events for the year. So they really rely on this period and their website really can't go down. We use load impact which is a tool that allows you to simulate hundreds of concurrent users. It gives you a bunch of parameters on how you want to schedule and run your test. But basically we scripted out a shopping workflow where a user would buy a membership and an event ticket and we just kind of ran that over and over again to see what kind of performance we could get out of it. At the end of this chart here you'll see the blue line sort of thrashing around and that's not good because that's how long it takes for one path to complete and when you see it jump around like that we started to see issues with the server of failed completion. But after tuning the server and the database we were able to get a lot more performance out of it. One big lesson learned was we had to bump up the server size from what we were using in the previous year. Fortunately we're using Amazon Web Services and that allowed us to do that pretty seamlessly. So the takeaways here start early. We launched the site in November and that gave us plenty of time to make some improvements. There's always more room for performance improvements but we got through the site launch and we're able to sell the tickets. Another big thing is don't assume that software upgrades will be to performance improvements. We were under the assumption that the CIVI upgrade, the Uber Kart upgrade and the Drupal 7 upgrade would speed things up but that turned out to not be the case. Another good tip for testing is know what your target is and question if that's really matching your real performance. We kind of struggle a little bit to pin down what you wanted to test but in the end I think we did a pretty accurate job of matching what real world performance needed to hit. So I'm turning this over for Bridget for a bit more on our collaboration. So let's go back to the title of this webinar. It's riding tandem with your client. So when two organizations work together on a project it typically isn't what you picture on a riding a tandem bike where you're on the same frame. You're going clearly the same direction easily. It's a little bit more like this. There's a lot more moving parts especially in a project like this where you're overhauling a business critical site with a lot of disparate and very passionate users under budget constraints with a lot of ambiguity. We also had a lot of critical staff turnover during this project so it required a lot of coordination. So building a close relationship between Format and Cascade wasn't a luxury. It was really critical to the project's success. So I'm going to dive a little bit into what we did to build that. First we worked as much as we could as one team. One of the concrete steps we took to make that happen was we co-located a lot. Tim and Alan from Cascade and Cascade's communication lead for the project came out to Form 1 offices especially early on in the project when we were defining what the IA and the workflows were going to be on the site. We, Andrew, Sten, I, and some other folks from Form 1 went to Cascade's office especially towards the end of the project. We were there two days a week all day and that really got us immediate direct feedback, a much deeper understanding of Cascade as an organization and resiliency through those transitions I mentioned. And it also made sure that Cascade got a greater visibility to the Form 1 process on the project. It kept us all working together very clearly. So this picture I'm showing you is from the release day which was at Cascade's office. As Sten mentioned it took over eight hours just to do the upgrades and deploy the code. From left to right here you can see Leah who's testing and updating content, Kim who's testing and providing business logic expertise, feedback on how things are working, me doing some testing, handling communications with some remote folks involved in the release, Alan and Chris and then Andrew at the far right who are doing technical support, bug fixes, tweaks as needed, Sten who's applying and driving the release, and Kim on the right who's doing everything under the sun coordinating with other stakeholders at Cascade. And it really didn't matter that about half these folks are from Cascade and half were from Form 1. Having everyone in that same room meant that we could detect and respond to problems immediately. We could lift the release steps on the board and cross them off as we walked through them. We could diagram issues and diagram the servers and the URL names that we needed to apply when and how those were going to work during a release. This type of coordination on site made a big difference and it was true during the development process as well. In terms of co-locating, we didn't just collocate physically, one of the tools we used to work with remote folks within Form 1 is chat rooms, this is hip chat for example. And we had Tim and Alan as I mentioned in the same project chat room with the tech team because it's so much more efficient when Tim can just ping the whole tech team directly with an urgent bug or when there's critical questions coming up or Andrew and Sten can ask Tim directly for clarifications on requirements. It's a luxury we could afford because Tim and Alan are both very tech savvy, super reasonable and this just helped a lot with the efficiency of the project. This also paired well with another unique collaboration that we had on this project which actually came out of the challenge. One item in the original scope which was this daily rides functionality turned out to be much, much bigger than we estimated once we dug into it. There was no way it was going to fit into scope once we really understood the complexity and size of this feature set. But Sten turned this actually into a great opportunity because Cascade had the goal to be more self-sufficient and Alan, who I've mentioned from Cascade, wanted to develop some Drupal expertise himself. So Cascade lent Alan to the project team to develop the daily rides functionality under Sten's guidance. He came and worked from the Form 1 office one day a week and really dug into building out this whole feature set which meant that Cascade built up this really hands-on technical expertise with the site. Form 1 got better understanding of Cascade and we got more features built in time for the release. That's Alan right there and that's the daily rides functionality that got built out. Don't underestimate also what getting out and experiencing your clients business can do. For this, this was natural and actually a really great perk of the project. This is a picture from riding the STP. Andrew, Sten, I, and Namho from Form 1 all went and rode on this which is the biggest Cascade event population-wise of the year. We're bike enthusiasts already so it's a real treat to be like an insider but it also helps to understand at a much more concrete level what Cascade does, who they serve, and that's the point of all of this, the helping better service cyclists. So in the end what this project did is go from this amalgam of systems on different web properties, messy custom code, multiple databases to this responses coherent Drupal 7 site which was very well received. This is a comment from the Seattle bike blog which is not related to Cascade saying that the new website is super fancy, you can actually find stuff. And as Andrew mentioned there are those peaks a couple days during the year when the site just gets hammered. At the peak we saw over a thousand simultaneous active users and processed 156 orders in six minutes. And while the site slowed down because we tested it and made those improvements tweaks to the server size, etc, it held up. And in the end what all of that means that Cascade now has a stronger platform for reaching the bicyclists that they support, teach, and advocate for. So more kids can grow up biking in a safe supportive city. Thanks. Any questions? Great thanks guys for asking or participating in this. Do we have any questions from anyone? I saw a comment. I see one in there from Yannick. It says, you mentioned using the Migrate D2D module to help with migrating content. How did you handle migrating views? Did you have to recreate those from scratch? That's a great question. So we rebuilt, actually their initial site did not have that many views on it very few. And in the redesign of the website the content and specifically the content listings changed enough to where we rebuilt the views that we needed from scratch. So we did not migrate views. And the Migrate module does not support migrating views or other kinds of structural content in Drupal. It's primarily for migrating non-structural content like nodes, users, taxonomies. Does that answer your question? Great thanks Andrew. As a reminder to you folks if you see the control panel on the side of your screen you can ask questions right through that box and our team is waiting to answer them. Sten, I wonder if you could go into a little more detail on what happened during the Uber Sprint? What that kind of broke down to? Sure that's a great question. So the Uber Sprint there were three or four basically large projects in it or pieces to it. Upgrading Drupal, upgrading CVCRM, upgrading UberCard, and then upgrading the 15 modules. And so we started first with Drupal. It was actually sorry Drupal and UberCard and seeing if we could upgrade those. So we used Drupal's built-in updates.php functionality and we basically spun off a test environment and I believe on the first attempt we were able to successfully update both Drupal and UberCard and bring all the data over. I think we did run into a few snags like there are something like 50,000 users, Drupal user accounts or 60,000 user accounts and I forget how many total orders but a lot and that's one of the reasons why the upgrade process took eight hours because it took just Drupal and UberCard that long to work through converting all of the users and all of the old orders. But we were able to take care of the Drupal and UberCard upgrades fairly quickly. Then we turned to the CVCRM upgrade. That was a little bit hairier because the older version of CVCRM that they had was 3.15. It was quite old and it actually was it wasn't set up quite correctly. It looked like it had it couldn't be directly upgraded. So that was another reason why we had a lot of manual steps was we had to make a number of manual database changes during the upgrade process. That was quite a pain. But once we figured out the CVCRM upgrade then the remaining big unknown was figuring out all of the custom, sorry, upgrading all of the custom modules. The approach we took there was Andrew and I and that really constituted the bulk of the Uber Sprint. We created a backlog, had all the custom modules in there and Andrew and I locked ourselves in a room, put them up on a whiteboard and divvied them up and went through them one by one. And our approach was we knew the rough functionality that each module was responsible for and so we had kind of a list of basic test cases that we used to validate whether our porting efforts were working. So we just went through them one by one, converted the syntax to Drupal 7 as best we could, ran through tests to see if it was working as best we could. And if things looked good then we turned it over to Cascade who then developed a much more detailed testing script of workflows. And by script I mean basically a list of test cases to manually run through and see if things were working as they should. And then they would file bugs and we would respond to them. But it was basically just go through each custom module one by one and get it working in Drupal 7. Does that answer your question about the basic workflow? Great. Thanks, Ben. That was awesome. Another question that came in here, what was the rough let's see, what was the rough project budget? Did you have to adjust during the project what was the budgeting process like? How would you like to answer that? You may not want to give any specific numbers but just kind of talk about how the process moved along. That is Tim from Cascade all into that one. So we had a fixed budget and a pretty reasonable sum or a sizable sum. And as we went through the project and did a pretty deep discovery scope increased once we found out the daily rides program required a lot more work. But then we had someone inside from Cascade Allen come in to tackle a lot of that work. As the project went on we found out that Drupal Commerce wasn't going to work. We were going to have to use UberCart still. Some of the time that we spent going towards the Drupal Commerce solution meant that we couldn't spend it doing other things. So we were all really ruthless as a team to focus on the minimum viable product what we needed at its core to have a highly functioning e-commerce website where 80% of our revenue comes through. So the Form 1 team in Cascade had to make some tough decisions about what was going to be in scope or not. But at the end of the day we got everything that we needed done and ended up in a great result. Excellent, thanks. Here's another question from Joshua. What was the major hurdle preventing you from going to Drupal Commerce? This is Stan. I can talk to that one. So there were a couple of big hurdles. I would say the number one hurdle was, well actually there were two. One was the volume of custom code. Cascade's website was built quite a while ago and a lot of that custom code was the glue, syncing data and connecting UberCart with CiviCRM, Drupal, and then also WebForm. WebForm was used to collect a bunch of event-specific information for each participant that registered. For example, someone signing up for a long bike ride from Seattle to Portland, we needed to know what T-shirt size we wanted. That information was collected inside of WebForm, but then this may be too much detail, there was custom code in there that added that information into CiviCRM reports. So there was just a ton of really complex, undocumented logic that was tightly intertwined with UberCart and CiviCRM. So switching to Drupal Commerce we realized would have meant untangling all that code, teasing out all that undocumented business logic. And so there was a tremendous amount of risk there that we didn't have time to absorb. The other challenge that we faced with potentially switching to Drupal Commerce was it would have meant additional UI work for designing new workflows and retraining Cascade staff on managing the backend orders, order fulfillment, etc. Great, thank you. Here's another question that came in. Do you know of a way to migrate views? That's a good question. I'm assuming that's from one Drupal site to another Drupal site? I don't have that information, but go ahead and answer both. Okay, if you're migrating views from one Drupal site to another, views actually have an ability. You can export views from within the views administrative interface. So if you're on Drupal 7 and you go to structure views and then select the view that you would like to move to another site, one of the tabs available to you is export, and then you can copy the code and then on the destination site, if you go into structure and views and select import, you can then paste that code in and import the view. Another option is using features. The features module is a great way to capture structural content in Drupal, for example views or panel pages or context, into module code. Then you can move that module or feature that you've created between sites. That's another great way to move structural content like views around. Let me know if that answers your question or if you have something different in mind. Okay, great. Here's a question from Laurie. What role did CVCRM play in the new site? So the CVCRM is there, that's a great question. So CVCRM is the database, and Tim might jump in here if I don't, I think he's got a better handle on it than I do, but it captures all of Cascade's engagement with all of their membership. The history of all their event participation, the history of all donations they've made, the relationships between their members, so like who's in what family, what classes they've participated in, so it's a great way for Cascade to dive in and really understand their membership. Okay, anything to add there? No, it's been captured it well. It's our customer relationship management system where we try to track everything we can about the 60,000 users that use our website, participate in our bicycle rides or donate for the cause, take action politically to write their legislator to advocate for safer streets. We try to keep everything in there so we can continue to build upon these relationships we have been for 40 years. Sure, that's where all of your member intelligence is, so that's super important. So another question that came in here, what project management issue tracking tools did you use for this project? This is Bridget, we primarily use Redline, which like any project management system is the worst project management system out there, unlike other than all the others. I think it's Churchill. I can't correct it. We use Trello for this project. Sorry, thank you for breaking me. We use Trello for task tracking, for bug tracking, for tracking everything augmented of course with meetings and email and as you saw a hip chat, the chat room. Actually it worked out really well because we started off using that just for the project and it evolved quite a bit over the course of the project. It ended up now in this backlog tool that Tim now owns and has customized to track incoming issues from a variety of different people, whether they're content changes or bugs or feature improvements, prioritize them, track them through the process, how they've been QA, stuff like that. Yeah, Trello was such an easy to learn how to use tool that we took a lot of our staff that were maybe not the most technical but were able to use the features it had to create their own issues and we had a lot of our staff being able to help me track bugs and priorities and reprioritize what was the most important thing to fix next. We took the opportunity to build it into something that we use still today to track technical issues on our web properties. One really handy tip for using Trello for managing Scrum projects, there's a great Google Chrome extension called Scrum for Trello, which allows you to, through the UI, assign story points to cards on your Trello board and then it will tell you how many total story points you have in any one column. So it adds some Scrum features to Trello for you. Great, that's a good tip. A couple questions here on the CRM. Any tips for handling contact management and syncing them effectively between Drupal and CVCRM? Did you have to do a lot of cleanup of contacts as you upgraded everything? Do you have any tips on cleaning up contacts before, during, or after an upgrade like this? Yeah, they stayed the same. We enter a fraction of the people who maybe donate at our bike to work breakfast into our CVCRM system that weren't necessarily front-end web users of the Drupal website, but everyone that had created a user account on the Drupal website had automatically created for themselves a CV contact record. So, CV had a few more thousand people in it than Drupal did, but we kept it straight across the board. We didn't do any cleaning up or removing or adding. One thing I just remembered is that one thing we did struggle with before the project and I think Cascade has a process in place for is dealing with duplicate users. Duplicates arise for a number of reasons, but either because at different points in time when they have contact with Cascade, maybe they misspell their name, or they don't report their birthday one time and do report it later, and so the records don't necessarily get matched up within CVCRM. One of the ways we tried to mitigate the creation of new duplicate records in CVCRM this time was by, during the user registration process, we require users to enter their first name, their last name, and their birthday, and we treat that as a unique person or contact. And so if someone tries to register on the site, even if they've already registered before, if they enter in a, you know, the name and birthday that already exists in the system, CVCRM will not create a new record for them that will attach them to the existing record. Great. Another question about CVCRM, what element of CVCRM are you using for the advocacy aspect for contacting legislators? While we track some of those interactions on the advocacy level for the community and our legislators, we use a separate tool called CVCRM, excuse me, which is called Salsa, SalsaLabs.org, I think, and it's an email platform like MailChimp that will write customized letters to legislators based on the user's zip code to find it in the right district, and that does have a module to tie in with CV, but we didn't go so far as to tie Salsa and CV as closely together as we could have. Gotcha, great. And you may have already answered this question with some of the other ones, but I'll ask it anyway. Was the CVCRM database shared with Drupal, and did that make the upgrade easier or harder? That's a great question. So the CVCRM tables were stored inside of the Drupal database, so they were all inside both the Drupal tables and the CVCRM tables were all in one database. And to your question of did it make it easier or harder, that's a really good question. Ideally, I wanted to split the two, but a lot of the custom code and some of the custom reporting in the system was built out in a way that it required all of the tables to be in the same database. So again, we haven't done any further investigation into that, so that's what's the most ideal setup. But I believe if I remember right on CVCRM's website, they do encourage you to have, don't quote me on this, but I think they encourage you to have them in separate databases. So in the future that is something that we would like to look into. Excellent, thanks, Dan. So I've come to the end of the questions today. If anybody has any additional questions, feel free to contact our presenters. You can contact us through the forum one website, and you can also find our presenter information on the website profiles for all of our great speakers today. You'll also notice that we have put up the link to our slideshare and YouTube channels, so we'll make things available on those channels as well, and the Drupal Association is also making the recording available on their website. So I'm going to hand it back over to Lauren at this time, and she's going to wrap things up, and thank everybody for attending. And on behalf of forum one and Cascade, thank you so much everybody for attending and having such excellent questions. You've really made this a wonderful event, so thank you for being so involved and a participatory. Lauren? Thank you. I'm sorry? Just before we move on, I don't know if we actually mentioned the URL for Cascade's website. It's cascade.org, so if you want to check out the website itself, it's cascade.org. Thank you. Sorry, Lauren. Go ahead. No, that's great. If you can change it to the next slide. I wanted to thank Cascade and forum one for joining us. It was a really fantastic subject and really innovative and engaging for someone new to the Drupal community and someone I'm sure that's been very engaged. So thank you guys for putting together such a great presentation. I just wanted to end with a little bit of a reminder that helping us fund more scholarships, grants, servers, all of the programs that help you can become an organization member, an individual member, and the link is down at the bottom. It always helps support the program and the project and we really appreciate that. Next slide, please. And just a reminder again, if you missed it at the beginning, our upcoming events, we have Drupal