|Tips on updating to new look website|
things to look out for!
| 10:01 pm on Apr 21, 2012 (gmt 0)|
I'm about to change the entire look of my site, which is not any cms, it is built on php and mysql. It was easier to create a whole new html template with a newer css.
Now I need to copy and paste the entire site into the public_html folder.
Are there anythings to consider, ie block robots, force revalidate so old css is not cached etc
this is a good resource but not comprehensive enough [rainbodesign.com ]
Just wanted your thoughts and/or experiences.
| 4:25 am on Apr 22, 2012 (gmt 0)|
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!
| 7:20 pm on Apr 22, 2012 (gmt 0)|
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?
| 7:52 pm on Apr 22, 2012 (gmt 0)|
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.
| 10:20 pm on Apr 22, 2012 (gmt 0)|
|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.
| 12:29 am on Apr 23, 2012 (gmt 0)|
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?
| 12:54 am on Apr 23, 2012 (gmt 0)|
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?
| 4:24 pm on Apr 23, 2012 (gmt 0)|
In reference to caching: typical cachebusting by appending a query string to it
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,
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." :-)
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.
| 7:27 pm on Apr 23, 2012 (gmt 0)|
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!