Thanks for the plug, but my article was focused on search engine issues for people who are moving their website to a new domain name. I didn't really consider the mechanical issues, but perhaps I should.

There's a wide range of possible complexity when you're talking about redesigning a site. It can be as simple as changing the template(s) and CSS file(s), or it can include massive changes to the navigation structure of the site.

Broadly speaking, I'd say if all you're doing in changing the page templates and CSS, but leaving the link structure intact, I'd suggest doing it in stages if at all possible. That is, change over one directory at a time so you can check everything without disrupting the entire site. It would be a good idea to run Xenu Link Sleuth on the site at each major step of the transition to avoid problems with broken links or missing resources. If you can't make the changeover in stages, then you might consider temporarily blocking your site from the search engines until you're certain everything went as planned. I'm sure others will have more suggestions. Good luck!

Thank you!
all my files reside in the root folder so all needs to be changed at once, their are some sub folders but they arent in need of the new template.
Ill probably stop robots and redirect all other users temporarily to another page and upload unless there are caveats?

i'd do it all at once.

personally i'd change the name of the css file, saves any caching issues and also is good practice to change the name after a major update.

Thanks

also is good practice to change the name after a major update

name of the css?

Sounds good only wondering when the page loads once new site has been updated will the response not be style.css (old one) not found? in which case the output would look quite messy right?

Please correct me if I'm wrong.

If your site is php, then surely you only have to change one line of code one time in one place to make it load a different CSS file, right?

Yes you are right. It won't look for old style sheet as the html isn't cached.
Thanks for the pointer.
Any other tips?

In reference to caching: typical cachebusting by appending a query string to it

style.css?version=1234567

will always force a download. This is true of any included resource, Javascript, images, whatever. Just change the number every time you upload.

Since this is the PHP forum, there are many PHP-focused things you can implement in a major revision. Consider every bad habit you've ever done and DON'T DO IT THIS TIME. :-) If you don't have bad habits, you wouldn't be here. Some ideas:

#1 on the list, in any way you can think of: cleanse all input. Query strings, form input, it's all the same. "mysql_real_escape_string" doesn't really sanitize, it just makes is safe for database insertion. If you're on a later version of PHP, you can make use of the sanitize functions. This is the #1 thing many coders should do and don't.

#2: Look for redundant functions and centralize them. If you're doing this,

session_start();

at the top of every single page on your site, put it in a file.

<?php include($_SERVER['DOCUMENT_ROOT'] . '/initialize.php'); ?>

As you rework, you will discover other redundant tasks that need to be in your initialization file. Put them there, do it once, when you change it, it applies everywhere. This is a concept that is not exclusive to "header and footer includes." :-)

#3: Get rid of RELATIVE paths across the board. An expansion of this is in post #4442087 in this thread [webmasterworld.com]. If you adopt this now, it's going to save headaches later. For php includes, use the full path as shown above, for in-browser resource references - images, Javascript source, CSS link, whatever - always begin the path with the leading slash. This means "start at the domain root" and follow this path to the resource.

/images/myimage.jpg

If you truly digest the link above, you'll see how important - and TIME SAVING - this is.

#4: Get rid of query string URL's. There is always a way to use mod_rewrite on 'nix servers and Isapi rewrite or the built in rewrite module on IIS 7 to avoid ugly, SO-unfriendly query strings.

#5 Proper 301's for old URL's, duplicate content elimination. Related to the above, don't just let old URL's 404. Give the m somewhere to go. You may have little or no search engine strength on these pages, but that's all the more reason to hang on to all you do have - and to not leave your visitors hanging on a useless 404 page. Don't allow your pages' strength to be divided among www and non www versions. This is discussed at great length on this board, seek it out. Google's recent attention to rel="canonical" has given people a lazy way out of doing what they should have done right in the first place, so . . . that's an option you can do if it suits you.

#6 Make use of functions: following the concept in #2, there will be many tasks, some of them that won't apply to all pages, that can easily be moved into a function (for procedural style) or a class (for OOP style.) If you're doing something more than three times on your site in exactly the same way, write a function for it, put it in your global include, and call it as you need it. For example, "get all columns of the members table where the member id is this or that." Or better yet, "Get all records of 'table x' using the unique column 'whatever' which has a value of 'Y'".

$table = MEMBERS_TBL; // defined in a constant
$rowArray = getRecord($table,'mem_id',$this_id);

... where "getRecord" is your function that makes your life 100 times easier to debug - it's only in ONE PLACE. :-)

There are probably hundreds more, but whenever I revise a site the first question I ask myself: "What can I do differently this time that I shouldn't have done last time?" I always have lots of them, and it always makes the sites easier to maintain, update, and faster in many ways.

Thank you for the excellent tips, now I will be implementing a lot of the above. I wasnt going to initially get rid of query strings from the url but now im going to, this means no more relative paths right?

Now url rewriting opens up a whole new can of worms!