 All right, hi everyone. Welcome to Taming the Beast, a practical guide for taking over a Drupal project. All right, so first, hi there. I'm Matthew. I work at Symmetris. I've been with Drupal since 2010. I'm passionate about technology, science in general, and I would say I'm a cautious optimist. So I try to see the good side of everything, but I pay myself. All right, then I work with Symmetris here in Montreal. So what's what's the story here? Why are we talking about the Beast? So you have your guy, your business guy, the business development doing sale at your company that bars into your office saying, good news guys, we have a new client. He wants us to maintain his current website and he wants us to add new features. And then you have your typical Drupal list, your typical developer is here. Max Sim, that first, what he's thinking is, man, I love a bit of new stuff. I don't like to take over other people's website. I don't want to do cleanup. I don't want to fix bugs that I haven't introduced myself. So it's not too enthusiast about the project. And then the words starts. What's in the box? So when we open the hood of a new website, this is where we uncover the Beast. So the Beast is the analogy for what you're picking up from a previous previous provider for your clients and you're never sure what you're gonna see up in the box. So what does it mean for you? It means maybe the code is 30 versions behind. Maybe the core is hacked, some patches were applied, but not documented. Maybe the application sends emails to clients on every action. When you update a node, when you run Tron, maybe everyone receives an email and you have no way to know about it. Maybe configuration are unmanaged. When I say only, you remember Drupal 7 features, maybe some stuff are in code, maybe some stuff are not. Maybe configuration are not managed at all. Maybe deployment is as it is, so you cross your finger each time you push something to production. And what it means for the clients, it means that maybe the initial core updates and control updates you're gonna do on the website will cost them thousands of dollars because you don't know what's in the box. Maybe in the process the site went down 10 times, even for a short period, that could mean something very fine. Maybe content was lost, maybe worse, maybe they lost customer during that process. So it can mean that first improvement of the website arrives 20 weeks later. So the time to market may be very low because you don't know what's in the box. So you understand that it's all about fear. And what I'm gonna talk about today, I'm gonna talk about managing fear. And I think that's the one thing we wanna do when we pick up someone else project. We wanna make sure that we don't leave that fear. We wanna manage our own fears and we wanna manage the client's fears. Because maybe if you left from a previous provider, maybe that's because you have a bad relationship with it. Alright, let's breathe. So now that we went over the hours that we can find in the box, let's see what we can do to mitigate that. It's all going to be okay, I promise you. You don't know why and how it got like that. You don't know why that Drupal website you inherited is as bad as it is. Maybe it's not, maybe it's just little stuff that downs you, but you don't know why it is like that. You do know that you need to find a path forward. I'm gonna help you get there. So it all starts with the work estimate. I know that there was a talk just before me in that same room about estimating work. Often we're good at estimating new projects, new websites, the ones that we will build from the ground up. We're not necessarily so good to estimate the work involved in taking over a new and existing project. So here's an alternative scenario. Julien, our business guy, wants everything for next week because it's what he talked about with the clients. And of course, Julien is a real person at our company and is more sensible than this. He won't promise stuff like that, but it's for the sake of the argument. And Max, again, our enthusiasm for this, only one requirement or two. You first need to understand what he is taking over and then he needs a fully functional and safe local and test environment. He wants to make sure that everything is going to do from now on, he's able to do it locally on his own computer in a safe space and to deploy it on a test environment that is sensible with what the client has in production. In reality, what he wants is comfort. He wants to walk away from that fear of every new thing, every little CSS adjustment he is going to deploy in production will break the whole site. You want to live that comfort. Let's see how we can do that. Alright, first step, hand-down documentation. You are on a mission to find everything you can put your hands on. It could be an RFP request for proposal. So in that original document, you are going to find maybe API integration that you didn't think was in the project. You can find automation that you didn't think was in the project. You want to see if the client or its past provider has functional or technical documentation about the product, your and everything. You want to see if the client has a backlog of bug fixes to address and maybe the old provider as well. Original repositories. So if the old provider is not enough to give you the .git folder of their previous project, it could help you understand the journey you went through. And then you want to understand what's going on with the whole project, not only the technical things but the whole project. So you want to know who are the stakeholders of that website who uses it. You want to understand the digital environment of the project so you are getting a Drupal website. What you don't know is there is CRM that connects to that Drupal website. Is there any automation that includes more than one application? Do the client has 10 other providers working on different websites? Do the client have processes that go through all their different applications? So to see the digital environment as a whole gives you information about what the site should do or should not do. And you want to know how governance works for that website. And this is really important. Write everything down, write the telephone numbers of who to contact if the server goes down. If the CRM to which content is synced, if the firewall of the CRM starts blocking the Drupal application. You want to know who to call if you have a problem with the DNS zone. Maybe you're not managing it. Maybe even the client, I've lost the email used to register the domain name. That's something that can happen. And maybe the client forgot to pay the bill for the domain name. That's actually already happened with us. So the client site was done. And after a couple, I would say maybe minutes or hours of troubleshooting. We found out that the problem was a bill that was not paid and reminders that were ignored by the client. Because he lost his email for registration. So you want to have a list of phone number and people to call and understand who manages what. All right, now about the technical environment. DNS zones. Who manages it? What's in it? Is there any MX record linked to the main domain name you're working with? Is there any subdomains that are registered to IPs that nobody has any ID what it is? And you fall on a white screen when you visit them. So you kind of have to dig for this information. And often the client will have no ID at all of what it is. So you have to find a technical person that you can go through to understand everything about that. Hosting company. So who's hosting the website, what kind of infrastructure it's using. What type of infrastructure and the service level of everything to that hosting company. So maybe everything is on let's say an infrastructure as a service at Amazon. And you're hired to maintain the Drupal application. But they have no one to maintain the server itself. So do you need the system in? And also take care of this. Did you cost those hours to work on the server? Do the client know what's the difference between infrastructure as a service and platform as a service? So is everything managed on that application? You want to know software and versions that are used to run your Drupal application because you want to reproduce that on your local environment. You want to reproduce this on your testing environment. And you want to know every external integration and dependencies for the website. Is there any software installed on the server that you want to replicate on your site? It could be a solar server. It could be some PHP plugins to crawl through PDF or through Word documents. So each integration and dependency must be addressed. And is there any bail step to kind of assemble that project? So we can think of obviously composing, installing everything, but also for the front end, are there any tasks that were used for the theme? I'm thinking about SAS and less. I once worked on a project where we didn't have access to the previous provider and we only had compiled CSS. So where do you go from here if you don't have the SAS file? So you want to look for all those things when you're looking at taking over a new website. And then the application, the beast. You want to see is there any automation in the website? So you're looking for rules, workflow, country modules or custom modules that were built to automate stuff linked to the client processes. You could look at hooks. So yeah, rules, hooks, mail. So for every Drupal hooks there could be an automation linked to that. So if on the hook entity insert there's some funny business going on there for the client's internal processes. You want to look for that when you kind of do an audit of the code. Then APIs. You want to find every API integration with either enterprise software that exists out there. We're thinking about Salesforce CRM, maybe Microsoft Dynamics, etc. But also custom APIs that were built by maybe the client's technical team. And often you will iterate the mandate from let's say the marketing side of the client and they did not really talk to their IT guys and maybe there's an integration with their ERP in-house. So you want to look for those integration. It could be also commerce integration. So make sure you know what is the payment platform that the client uses. Can you have a sandbox at that payment platform, libraries that could be used. And here my best advice is to kind of build a set of keywords that you want to look for when you look through the code. So at one point hopefully before you install anything you're going to try to look through the custom code, custom modules and the theme and you want to look for a bunch of keywords. So you can even build a script with those keywords. So I'm thinking statually to external APIs. So maybe every looks and mail, double mail that are in custom modules you want to pick those up and see, understand when they're fired and why they're fired. For API integration you could build a list of keyword like SOAP, JSON. You could look at Drupal HTTP request that is the helper to access external links. So you try to build a list of keywords that you can crawl through the site. I tend to include as well enterprise software in that list of keywords. So Salesforce is an example, Dynamics is an example. So you really want to kind of statically assess the code before installing it. And then the last thing to take into account of the application is user generated content. So if you have to move around databases, if you have to change a hosting company, if you want to move the infrastructure you want to understand what is the user generated content and what does it mean if you have to have some content freeze on the website because you're changing infrastructure. And the most vicious one in that category is web form because a client with only web form on their website will always tell you, oh no, it's just static content. We are the only one touching the content, etc. But they have like two contact forms that are linked to business processes that they don't take into account when we're thinking user generated content. All right, now you can install the site locally. You've gathered documentation, you went through the code, you asked around for API integration for business processes and now you're ready to install the site locally. Maybe it's a good idea before you think the first PHP page on that site to disconnect from the network. Why? You asked me. So that's a true story, an unfortunate one, but it's a true one. So we did all those steps, we kind of add a bunch of documentation, we went through. But there's one thing we didn't catch is that emails were sent using Chrome and they were not sent using the PHP mailer, they were sent connecting to an external API. So once the site was installed locally, 10,000 emails were sent to the client's clients telling them that a new account was created for them on the localhost website. Everyone clicked on the blank page and they received hundreds of emails of oh your email didn't work, etc. So even if you use something like mail log that I'm going to talk about a little bit later, maybe the first time you run the PHP on the website, disconnect from the network just to see what's going on, are there some errors that show up, etc. So can you make the website work locally and can you make it work without being connected to your network? So that would be great news, that would mean that there's no kind of script blocking integration with external integrations. Can you reproduce entirely your collection environment locally? That would be great. And can you cache any potentially dangerous external integration before they trigger locally or on your test servers? Things you want to worry about, API integration. So then again back to my example, if a web service is called at a custom API built by your client maybe, the name of that API will not be very eloquent and you won't see that this particular API will send 10,000 emails. And you can cache everything that Drupal sent on the local installation using mail log if we routes every outgoing emails to kind of a web application where you can see where it's from, where it's going, etc. There's a doctor container for mail log. Even if the mail is sent by send grid? No. That's why you want to do this. That's why you want to cache any potential dangerous integration. So yeah, so SMTP modules and VIN modules and Drupal, all of those external mail integration using country modules in Drupal. It's a good thing to, when you're going through the country modules, country module if there's one module that you don't know what it's doing just Google it, go see in Drupal.org, what's that module, what's it doing? You can put a statement in your settings about local.php which will force Drupal to always try and use the simple phpmailer which will force it to all go through the mail log. I still disconnect though, just in case. Great, that's a good point. So would it be like settings, so the settings over right, the basic settings over right? How people always use the simple language and always goes through mail log where it's supposed to. That's a great tip. All right, now you want to look at non-functional requirements. So you've got it installed. Yay, it works, but what are other things you want to look for? So in a position of functional requirements which would be when you click here this happens and non-functional requirements is everything else on your website. So first security is everything up to date. Recoverability, so this is a big one because you're in everything, a project from a client and you don't know if the client has backups, you don't know if the client has a strategy to recover his or her website when something happens. Maybe they could be hacked, maybe they could do something wrong themselves using the onion panel. So you want to make sure that the client has a strategy to recover the website. If they don't have one, maybe it's your job to tell them to put something in place. So security, recoverability, do the man have a plan for the same things. Interrepairability, so also this one is often overlooked and you kind of have stuff to do last minute to fix it. So let's say the Drupal website needs to talk to an internal ERP within API integration and that internal ERP is beyond firewall and that firewall whitelist IP that they connect to it. So maybe you don't have this information and you learn about that five minutes before deploying the one function that the client was hoping for. So you want to go through this and even if you got the opportunities to work with that client from the let's say marketing division, you want to make sure that you have someone from IT at one point to go over through this stuff. The component process, so do they already have one? Do you have to integrate an existing component process or do you work to download from scratch or to suggest them one? Alright, two full modules that can help you kind of edit the security of Drupal. Security reviews to see is there any unsecured configuration on your installation and the module hack that will give you a diff of every country module to see if a patch was applied without you knowing it. I think security review, there's no Drupal 8 release for now. But if you enter the website, it's probably going to be a Drupal 7. Unless something went really bad with the last provider. Alright, can you go further than that? Sure, you can build a do not list. So that could be really helpful for anyone who starts working with the project. Maybe you haven't secured the whole project yet and you want to make sure someone doesn't send those 10,000 emails. So it's always useful to know what you should not do. It could be stuff as simple as do not use the Drupal backup and migrate to export it at a base because x, y, z. Do not touch that module. It could be a simple do not list for the time you secure the application. You could build a test plan. So what are the steps you want to take to make sure once you deploy that snippet of CSS you're not breaking the whole system. I'm using CSS as an example. I understand that it's not really functional but it would be crazy if you just deploy one line of CSS. You want to have a test plan and you want to make the application your own. You want to really go into the application and remove every mytestmodule.bck.2015.module file. All those artifacts that you don't know how or why they exist on the website. And you don't want to touch them because it's not yours. This is the time to make it yours and to delete that file. I promise you this is a great feeling to get rid of those artifacts. And maybe you want to go over the risk mitigation strategy that you have in place with the client. You want your client to understand that the work you're doing, the steps you take to make yourself safe and to make your clients safe are worth the buck they're investing in your work. And this is crucial and often as developers we don't want to put on work that's not immediately observable by the client. And we want that every hour that we spend is added value to the client. And yes they will get their new carousel. Yes they will get their new feature but risk mitigation is value. You are bringing this value to your client. And then remember that compassion and transparency wins over fear. You want to be compassionate and transparent with the client. You want to be there for their fears. You want to be able to listen to them. You want to be able to tell them to wait for that deployment because they are taking a big risk to deploy this Friday at 5pm on a website that you've never touched before. You want to be compassionate with them and to understand where their fear comes from. You want to be compassionate with the previous team. The one that built the monster, the one that built the beast. You don't know what were the conditions in which this beast was put into life. You don't know the friction they had. You don't know if it was given to someone who had never worked with Drupal before. You don't know if the client maybe was cheap at first and they didn't understand the work and the hours that we need to put in a website to make it stable and secure. So you don't want to start using those guys as your scapegoats. You want to be compassionate with them because you've been in that situation before. You want to be compassionate with yourself. You don't want to put yourself in a position where you're going to fail. You don't want to set yourself for failure. That's the big thing because we always want to please the client. We want quick wins. We want the client to be happy with the service we provide. But if you put yourself in a position or if you put your developers in a position where they're going to fail, you're causing harm and suffering to your developers, to your clients and maybe to the end user of the client. So if you're interested about this idea of compassion in tech, there's a great talk by April Winslow about reducing suffering in tech. And how compassion can be used to reduce suffering. I encourage you to hit this. Alright, so how do you manage fear? The first question of this talk. So you estimate what it takes to be comfortable working on the system. So all of these activities that you can do to make sure that when you're going to deploy that line of CSS that will take you 15 minutes to write and 10 seconds to deploy. You want to share that this 15 minutes you've put in all the hours you needed to make sure you're comfortable to deploy it without any fear. And then you want to mitigate risks using all the strategies I've explained before. And last, you want to stay compassionate and transparent with your clients, with yourself and with the previous team. And now you're a happy little doggy. Alright, any questions, comments and thoughts? Do you have any tips for the tool to actually document everything that you install? The tools of developer are comfortable opening and going through the points for everything technical. That's a good place. So if you have a project management tool often there's a wiki that comes with it. So either you use Gira, Confluence, etc. Or in-house we use Redline. In the wiki part we have kind of a structure to document those information. And that's the first thing that we show to every employee that comes as an interest is what's that structure, what pages you've got to read before entering in a project, etc. So that's a little bit different than let's say a deployment process where you can give permission to only one person to deploy the application in production. So there you're safe because it's going to be your, I don't know, your main developer on the project. That's different because you want to make sure that even the people who install it locally understand the risk they're exposed to. Especially if you haven't secured yet the application. So down the line you're going to, let's say, separate configuration. You're going to make sure that when it's unsolicly it's not connecting to any dangerous API, etc. But for the time that you're not safe you want to make sure that everyone goes through those static documentation pages So one of the things that I haven't dealt into is you've got to solve each of these problems individually. So let's say you found a list of problems with that site when you install locally it does this and that, etc. So at each step of the way you want to solve those problems before starting deploying stuff to the production environment. In real life the thing is the client will always try to nudge you one way. So oh yeah but can we get this done by you? So it's always, that's a good moment to inflict the client into the client and to make sure the client understands the risk. And maybe he is comfortable with taking this risk but let's make it their decision and not yours. And if you succeed convincing the client that the risk they're taking is theirs, at one point you're all good because the client is an adult and he can go his own way. Alright, I hope you enjoyed the talk. Thank you.