We've recently attracted new clients that came with Drupal sites already in tow. New clients is always a good thing, especially when they come with a fondness for Drupal, but it isn't all peaches and cream. We've found the transition hasn't always been as smooth as we'd expect. Here's a list of some common gotchas to look out for when inheriting a Drupal site from another developer or Drupal shop.
Before quoting new functionality, upgrades, etc. ask to review the codebase directly
There's no substitute for actually digging in and directly reviewing the codebase. We strongly recommend doing this before estimating any new features, upgrades, or maintenance. Skipping this can come back to bite you later when a feature that would normally take you one hour takes seven because the previous developer hacked something to bits or built something untenable. Additionally, you'll see right off the bat whether of not the previous shop followed Drupal best practices regarding code standards, where things should live, etc. This information will speak volumes about what you're getting yourself into.
Hacked Core?! Hacked Contrib?! GRRRRRRR!
If you are able to get your hands on the codebase and a working copy of the site, do yourself a favor and install and run the Hacked module. This little gem will compare the existing core and contrib modules against their unhacked/pure counterparts. After running this, you'll see any and everywhere that has been hacked by the previous dev team. Hopefully, this reports that nothing has been hacked. If anything has been hacked, be sure to adjust your estimates accordingly and do some CYA by alerting the client.
Is the site version controlled? Preferably in Git?
All projects should be using version control. The information that a commit log offers is invaluable when inheriting a site. Assuming the commit messages are quality and concise, you can quickly gather an understanding of how the project and code grew to its current state. When debugging, troubleshooting, or otherwise trying to grok how the last dev set things up, git blame is priceless. If the project you're inheriting isn't version controlled, consider making it a requirement moving forward with your new client. This is a requirement we rigidly enforce on all of our engagements.
Hosting, SSH Access and Drush
A firm understanding of the existing hosting situation is crucial. We try to have this conversation as soon as possible to get everyone on the same page. If the existing site is hosted on cheap shared hosting without proper SSH access, we try to fix that right away. Gone are the days of FTP deployments and manual database changes. These methods are slow, painful, and risky. This is why we make it a requirement that if we're to be responsible for deployments to production, we must have SSH access with Drush and Git installed.
Features?
Is the site you're taking over not using Features to manage configuration in code? Or, if it is using Features, are they overridden? Either of these scenarios are a definite red flag. The last thing you want is to deploy a bunch of fancy new code and accidentally revert features that were previously overridden! When we inherit a site like this, the first thing we do is get all of the features modules to a default state on a dev or staging environment. This way, everyone on our team can be sure they aren't breaking things on their next features revert via Drush. drush fra -y FTW!
Basic Drupal features being overridden by custom code, modules
This one bit us just the other day. The site we inherited was (seemingly) using the basic search that comes with core. The client was trying to adjust the weight/priority of certain node types in the search and wasn't able to achieve the results they were looking for. After hours of digging and lot's of head scratching, we realized the default search page was being overridden by a custom view. DOH! The tricky part here is that there was nothing obvious about this on the default search admin panel. If it were us, we would've set some alert on that page to remind users that those settings would not be respected.
Panels vs. Context?
Panels and Context are both great modules.... err... solutions to the page building problem. Chances are the site you're inheriting is using one or both of these modules. Some site builders are rabid about one tool being better than the other. Here at CHROMATIC we use Context more often than not. It isn't a deal breaker for us, but it is definitely something to consider when taking on an existing Drupal site. Run for the hills if the site is still using the default block admin panel from D6!
Is the site running Pressflow or another Drupal distribution?
In some cases, you might be taking over a Drupal 6 site that is running Pressflow. This is crucial because it will determine how, when you update Drupal core. If the previous developer used Pressflow, you'd hope it was for a good/obvious reason but we've found instances where it wasn't obvious at first glance. Keep an eye out for this one.
Keep these gotchas in mind next time you inherit a Drupal site. It could save you loads of time and frustration! Leave us your favorite (or not so favorite) gotchas in the comments below. Happy Drupaling!
