I just went through this myself.
My number one tip is to not try and change everything on day one.
You need friends if you really want to be able to fix this thing.
You need your colleagues respect before you suggest how to change everything they've been working on for months (years?).
First, get the code under version control as soon as possible. If that's not going to be easy for you, at least start making daily backups, even if it means just zipping up the files and naming the zip file with the date. If nobody there knows about version control, buy a Pragmatic Programmer's book on CVS or SVN, and set it up yourself. The books can be read in a day, and you can be up and running quickly. If nobody else wants to use version control, you can use it yourself... then when somebody loses a file you can save the day with a copy from your repo. Sooner or later the others will see the wisdom that is version control.
Second, dive into the code as hard as you possibly can. Live it and breathe it for a month. Show the people who are there that you are going to learn their code.
Third, as you go through the code, take copious notes. Write down every thing that bothers you about the code. Just get your thoughts on paper. You can organize it later, after Month One.
Fourth, install a code profiler (such as xdebug). That'll tell you what files & functions are being called on each page, and how long each piece of code takes to run. You can use this to figure out your includes issues, and find slow bits of code. Optimize those first.
After your month of hard work, sifting through the code, and taking notes, turn your notes into a proper document. The different sections could range from security, to caching, to architecture, to whatever else is bothering you. For every criticism you make, offer a better solution, and an estimate on how long it would take to fix. This is where you get rid of all the competing javascript frameworks etc.
Revise this document as much as possible.
I cannot stress that enough.
Make sure your audience can tell you're doing it for the good of the company, not just your personal preferences.
Present it to your boss, in person.
Set-up a time to discuss it.
They could fire you for having written it. If they do, you're better off without them, because they don't want to improve, and your career will stagnate.
They might want to implement all of your recommendations. It's not likely, but it is possible. Then you'd be happy (unless your recommendations fail).
Most likely they'll want to implement a few of your recommendations, and that's better than nothing. At the very least, it'll help ease your concerns.
As for testing, setup another "virtual host" in Apache (supported on both Windows & Linux). Virtual Hosts let you run multiple sites on a single server. Most larger sites have at least 3 virtual hosts (or actual servers): dev.domain.com (for daily development), staging.domain.com (for QA people to do testing on just before a release), and www.domain.com (your production server). You should also setup dev, staging, and production versions of the database, with different logins & passwords so you don't accidentally confuse them.
An alternate solution would be to give each developer their own virtual host on the Linux server, and they can work via FTP/SCP or network share using samba.
Good luck!
