HWG-News Tips Late June 2000
Taking Over Another Author's Site
HWG-News features member-submitted "tips" in each issue, in the space
between articles and announcements. These were the tips submitted for
19 June 2000
newsletter, for the following category:
Taking Over Another Author's Site
In today's job market, new web developers will often be required
to take over existing code... often when the original author(s)
are long gone. What are some methods that can help ease the pain
of having to take over existing code, cleaning it up and making
it more maintainable?
This issue's winner!
- MOST IMPORTANT: Back up the entire old site to floppy or Zip disk!
You might miss something.
- DON'T GET COCKY. Quite often a new author will flame a site design
only to find they are not insulting the author but the customer...
- DESIGN THE NEW SITE AROUND THE OLD CONCEPT. Quite often the
customer's original ideas are there, they are just too hard to find.
Look for the core concept of the original site and rework it -- not
only it will make your job easier, the customer will most likely say
"now THAT'S what I was trying to say!"
- CROSS BROWSER/PLATFORM COMPATIBILITY. Most of my redesigns are
simply because the previous author refused to believe that YES,
there are users for BOTH platforms and many browser visiting a site.
Check all your work for cross-platform and cross-browser
- ECONOMICS: Finally, recode everything to make use of common files
and CLEAN HOUSE. A neat and well-formed directory structure will
help lend to a terse and effective site.
-- Submitted by Bill Snowman <email@example.com>
Other Tips for Taking Over Another Author's Site
When you take over a website from another webmaster, make sure any code you write contains comments. Comment everything you keep from the old webmaster as well. Not only will it be easier for another person to follow what you wrote, it can help you remember what you were thinking when you wrote your own code six months ago.
-- Submitted by Ramon Campos <firstname.lastname@example.org>
If it is a contracted project, make sure you have a local copy of the
site BEFORE you make your bid. Make very sure there is no
hidden programming you will have to deal with. We have received a
few projects because the last webmaster couldn't finish the job.
This is usually due to a problem with a code in the beginning of the
process that corrupted the end product. It is no fun to reverse
engineer a site, especially when it is on your dime. Make very
sure you know exactly what your headed into before you put a
price tag on it.
-- Submitted by Joel L Compton <email@example.com>
I am kind of new to the world of web pages, but could you copy the visable
text that is on each page to a web editor, like front page or something, and
let it clean up the mess, Errr differences of opinion about how the page
should have been written? And then move any graphics in as you progress.
-- Submitted by Pan Piper<firstname.lastname@example.org>
Don't change page addresses just because you like your own page
You will lose any links already established by search engines.
-- Submitted by Joe D Williams<email@example.com>
If the site is really awful, don't try to patch the existing framework.
Strip out the usable text and any usable images and set them aside. Create
a "new site" (perhaps with CSS), then reintroduce the usable content and
images. It will be less painless in the long run, believe me.
-- Submitted by Jim Peden <firstname.lastname@example.org>
I have not normally submitted tips .. however I do have a couple of
I have had to take over several sites that were written by people who
used Front Page and Hot Metal .. It seems that every authoring tool has
its own quirks and those who are writing sites have their own way of
doing things .. If I plan to continue to keep up these sites - I
re-write (edit) the site to be closer to the way I write pages (and
charge the customer accordingly) - or - I bid to re create a new site -
it seems to be more favorable to crate a new site and sometimes could be
about the same cost as editing an old site ... as for the pain of
cleaning up code (The biggest problem seems to be dirty JAVA) - not much
eases the pain created by others.
-- Submitted by Dan <email@example.com>
When taking over another author's code,
Make a copy of the site and put it in a separate folder. Only make changes to the copy and verify it works before publishing it to the original.
Study the code and try to determine what the previous author was doing before you make changes. It helps to add border="1" to each table in order to see the layout more clearly. Use the Comments tag for instructions to yourself or to explain a specific area of the code.
-- Submitted by Joanna Wright <firstname.lastname@example.org>
A subject dear to my heart, even if I'm the person editing my own code after
many months (and I need a few moments to get re-oriented). My pet methods:
First , the basics...
 UPPER-CASE TAGS and lower-case attributes; few things are more annoying
than wading through acres of code that all looks the same. Upper-case tags and
lower-case attributes make it easier to separate one from the other.
 Progressive table indents accompanied by thorough commenting; this is
crucial to keeping track of where you are in a series of nested tables. Cells
and headers are always indented one tab stop further than their rows and
 Block tags (H1, P, BLOCKQUOTE, UL, etc.) always start on a new line,
at the same level of indent as their parent table cell. This also applies to
line breaks. List elements are indented one step further than their
 Paragraphs and lists are always closed.
 Table (WIDTH, ALIGN, BORDER, CELLPADDING) and font parameters (FACE, SIZE,
COLOR) aren't left to chance; they are always spelled out even if the page
features a style sheet.
 No extraneous spaces between lines of code (except when commenting, per
above example); I like to have as tight an overview as possible over the
sections. And no spaces between parameters and their attributes e.g.
SRC="images/nav.gif" instead of SRC = "images/nav.gif"
 Attributes are *always* quoted. This prevents some older browsers from
misinterpreting table width values expressed in precentages. It also helps
differentiate parameters from attributes. The only drawback is that if you miss
one quotation mark, the rest of the page is hosed.
 Parameters ought to be in the same order within tags e.g. TABLE WIDTH=
ALIGN= BORDER= CELLPADDING= CELLSPACING= BGCOLOR= or FONT FACE= SIZE= COLOR=
or IMG SRC= WIDTH= HEIGHT= BORDER= HSPACE= VSPACE= ALT=.
When a page is coded this way, I have a much easier time tracking down gremlins
and weird behavior. It also ensures maximum cross-browser compatibility,
IMNSHO. Unfortunately I have yet to encounter a WYSIWYG editor that delivers,
which is why I stick to my trusty WebEdit v2.0 (now four years old) for digging
into code (and making easy work of global Search and Replace!) and leave the fancy (Flash, JS)
stuff to Dreamweaver.
-- Submitted by Stanislaw Chalicki <email@example.com>
Give the site a thorough once-over to figure out the general organization.
Then while still keeping the same basic look, make gradual improvements to
the site. (i.e. Replacing yucky pixelated graphics with a sharp cleaned up
version.) That way the site isn't out of commission while you are working on
improving it, and it's not too jarring to the users who are happy with the
site the way it is. A global search-and-replace feature in your web
development software is very valuable. That way a bit of pesky code that the
original author used on every page in the site, can be searched and replaced
with one action. You'll still yearn for to do the major overhaul -- but the
site will be usable in the meantime.
-- Submitted by Diane Jackewicz <firstname.lastname@example.org>
Most of us take the attitude that we'd rather
start from scratch than take over someone
else's code, whether it be Perl or HTML. But,
if you approach it methodically, you can
separate the wheat from the chaff and develop
a site that you can be proud of.
1. DON'T assume that, necessarily, the
previous webmaster didn't do as good of a job
as you would have. Take time to learn what you can
from their work.
2. Then, of course, it is pretty much a
given that you're going to want to change some
things to fit your personal preferences. Dig
in and understand as completely as you can
what is going on before you start rearranging
the furniture. You don't want to inadvertently
cause problems by corrupting the existing
code. DO insert comments liberally throughout.
3. Build a FLOWCHART early on.
4. Categorize and define, in your own language, the modules,
sheets in the existing site so you can modify or replace them
with your own tried-and-true routines.
5. Keep a POSITIVE attitude... negativity only increases
the probability of failure, and your customer's opinion of
you will not be enhanced by your whining.
-- Submitted by Chuck Lund <email@example.com>
When taking over another author's site, plot a site map of the links to
each page. This will help you to get a feel for how the site flows for
-- Submitted by Melinda Davis <MelMD2003@juno.com>
1. Become very familar with the structure and layout of the entire site by
reading it through.
2. Make minor fixes immediately to see if a pattern of
errors occurs (e.g. the old webmaster never nested tags consistently).
3. Automate whatever corrections you can, through programming or validation
4. Avoid making major changes (e.g. new navigation structure) to the
code at the same time as fixing the original site.
5. Document everything for the person who will be there after you.
-- Submitted by Michael Clark <firstname.lastname@example.org>
Be willing to burn the website to the ground and start all over again
using site management techniques. It's often faster than trying to
repair a site with lots of problems.
If you do try to simply clean up an existing site without rebuilding,
be sure to use all the "html cleaner" utilities you can find, such as
Dreamweaver 's "Word html cleaner" and BBEdit's "PageMill Cleaner".
Run link checkers and Bobby too.
-- Submitted by Ellen Guttadauro <email@example.com>
If it's a corporate site, try to get your hands on the webmaster's
computer. You must capture the work already invested in collecting and
processing content. Even if you plan to recode from scratch, you'll need
those content files.
Avoid the extremes in the code takeover. Someone invested a lot of time
in that site, but he/she did it his/her way, not yours. Study the site
hands-on, offline, looking for includes, style sheets, logos, and other
common elements. Aggressively comment points of interest and concern in
that offline copy.
Better yet, take a job where the website is adequately staffed, and no
great mysteries result if one code jockey hits the road ...
-- Submitted by Joel E. Tucker <jt@BootUp.com>
The first three contracts I secured were internet directory repair/reconstruction jobs; I have also often been hired to fix specific parts of sites for small business owners who would like to manage their own site, but their plans exceed their knowledge and experience. My advice is to contract specific tasks initially -- in writing --because it is so often the case that one new format will give the client new 'inspiration' and it becomes unclear when the work you've agreed to do is complete. Contract changes in the graphics separately from the code. Also, do not change a single tag until you've burned a copy of the existing site on a CD for them; it is a useful reference point in comparing the changes you've made to the original site.
-- Submitted by Marguerite Carr <firstname.lastname@example.org>