Escaping the chains of Prometheus: or, what to do when you inherit a Frankensite

If you've been in the Drupal world for a few years, you've either come across what I'm about to describe, or you've created one of these monsters yourself (I know I have -- this talk is not about being "more perfect than thou"!).

Congratulations, you've got a new client and you've just inherited a Drupal "Frankensite" with:

• No version control
• No documentation
• Custom code in non-standard locations that makes little to no use of the Drupal API
• Non-Drupal, custom PHP code in the Drupal root
• Zero adherence to coding standards, Drupal or otherwise
• PHP code stored in the database
• Numerous errors and warnings in the logs
• Undocumented patches to core and contrib modules

In this session, we're going to help you escape your Promethean suffering [1] and outline a method for rescuing a broken Drupal site and making it whole again. (Spoiler alert: there are no quick or easy answers here.)

We’ll outline a checklist and set of tools you can use to quickly assess the state of an inherited site and figure out what needs to be fixed first. Some topics we'll cover:

• Using phpcs-security-audit and Security Review to quickly identify potential security issues
• Making use of Hacked and Site Audit to uncover configuration and code issues
• How to approach auditing the database layer of the web application
• Explaining technical debt to clients in such a way that they won't hate you
• Maintaining a zen outlook in the face of a site that challenges your will to stay in the game

Come to this session if you're tired of your liver getting eaten by an eagle every day and you want to unchain yourself from that lonely rock in the Caucasus!

Footnotes