Lots of useful posts about how to deal with this.
Without trying to repeat what everyone else has said:
- Get a copy of the prod environment running. It can be a virtual machine, or another real machine. But you need to be God on it. If the prod database is on another box, you'll need a dev version, too.
- Throw it all into version control. On another box. One that is backed up at least weekly.
- Make sure you know how branching works in your version control application. You'll probably need it.
- Get the prod server locked down. You don't want any further changes made to it that don't come out of version control.
- Create instructions for releasing code from version control to the prod server. The smallest unit of releasable change should be the whole code base.
The next steps depend on how attached to it the users are. If it can't be changed to much for whatever reason, you will need a progressive approach. If development and maintenance still needs to happen, then this is probably your only option. Remember to use that branching feature to separate such mods away from your re-writing efforts.
To put sense into the structure, you have to basically create a new structure alongside what's there. A new DB handler is usually a good place to start, included from a generic include file that every page should load. The goal here is to create a minimal include structure that can be expanded later without telling every page to load additional files.
Now you need to start moving functionality over to your new include files. You will need a way to have several files open at once, such as a multi-file editor, or screen+vi (or emacs). Start with utility functions and code-blocks that are repeated in various places. Try not to get distracted into fixing a lot at once. Some types of problems are going to have to just move places as other problems get fixed. You'll come back to them later.
Don't feel you need to add a third-party framework. Adding such a thing quickly leads to a complete re-write. At this point, this will be a whole lot more work than just taming its include structure. So sort that out first.
As you move functionality over, you will need to have files use your new include file. The first few files you do this for you will be chasing conflicts for a while. It will feel disheartening and pointless but this is probably the hardest part. After a few files, it will get easier. There will be times when you can migrate half-a-dozen pages to the new include files by replacing a dozen includes with just one. The flip side of that action is that there will be files you can just delete.
If you stick at it, you will eventually get to the point where all the include files are the ones you've written and you'll be across the whole include layout. By that point, it will be significantly easier to do much more invasive changes, like putting in a third-party framework.
