Whether due to an inexperienced prior vendor, a severe security incursion, or both, a sufficiently broken Drupal site is almost impossible to work with. When your site is not in a known good state, the simplest bug report or functionality request can be impossible to resolve. The entire code base and database require a thorough audit and repair before your site can be deployed.

The good news is that you can recover from this situation! This talk will describe the process used to recover sites with no filesystem or database backups after a Drupalgeddon infiltration, and the process used to rescue a site containing multiple major unsupported core patches.

This talk will also briefly mention the related project management difficulties associated with having inherited a completely broken site, in particular one belonging to an external client.

This talk is targeted at anyone who fears they may someday be responsible for fixing a horribly broken Drupal site in production. It assumes a basic working knowledge of the Unix command line, patches, and server security audits (or an interest in learning about them).

If time allows, this session will include a question and answer period and discussion of related problems seen by session attendees.

Slides: https://docs.google.com/presentation/d/1e0XnJRHJh8gDQjHYht_qYsFHiX2AEl5O3emRPAh-IV0/edit