Well, first things first. I've been in the situation you're in, and it sucks. I think you're on the right track with wanting to get a development environment up and running.
Development environment
This will include a Webserver / script engine / database engine stack, and an IDE most likely.
For a LAMP stack installer, I recommend using one of these:
- http://www.apachefriends.org/en/xampp-windows.html
- http://www.easyphp.org/
- http://www.nucleex.com/nucserv/
Further reading on the LAMP stack:
O'Reilly's OnLamp site
For a good PHP IDE, I recommend using one of these:
- Zend Studio
- ActiveState Komodo
- Jetbrains PhpStorm
Article on IBM's Developer site comparing several IDE's
For Source control, you can use Team Foundation Server, SVN, or Git -- just use something that you know. I would recommend getting everything in source control first (for any emergency maintenance you might have), but then plan on doing a pretty big overhaul.
The Overhaul
You mentioned that you didn't even know what files are getting used, and that they used a file naming convention as a pseudo-version-control. You might want to start overhauling there, once you have a development environment up and running. There are a few things that can help you:
- Your app customers/users
- Meticulous and organized note taking
- A good logging framework
Your customers/users are important, because it sounds like you're new to the project and they're going to know how the app should behave better than you (most likely).
Meticulous note taking is important, because you're going to be essentially re-writing any requirements / design / end-user documentation from the ground up. You need to understand the internals if you're going to do that. And if you're going to understand anything about this system, you'll need to write it down yourself (or you'd be perusing premade documentation right now instead of reading Stack Overflow) ;-)
And finally, a logging framework is important because you need to fix things, and you can't fix things that you don't know are broken. A logging framework gives you visibility into parts of the app that don't have any obvious UI. Inserting it into various parts of the app and then looking at the logs gives you a good idea of when code is executing and in what order.
You'll want to focus on capturing (on paper) how the app should work, and then slowly removing unnecessary files while trying to not break anything. Keep an eye on logs to help with debugging. Make sure your customers aren't screaming that something is broken. Make sure your notes agree with what is getting logged and what your customers are saying.
Preventing this in the future
Recheck everything back into source control. Hopefully you will have arrived at a newer, saner, better directory structure by this point.
Get a test structure in place. Even if this just means getting a basic unit test framework in place and doing some basic smoke tests after each deploy, it's better than nothing. Ideally, you should have a test engineer or a knowledgeable and trustworthy customer that can spend time testing after each deploy.
Put a deployment process in place if you grow more than one developer. Controlling change to your production environment should be your first priority. (The last thing you'd want to do is go through this again, right?) You should have a clear and simple process for moving between environment boundaries (like Dev -> Test then Test -> Production).
