By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,667 Members | 2,214 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,667 IT Pros & Developers. It's quick & easy.

Large web site, need to do some major rearrangement of files...

P: n/a
I help manage a large web site, one that has over
600 html pages... It's a reference site for ham radio
folks and as an example, one page indexes over
1.8 gb of on-line PDF documents.

The site is structured as an upside-down tree, and
(if I remember correctly) never more than 4 levels.

The site basically grew (like the creeping black blob) ...
all the pages were created in Notepad over the last
10 years.

We're now having to re-arrange the site, and find that
we have to move entire folders of pages to other
locations.

Many pages have embedded in their text hard-coded
links to other pages. In addition, every page has, in
the upper left corner (and repeated in the lower left
corner) one to three hard-coded links the the level(s)
above it.

Moving one index page requires editing everything
that points to it and from it, and moving a glossary
page would require editing over 100 pages (scattered
across almost every folder) that pointed to it.

I've been told to use Microsoft FrontPage as it allows
you to automatically updating other links when a page
is changed or moved. Others have said that Dreamweaver
will do it. Others have said that "Hot Metal Pro" will do it,
or Adobe GoLive.

The only one of the above that I have had access to for
experimentation is Front Page and after experimenting
with it for a while I have decioded that it is NOT an option
due to the typical Microsoft "BLOAT". It would create
more problems than it would solve.

Every one of our pages is lean and mean html, and I've found
that you can suck any one of the pages into FP-2000 (the
only version I have access to) and it IMMEDIATELY reformats
it and there is no option to prevent that.

My experimentation settled on this: You suck in a page file,
flag the page as having been changed (even by just adding
one character somewhere, even in a meta tag) and then save
the page and you will find that it is mote than triple the size...
(mostly due to division, style and font tags that were added
behind your back). _this is unacceptable_. Maybe this
behavior has been fixed in FP-XP or some replacement,
I do not know.

Our audience is over 60% dialup and download speed is
important (which is why we hand edit everything and use
mostly html 3 standards).

How do other folks manage large web sites with regard
to changing pages which affects many other folders
and pages within the web site?

Jan 21 '07 #1
Share this Question
Share on Google+
20 Replies


P: n/a
"mike" <gr*****@gmail.comwrites:
How do other folks manage large web sites with regard
to changing pages which affects many other folders
and pages within the web site?
First, configure your web server to return a 301 Moved Permanently for the
old URLs. That will redirect requests for the old URLs to the new ones. If
you're using Apache, you can use the RedirectPermanent directive for that.

Now, apply the "squeaky wheel" rule. Watch your web server logs and see which
redirects are getting hit the most often, and what their referrers are. Those
referrers (assuming they're your pages) will be the pages you want to update
first.

Another reason to watch those referrers: There may be "deep links" from out-
side your site that lead to a page you've moved. As a courtesy, you can let
those folks know that they need to update their links.

The 301 redirect only takes an additional fraction of a second, even on dial-
up, so you don't need to feel pressured to find and fix every last link at
the same time. That kind of pressure often leads to a rushed job, which leads
to mistakes.

As far as actually making the edits goes, I'm a Mac guy, so I'm not familiar
enough with Windows software to make a specific recommendation. As you've
mentioned, you want to avoid anything that rewrites your code behind your
back. Beyond that, any editor that can do a multi-file search & replace will
be a big help.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
Jan 21 '07 #2

P: n/a
In our last episode,
<11**********************@a75g2000cwd.googlegroups .com>, the lovely and
talented mike broadcast on comp.infosystems.www.authoring.html:
How do other folks manage large web sites with regard
to changing pages which affects many other folders
and pages within the web site?

To maintain a site like that I think you need some combination of
a database and a scripting or preprocessing language.

This would allow you to refer to links symbolically in page templates,
change the links as necessary in your database, and generate pages with the
scripting or preprocessing language. For the scripting/preprocessing
component, the major choices are perl and PHP. Although PHP is widely used
to generate pages dynamically, it can also be used as an offline
preprocessor (CLI --- command line interface). Both PHP and perl have
support for a variety of databases, one of which is likely to be suitable to
your platform. A make utilitity is also very handy for keeping track of
dependencies so you need only regenerate those pages actually affected by
particular changes instead of having to regenerate the whole site for every
little change.

--
Lars Eighner <http://larseighner.com/ <http://myspace.com/larseighner>
Countdown: 730 days to go.
Jan 21 '07 #3

P: n/a
On 2007-01-21, mike <gr*****@gmail.comwrote:
[snip]
Many pages have embedded in their text hard-coded
links to other pages. In addition, every page has, in
the upper left corner (and repeated in the lower left
corner) one to three hard-coded links the the level(s)
above it.

Moving one index page requires editing everything
that points to it and from it, and moving a glossary
page would require editing over 100 pages (scattered
across almost every folder) that pointed to it.
[snip]
How do other folks manage large web sites with regard
to changing pages which affects many other folders
and pages within the web site?
We don't know exact details, but what you want is fairly easy to do with
a short script in Python, Tcl, Perl etc., or even with a powerful text
editor like vim.

If you don't know any of those tools, any time spent learning any of
them will quickly pay for itself.
Jan 21 '07 #4

P: n/a
On 21 Jan 2007 13:06:41 -0800, in comp.infosystems.www.authoring.html
"mike" <gr*****@gmail.comwrote:
>I help manage a large web site, one that has over
600 html pages... It's a reference site for ham radio
folks and as an example, one page indexes over
1.8 gb of on-line PDF documents.
[...]
>Many pages have embedded in their text hard-coded
links to other pages. In addition, every page has, in
the upper left corner (and repeated in the lower left
corner) one to three hard-coded links the the level(s)
above it.
[...]
>How do other folks manage large web sites with regard
to changing pages which affects many other folders
and pages within the web site?
I use a multi-file text editor for this and other things:

http://www.simes.clara.co.uk/programs/xchange.htm

FWIW, my site will eventually have 350+ pages. Moving, renaming or
splitting a file has serious ramifications.

--
William Hughes, San Antonio, Texas: cv****@grandecom.net
The Carrier Project: http://home.grandecom.net/~cvproj/carrier.htm
Support Project Valour-IT: http://soldiersangels.org/valour/index.html
Jan 21 '07 #5

P: n/a
mike wrote:
I help manage a large web site, one that has over
600 html pages... It's a reference site for ham radio
folks and as an example, one page indexes over
1.8 gb of on-line PDF documents.

The site is structured as an upside-down tree, and
(if I remember correctly) never more than 4 levels.

The site basically grew (like the creeping black blob) ...
all the pages were created in Notepad over the last
10 years.

We're now having to re-arrange the site, and find that
we have to move entire folders of pages to other
locations.

Many pages have embedded in their text hard-coded
links to other pages. In addition, every page has, in
the upper left corner (and repeated in the lower left
corner) one to three hard-coded links the the level(s)
above it.

Moving one index page requires editing everything
that points to it and from it, and moving a glossary
page would require editing over 100 pages (scattered
across almost every folder) that pointed to it.

I've been told to use Microsoft FrontPage as it allows
you to automatically updating other links when a page
is changed or moved. Others have said that Dreamweaver
will do it. Others have said that "Hot Metal Pro" will do it,
or Adobe GoLive.

The only one of the above that I have had access to for
experimentation is Front Page and after experimenting
with it for a while I have decioded that it is NOT an option
due to the typical Microsoft "BLOAT". It would create
more problems than it would solve.

Every one of our pages is lean and mean html, and I've found
that you can suck any one of the pages into FP-2000 (the
only version I have access to) and it IMMEDIATELY reformats
it and there is no option to prevent that.

My experimentation settled on this: You suck in a page file,
flag the page as having been changed (even by just adding
one character somewhere, even in a meta tag) and then save
the page and you will find that it is mote than triple the size...
(mostly due to division, style and font tags that were added
behind your back). _this is unacceptable_. Maybe this
behavior has been fixed in FP-XP or some replacement,
I do not know.

Our audience is over 60% dialup and download speed is
important (which is why we hand edit everything and use
mostly html 3 standards).

How do other folks manage large web sites with regard
to changing pages which affects many other folders
and pages within the web site?
mike,

A preprocessor would help. See http://dennisbareis.com/ppwizard.htm for
one possible choice, which is free and works.

Chris Beall
Jan 21 '07 #6

P: n/a
"mike" <gr*****@gmail.comwrote in message
news:11**********************@a75g2000cwd.googlegr oups.com...
>I help manage a large web site, one that has over
600 html pages... It's a reference site for ham radio
folks and as an example, one page indexes over
1.8 gb of on-line PDF documents.

The site is structured as an upside-down tree, and
(if I remember correctly) never more than 4 levels.

The site basically grew (like the creeping black blob) ...
all the pages were created in Notepad over the last
10 years.

We're now having to re-arrange the site, and find that
we have to move entire folders of pages to other
locations.

Many pages have embedded in their text hard-coded
links to other pages. In addition, every page has, in
the upper left corner (and repeated in the lower left
corner) one to three hard-coded links the the level(s)
above it.

Moving one index page requires editing everything
that points to it and from it, and moving a glossary
page would require editing over 100 pages (scattered
across almost every folder) that pointed to it.

I've been told to use Microsoft FrontPage as it allows
you to automatically updating other links when a page
is changed or moved. Others have said that Dreamweaver
will do it. Others have said that "Hot Metal Pro" will do it,
or Adobe GoLive.

The only one of the above that I have had access to for
experimentation is Front Page and after experimenting
with it for a while I have decioded that it is NOT an option
due to the typical Microsoft "BLOAT". It would create
more problems than it would solve.

Every one of our pages is lean and mean html, and I've found
that you can suck any one of the pages into FP-2000 (the
only version I have access to) and it IMMEDIATELY reformats
it and there is no option to prevent that.

My experimentation settled on this: You suck in a page file,
flag the page as having been changed (even by just adding
one character somewhere, even in a meta tag) and then save
the page and you will find that it is mote than triple the size...
(mostly due to division, style and font tags that were added
behind your back). _this is unacceptable_. Maybe this
behavior has been fixed in FP-XP or some replacement,
I do not know.

Our audience is over 60% dialup and download speed is
important (which is why we hand edit everything and use
mostly html 3 standards).

How do other folks manage large web sites with regard
to changing pages which affects many other folders
and pages within the web site?
Mike, The latest version of Frontpage, 2003, fixes many of the gripes you
have about bloat, auto-reformatting, etc. It also can optimize your HTML, to
remove comments and extra spaces for even faster download time. FP 2003,
like Dreamweaver, allows you to use Dynamic Web Templates, which could help
you quickly update large number of pages in batches with standardized
headers, footers, navigation, etc. As you noted, FP does allow you to move
or pages from within a GUI and automatically manage the links, etc. The
successor to FP is Expression Web
(http://www.microsoft.com/products/ex...b/default.mspx)
which has a free trial available.

Hand coding may get you leaner pages, but with 600 pages to update and
reorganize, it might make sense for you to find a tool that will maximize
your productivity and provide a path for easier maintenance over time.
There's a good reason that a lot of professional web developers, for whom
time is money, use DreamWeaver (fewer use FP, which because of flaws in
earlier versions is still perceived as more of an amateur's tool) rather
than Notepad, etc.

Jan 22 '07 #7

P: n/a
mike wrote:
I help manage a large web site, one that has over
600 html pages... It's a reference site for ham radio
folks and as an example, one page indexes over
1.8 gb of on-line PDF documents.

The site is structured as an upside-down tree, and
(if I remember correctly) never more than 4 levels.

The site basically grew (like the creeping black blob) ...
all the pages were created in Notepad over the last
10 years.

We're now having to re-arrange the site, and find that
we have to move entire folders of pages to other
locations.

Many pages have embedded in their text hard-coded
links to other pages. In addition, every page has, in
the upper left corner (and repeated in the lower left
corner) one to three hard-coded links the the level(s)
above it.

Moving one index page requires editing everything
that points to it and from it, and moving a glossary
page would require editing over 100 pages (scattered
across almost every folder) that pointed to it.

I've been told to use Microsoft FrontPage as it allows
you to automatically updating other links when a page
is changed or moved. Others have said that Dreamweaver
will do it. Others have said that "Hot Metal Pro" will do it,
or Adobe GoLive.

The only one of the above that I have had access to for
experimentation is Front Page and after experimenting
with it for a while I have decioded that it is NOT an option
due to the typical Microsoft "BLOAT". It would create
more problems than it would solve.

Every one of our pages is lean and mean html, and I've found
that you can suck any one of the pages into FP-2000 (the
only version I have access to) and it IMMEDIATELY reformats
it and there is no option to prevent that.

My experimentation settled on this: You suck in a page file,
flag the page as having been changed (even by just adding
one character somewhere, even in a meta tag) and then save
the page and you will find that it is mote than triple the size...
(mostly due to division, style and font tags that were added
behind your back). _this is unacceptable_. Maybe this
behavior has been fixed in FP-XP or some replacement,
I do not know.

Our audience is over 60% dialup and download speed is
important (which is why we hand edit everything and use
mostly html 3 standards).

How do other folks manage large web sites with regard
to changing pages which affects many other folders
and pages within the web site?
First of all, as you work on individual pages within your site, change
all links to other file within the same site to use relative URLs. This
can be done over a period of time.

Try an experiment. Install both FrontPage and Nvu (freeware available
for Windows at <http://www.nvu.com/>). After fixing one page with
FrontPage, note all the other pages that are affected and adjusted by
FrontPage. Then make a negligible change to each with Nvu. See if Nvu
reduces the bloat.

I've never used FrontPage, but I have tried Nvu. The latter seems to
create pages that are compliant with the HTML 4.0 specification. I
still use Wordpad (not Notepad) to create and maintain my site (344
pages). I don't use Nvu because I don't like the way it formats source
files. (But that's a personal judgement based on aesthetics and not on
technical merit.)

Since I didn't use Nvu extensively, I didn't learn all its features. It
might even have the same capability as FrontPage to update links in
affected pages when you change one page.

--

David E. Ross
<http://www.rossde.com/>

Concerned about someone (e.g., Pres. Bush) snooping
into your E-mail? Use PGP.
See my <http://www.rossde.com/PGP/>
Jan 22 '07 #8

P: n/a
mike wrote:
I help manage a large web site, one that has over
600 html pages...
>
Many pages have embedded in their text hard-coded
links to other pages. In addition, every page has, in
the upper left corner (and repeated in the lower left
corner) one to three hard-coded links the the level(s)
above it.
>
Every one of our pages is lean and mean html, and I've found
that you can suck any one of the pages into FP-2000 (the
only version I have access to) and it IMMEDIATELY reformats
it and there is no option to prevent that.

My experimentation settled on this: You suck in a page file,
flag the page as having been changed (even by just adding
one character somewhere, even in a meta tag) and then save
the page and you will find that it is mote than triple the size...
(mostly due to division, style and font tags that were added
behind your back). _this is unacceptable_. Maybe this
behavior has been fixed in FP-XP or some replacement,
I do not know.
This may be only half-helpful at best, but maybe you or somebody else
can use it.

FrontPage 2002 (and I had *thought*, FP 2000, but I don't have it
around) has a switch to preserve source code formatting (who says
Microsoft doesn't listen?). It's under Tools - Page Options (which
doesn't mean it affects just the *current page's* options; rather, it
concerns options which affect the *pages*). On the "HTML Source" tab
choose the "Preserve existing HTML" radio button. It seems (or seemed)
to do it for me. FrontPage 98, I remember clearly, was quite merciless
about changing code.

Mmm, before I sign off, you might also look at the Compatibility tab on
the same Page Options window. If you're getting a bunch of DIVs added,
maybe you can try dialling down the CSS and DHTML levels.

If you can convince FP not to hack your code, but just make the link
changes (and you've already got it handy), then you should be able to
import your web, change the links site-wide, then just grab the changed
HTML files (turn off FP and put it back in the closet), ignoring all the
nasty _vti files and folders.
>
How do other folks manage large web sites with regard
to changing pages which affects many other folders
and pages within the web site?
Well, I use FP or DW for that. It's probably the biggest useful thing
about FP, except that it's familiar. I code mostly in Notepad or HTML
View of one of the WYSIWYGers.

HTH. GL!
--
John
Jan 22 '07 #9

P: n/a
On 21 Jan 2007 13:06:41 -0800, "mike" <gr*****@gmail.comwrote:
>
How do other folks manage large web sites with regard
to changing pages which affects many other folders
and pages within the web site?
The site I publish is in excess of 100,000 pages. Yes it's a
nightmare!

I use bespoke automation software to create the HTML from text files
containing the data, in this way links etc are automatically changed.

Similarly, with a change of a single link, such as a navigation link,
I use a bespoke program to search every HTML file and make the desired
change, and then upload the amended files to the server.

If the old links are in a fixed pattern, that is every HTML file
follows the same format, automation is straightforward, search for the
old pattern and replace it with the new.

Matt
Jan 22 '07 #10

P: n/a
mike wrote:
The site basically grew (like the creeping black blob) ...
all the pages were created in Notepad over the last
10 years.
Get yourself a decent SQL-database-backed content management system.
Getting all your pages *into* the CMS will be a pain, but you'll only have
to do it once. (If you know a bit of Perl, you may be able to automate
some of it.)

You'll thank yourself in the future.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Jan 22 '07 #11

P: n/a

David E. Ross wrote:
mike wrote:
I help manage a large web site, one that has over
600 html pages... It's a reference site for ham radio
folks and as an example, one page indexes over
1.8 gb of on-line PDF documents.

The site is structured as an upside-down tree, and
(if I remember correctly) never more than 4 levels.

The site basically grew (like the creeping black blob) ...
all the pages were created in Notepad over the last
10 years.

We're now having to re-arrange the site, and find that
we have to move entire folders of pages to other
locations.

Many pages have embedded in their text hard-coded
links to other pages. In addition, every page has, in
the upper left corner (and repeated in the lower left
corner) one to three hard-coded links the the level(s)
above it.

Moving one index page requires editing everything
that points to it and from it, and moving a glossary
page would require editing over 100 pages (scattered
across almost every folder) that pointed to it.

I've been told to use Microsoft FrontPage as it allows
you to automatically updating other links when a page
is changed or moved. Others have said that Dreamweaver
will do it. Others have said that "Hot Metal Pro" will do it,
or Adobe GoLive.

The only one of the above that I have had access to for
experimentation is Front Page and after experimenting
with it for a while I have decioded that it is NOT an option
due to the typical Microsoft "BLOAT". It would create
more problems than it would solve.

Every one of our pages is lean and mean html, and I've found
that you can suck any one of the pages into FP-2000 (the
only version I have access to) and it IMMEDIATELY reformats
it and there is no option to prevent that.

My experimentation settled on this: You suck in a page file,
flag the page as having been changed (even by just adding
one character somewhere, even in a meta tag) and then save
the page and you will find that it is mote than triple the size...
(mostly due to division, style and font tags that were added
behind your back). _this is unacceptable_. Maybe this
behavior has been fixed in FP-XP or some replacement,
I do not know.

Our audience is over 60% dialup and download speed is
important (which is why we hand edit everything and use
mostly html 3 standards).

How do other folks manage large web sites with regard
to changing pages which affects many other folders
and pages within the web site?

First of all, as you work on individual pages within your site, change
all links to other file within the same site to use relative URLs. This
can be done over a period of time.

Try an experiment. Install both FrontPage and Nvu (freeware available
for Windows at <http://www.nvu.com/>). After fixing one page with
FrontPage, note all the other pages that are affected and adjusted by
FrontPage. Then make a negligible change to each with Nvu. See if Nvu
reduces the bloat.

I've never used FrontPage, but I have tried Nvu. The latter seems to
create pages that are compliant with the HTML 4.0 specification. I
still use Wordpad (not Notepad) to create and maintain my site (344
pages). I don't use Nvu because I don't like the way it formats source
files. (But that's a personal judgement based on aesthetics and not on
technical merit.)
Try HandCoder, it's an extension for NVU, it runs useing HTML Tidy,
which you will need as well.
It re-formats your code in to a nicely indented page so you can edit it
in an external editor if need be.
>
Since I didn't use Nvu extensively, I didn't learn all its features. It
might even have the same capability as FrontPage to update links in
affected pages when you change one page.
It does, but the feature is not fully functional.
Although you can download an extension that will fix the problem,
(though I have never used it).
I now a days, create my pages in NVU, then just use HandCoder to tidy
up the code and I then just use PHP includes, written in HTML-Kit or
NotePad (depending on if I want the extra features or not).
--
Regards Chad. http://freewebdesign.cjb.cc

Jan 22 '07 #12

P: n/a
On Mon, 22 Jan 2007 10:18:38 +0000
Toby Inkster <us**********@tobyinkster.co.ukwrote:
Get yourself a decent SQL-database-backed content management system.
The sledgehammer approach. I'd say the same for that as for
fixing links on the fly: do it if and only if you have an
identified need *and* no simpler solution.
Getting all your pages *into* the CMS will be a pain, but you'll only
have to do it once. (If you know a bit of Perl, you may be able to
automate some of it.)
If you know a bit of Perl, it becomes a five minute job to fix the
links when you rearrange pages, whether that's 6 pages or 600.
Or indeed, six million!

--
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Jan 22 '07 #13

P: n/a

mike wrote:
I help manage a large web site, one that has over
600 html pages.
You have several destinations you could end up. Decide on which one,
then worry about how to get there.

The options are:

* Static HTML pages

* Static XML text with off-line publishing. The content gets turned
into static XML files in something like DocBook or even HTML itself,
and then an XSLT transform converts it to HTML and sorts out the many
links.

* SQL database content store and a few dynamic page generators. This
can run on-line or off-line (a bit like #2, make a copy of the site as
static HTML, then upload it and pretend it's option #1)

* CMS
Don't write your own, download an open-source one and use that.

* Wiki
Don't write your own, download an open-source one and use that (and
I'd suggest MediaWiki)
Your choice between these should be based on the end results and a
long-term view of how you'll manage things for the next few years,
including further refactorings like this and possible the addition of
major new facilities.

Don't base your choice of destination on the options for conversion
alone. It's a big site, it has plenty of resource it can call on. To be
honest, when I hear "Frontpage" discussed as a possible tool here I
lose heart that it will ever work again. That's _entirely_ the wrong
sort of tool to be using, at a level that's deeper than any M$oft
flamewar over "M$ tools make lousy code".

Don't focus on the finished site either. You also need to create these
pages and presumably a lot of people need to create more of the same.
This itself is a strong argument for using a good Wiki.

While you're making this change, write some standards for the quality
of the final pages. This is a very good time to think about making them
accessible and standards-based. Please ask c.i.w.a.h for advice on
these standards though, don't just adopt XHTML blindly because it's the
latest thing around.

As a final issue, try to manage the migration from one to the other in
terms of search engine ratings. Intelligent use of 301s can help, lots
of use of 301s might make the change entirely invisible. On the whole
though, just make the best site you can, give it a logical structure
with good navigation, write a sitemap for Google and then let Google
sort things out for itself. Unless you're actually competing for
keywords with other sites, the best SEO is simply to have a good site
with good content.

Jan 22 '07 #14

P: n/a
"mike" <gr*****@gmail.comwrote:
How do other folks manage large web sites with regard
to changing pages which affects many other folders
and pages within the web site?
I use XML to store the pages. A script generates the HTML pages in a build
directory. A second script checks the build against a local copy of my
site. If there is a difference, the file is uploaded, and after a
succesfull upload copied to the local copy as well.

It was a bit later that I read about Forrest. Haven't checked it out, but
it does a similar and probably better job: http://forrest.apache.org/

--
John Need help with SEO? Get started with a SEO report of your site:

--http://johnbokma.com/websitedesign/seo-expert-help.html
Jan 22 '07 #15

P: n/a
Nick Kew wrote:
Toby Inkster <us**********@tobyinkster.co.ukwrote:
>Get yourself a decent SQL-database-backed content management system.

The sledgehammer approach.
Bulk changing links in a bunch of files is possible, sure, but it's a
sticking-plaster solution covering up the underlying problem: lots of
pages with no content management.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Jan 22 '07 #16

P: n/a
I'm going to reply to all the messages above here...

From: Sherm Pendley - view profile
Sherm Pendley wrote:
First, configure your web server to return a 301 Moved Permanently
for the old URLs. That will redirect requests for the old URLs to the
new ones. If you're using Apache, you can use the RedirectPermanent
directive for that.
Can you elaborate slightly on this... we're using hostmonster for our
hosting and they've been quite helpful but I think I need to know a bit

more before I ask for this...
The 301 redirect only takes an additional fraction of a second, even
on dial-up, so you don't need to feel pressured to find and fix every
last link at the same time. That kind of pressure often leads to a
rushed job, which leads to mistakes.
I certainly understand mistakes... I've been there, done that...

I've edited the 404 page as a stopgap... see
<http://www.repeater-builder.com/404.html>

Lars Eighner wrote:
To maintain a site like that I think you need some combination of
a database and a scripting or preprocessing language.
The database woudl certainly help, and the hosting comany offers
MySQL, PostgreSQL, but I havent' learned that (yet)
This would allow you to refer to links symbolically in page
templates, change the links as necessary in your database,
and generate pages with the scripting or preprocessing language.
I'm not sure what they offer there...
For the scripting/preprocessing component, the major choices
are perl and PHP. Although PHP is widely used to generate
pages dynamically, it can also be used as an offline preprocessor
(CLI --- command line interface). Both PHP and perl have
support for a variety of databases, one of which is likely to be
suitable to your platform. A make utilitity is also very handy
for keeping track of dependencies so you need only regenerate
those pages actually affected by particular changes instead of
having to regenerate the whole site for every little change.
I'm familiar withthe concept of make - but the last two major software
development projects I worked on were on a minicomputer (Data
General, in assembly code, 20 years ago, a process control
application, 250,000 lines of code) and on a microprocessor (Z80,
47,000 lines of assembly, boiled down to 40k of binary).

Ben C. wrote:
We don't know exact details, but what you want is fairly easy
to do with a short script in Python, Tcl, Perl etc., or even with
a powerful text editor like vim.
Here's a sample file from the site, showing the links in the top
left corner, and a second identical set at the bottom:
<http://www.repeater-builder.com/mitrek/mitrek-interfacing.html>
If you don't know any of those tools, any time spent learning
any of them will quickly pay for itself.
I've done some playing with Perl, in fact I rewrote an auction script
that was in Perl... I did a draft web site for a Playmate and we had
an auction script going... it actually wrote the html code on the fly.
The auction never made it into the final web site...

Yes, I need to learn a lot more about text processing languages...

FWIW all updates are currently done by four people... the site
owner and I have complete copies of the entire web site on our
local hard drives, and the other two have copie sof their articles.
The current procedure is for the person to download a fresh copy
of any web page they are going to change, rename it to
(filename).yyyy-mm-dd.html, upload that file, then make the
changes to the original file, then upload it (overwriting the live
copy). If there's a problem, then any of us four can put the
old page back.

William Hughes wrote:
I use a multi-file text editor for this and other things:

http://www.simes.clara.co.uk/programs/xchange.htm
Their site has moved, might want to update your links...

I've got MultiEdit, but at first look that one looks better...
FWIW, my site will eventually have 350+ pages. Moving,
renaming or splitting a file has serious ramifications.
Exactly - that's why I'm here asking these questions...

Chris Beall wrote:
A preprocessor would help. See http://dennisbareis.com/ppwizard.htm
for one possible choice, which is free and works.
At a first read that will help a LOT !!! I like the ;#include... I
feel that some
kind of an include should have been in html from the beginning...
that
would have made headers and footers a lot easier.

"Alex" wrote:
Mike, The latest version of Frontpage, 2003, fixes many of
the gripes you have about bloat, auto-reformatting, etc. It
also can optimize your HTML, to remove comments and
extra spaces for even faster download time. FP 2003, like
Dreamweaver, allows you to use Dynamic Web Templates,
which could help you quickly update large number of pages
in batches with standardized headers, footers, navigation, etc.
As you noted, FP does allow you to move or pages from within
a GUI and automatically manage the links, etc. The successor
to FP is Expression Web
(http://www.microsoft.com/products/ex...ion-Web/defaul...)
which has a free trial available.
I'd love to have a hourlong sit-down session with a Dreamweaver
guru and get a feel for it... (I'm in the Pasadena, Calif. area if
anybody
is local to me). I have no problem with buying a copy if it will
actually
scratch my itch.
Hand coding may get you leaner pages, but with 600 pages to
update and reorganize, it might make sense for you to find a
tool that will maximize your productivity and provide a path for
easier maintenance over time.
(nods head) I totally agree.
There's a good reason that a lot of professional web developers,
for whom time is money, use DreamWeaver (fewer use FP, which
because of flaws in earlier versions is still perceived as more of an
amateur's tool) rather than Notepad, etc.
The team used text editors a lot due to the behind-your-back rewriting

that a lot of earlier tools did. The site was first started in March
of
1995, and many of the oldest pages were done in Netscape Composer
and later on, Front Page 97.
Have you seen the bloat that Word 2000 produces with "Save As"
html ??? That's the kind of stuff I'm referring to when I say "Bloat".
I've got several contributors that send me Word files... it's not
unusual
to take a 250kb file and whittle it down to under 50kb just by trashing

the <p class=MsoNormal style='text-align:justify'(and variants)
stuff.
I'd love to see a "Save As HTML 3" option.

David E. Ross wrote:
First of all, as you work on individual pages within your
site, change all links to other file within the same site
to use relative URLs. This can be done over a period of time.
We've been doing that...
Try an experiment. Install both FrontPage and Nvu (freeware
available for Windows at <http://www.nvu.com/>). After fixing
one page with FrontPage, note all the other pages that are
affected and adjusted by FrontPage. Then make a negligible
change to each with Nvu. See if Nvu reduces the bloat.
I've downloaded Nvu, and I'm going to borrow a copy of FP 2003
based on comments above and below.
I've never used FrontPage, but I have tried Nvu. The latter
seems to create pages that are compliant with the HTML 4.0
specification. I still use Wordpad (not Notepad) to create and
maintain my site (344 pages). I don't use Nvu because I don't
like the way it formats source files. (But that's a personal
judgement based on aesthetics and not on technical merit.)
I've looked at your site, and am impressed. I clicked on your
loation link and discovered that I was less than 10 miles from
your location a week ago. Mabe we can cross paths sometime.
Since I didn't use Nvu extensively, I didn't learn all its features.
It might even have the same capability as FrontPage to update
links in affected pages when you change one page.
I'll play with it and see what it can do. Thanks for the pointer.

John Hosking wrote:
This may be only half-helpful at best, but maybe you or
somebody else can use it.

FrontPage 2002 (and I had *thought*, FP 2000, but I don't
have it around) has a switch to preserve source code
formatting (who says Microsoft doesn't listen?). It's under
Tools - Page Options (which doesn't mean it affects just
the *current page's* options; rather, it concerns options
which affect the *pages*). On the "HTML Source" tab
choose the "Preserve existing HTML" radio button. It seems
(or seemed) to do it for me. FrontPage 98, I remember clearly,
was quite merciless about changing code.
As I said above, a lot of the work was done with FP97 and
Netscape Composer... in fact the last Composer user switched
about 11 months ago.
Mmm, before I sign off, you might also look at the Compatibility
tab on the same Page Options window. If you're getting a bunch
of DIVs added, maybe you can try dialling down the CSS and
DHTML levels.
Speaking of CSS, that's another thing I've got to learn.
This is part of the "standard" page template and I've been told
that it would be a simple thing to put into a CSS file:

<body lang="EN-US" bgcolor="#C0C0C0" background="/pix/rbtip.gif"
text="#000000"
leftmargin="20" rightmargin="20" topmargin="20" bottommargin="20"
marginwidth="20" marginheight="20">
<!-- Netscape specific: marginheight is the top margin,
marginwidth=left margin -->
If you can convince FP not to hack your code, but just make
the link changes (and you've already got it handy), then you
should be able to import your web, change the links site-wide,
then just grab the changed HTML files (turn off FP and put it
back in the closet), ignoring all the nasty _vti files and folders.
As I said, I'm going to borrow a copy of FP 2003 and play with it.
If I can load the site into it, relocate a folder within the tree, and
have ONLY the hard coded inter-file links that are contained in
the other files change (i.e no other reformatting done) then FP
will scratch my itch. If it does any other changes, then it's
getting trashed.

My current thinking is that my fallback is a multi-file editor of
some sort.

Toby Inkster wrote:
Get yourself a decent SQL-database-backed content
management system. Getting all your pages *into* the
CMS will be a pain, but you'll only have to do it once.
(If you know a bit of Perl, you may be able to automate
some of it.)
You'll thank yourself in the future.

The hosting comany offers:
Drupal
Geeklog
Joomla
Mambo Open Source
PHP-Nuke
phpWCMS
phpWebSite
Post-Nuke
Siteframe
Xoops

dotProject
PHProjekt

Anybody have any comments on any of them?
All they are to me (right now) is names...

Chaddy2222 wrote:
David E. Ross wrote:
I've never used FrontPage, but I have tried Nvu. The latter seems to
create pages that are compliant with the HTML 4.0 specification. I
still use Wordpad (not Notepad) to create and maintain my site (344
pages). I don't use Nvu because I don't like the way it formats source
files. (But that's a personal judgement based on aesthetics and not on
technical merit.)

Try HandCoder, it's an extension for NVU, it runs useing HTML Tidy,
which you will need as well.
It re-formats your code in to a nicely indented page so you can edit it
in an external editor if need be.
I've used Tidy... it does a lot of good, but insists on replacing </p>
with <br><brand then complains that <brshould be <br />
Since I didn't use Nvu extensively, I didn't learn all its features. It
might even have the same capability as FrontPage to update links in
affected pages when you change one page.
It does, but the feature is not fully functional.
Although you can download an extension that
will fix the problem, (though I have never used it).
Which one?
I now a days, create my pages in NVU, then just
use HandCoder to tidy up the code and I then just
use PHP includes, written in HTML-Kit or NotePad
(depending on if I want the extra features or not).
Andy Dingley wrote:
mike wrote:
I help manage a large web site, one that has over
600 html pages.

You have several destinations you could end up. Decide on which one,
then worry about how to get there.

The options are:

* Static HTML pages
Which is what we have now.
* Static XML text with off-line publishing. The content
gets turned into static XML files in something like DocBook
or even HTML itself, and then an XSLT transform converts
it to HTML and sorts out the many links.
I'll have to look at DocBook, until your message I had
no idea it existed.
* SQL database content store and a few dynamic page
generators. This can run on-line or off-line (a bit like #2,
make a copy of the site as static HTML, then upload it
and pretend it's option #1)
As I said above, I have a copy of the site on my home machine.
* CMS
Don't write your own, download an open-source one and use that.
As I said above, the hosting comany offers several (listed above),
and I'd like comments on them.
* Wiki
Don't write your own, download an open-source one and use that (and
I'd suggest MediaWiki)
They offer:
TikiWiki
PhpWiki
Your choice between these should be based on the end results and a
long-term view of how you'll manage things for the next few years,
including further refactorings like this and possible the addition of
major new facilities.
We just moved to a new hosting company in December, and that
was the first major change in 10 years. The site is run totally by
volunteers, and is funded by donations. The only current plans are
to add a few more helpers... nobody has looked much at site
management except me.
Don't base your choice of destination on the options for
conversion alone. It's a big site, it has plenty of resource
it can call on. To be honest, when I hear "Frontpage"
discussed as a possible tool here I lose heart that it will
ever work again. That's _entirely_ the wrong sort of tool
to be using, at a level that's deeper than any M$oft
flamewar over "M$ tools make lousy code".
The only reason I even mentioned it was that it was used before,
and that I may have access to a copy of FP2003. If it can fix the
links *and change nothing else* then it scratches my current itch...
I do not see it as a viable long-term management tool.
Don't focus on the finished site either. You also need to
create these pages and presumably a lot of people need
to create more of the same.
This itself is a strong argument for using a good Wiki.
We have a large number of contributors, some of which
have asked to be anonymous. If you look at the site
(www.repeater-builder.com) you will see a lot of donations
credited to A. Nony Mous.
I would love to be able to take their contributions and NOT
have to spend hours converting their Word files or emails
into html pages.
While you're making this change, write some standards
for the quality of the final pages. This is a very good time
to think about making them accessible and standards-based.
Already in progress.
Please ask c.i.w.a.h for advice on these standards though,
don't just adopt XHTML blindly because it's the latest thing around.
I look skeptically at anything designed by a committe. Something
is always overdone, or left out. Look at RS-232 - a complete spec
except for the connector itself. Fortunately the Canon Corp DB25
was settled on, but 20 years later IBM flipped the sex over... until
the PC came along the computer port was always female and the
cable was always male. IBMs response? the connector was never
specified in the standard.
As a final issue, try to manage the migration from one to the
other in terms of search engine ratings. Intelligent use of 301s
can help, lots of use of 301s might make the change entirely
invisible.
Not too worried about ratings as this is a labor-of-love donation-run
reference website for a bunch of radio geeks, and there is pretty
much no competition. In any other environment I'd be in total
agreement. BTW, we've got folks that run some of the largest
public safety communications systems (i.e. Los Angeles County
Sheriffs, California Highway Patrol, Nevada Highway Patrol, FBI,
and others sharing info with us and using us for information.
We've got a Yahoogroup with over 3500 members and the web
site is basically an information warehouse.
On the whole though, just make the best site you can,
Doing that.
give it a logical structure
That's why we are trying to rearrange the folders on the server - to
make the structure easier for the helpers to understand.
with good navigation,
Working on that...
I'd love to make the links on the top left of the page automated
my a make process.
write a sitemap for Google and then let Google sort things out for itself.
Huh?
Unless you're actually competing for
keywords with other sites, the best SEO is simply to have a good site
with good content.
No competing involved (see above).

I appreciate all the responses, and am looking forward to any
replies to this message.

Mike Morris

Jan 22 '07 #17

P: n/a

John Bokma wrote:
It was a bit later that I read about Forrest. Haven't checked it out, but
it does a similar and probably better job: http://forrest.apache.org/
Provided that you're happy with the "content as XML" decision in the
first place, Forrest is an excellent tool for handling the downstream
processing of it. It makes it very easy to support paper or CD-ROM
versions too.

Jan 22 '07 #18

P: n/a
"mike" <gr*****@gmail.comwrites:
I'm going to reply to all the messages above here...

From: Sherm Pendley - view profile
Sherm Pendley wrote:
>First, configure your web server to return a 301 Moved Permanently
for the old URLs. That will redirect requests for the old URLs to the
new ones. If you're using Apache, you can use the RedirectPermanent
directive for that.

Can you elaborate slightly on this... we're using hostmonster for our
hosting and they've been quite helpful but I think I need to know a bit
more before I ask for this...
As you're apparently aware, a status of 404 means "not found".

A status of 301 indicates that there was once a resource at this URL, but
that resource has since been moved to a different URL. Unlike a 404, which
returns a page to display to the user, a 301 does not include any content.
Instead, it simply returns a "Location:" header for the browser to follow.

It's all done automatically and very quickly. Especially observant users
will notice that the address bar changes to the new URL, but most won't. On
the other hand, well-written browsers do take notice, and update any book-
marks. Search engines will also notice, and take note of the new URL.
I'm familiar withthe concept of make - but the last two major software
development projects I worked on were on a minicomputer (Data
General, in assembly code, 20 years ago, a process control
application, 250,000 lines of code) and on a microprocessor (Z80,
47,000 lines of assembly, boiled down to 40k of binary).
Yes, I'm aware that this was in response to someone else's comment... just
had to chime in on this part... :-)

I use 'make' on some of my own sites. For those sites, I write my content in
XML, and I've created rules to run xsltproc to transform that into HTML. I
also have 'install' and 'synch' targets that use rsync to synch up a local
staging server and remote deployment server, respectively. I also check the
XML source into CVS, for version control management.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
Jan 22 '07 #19

P: n/a
Sherm Pendley <sp******@dot-app.orgwrote:
I use 'make' on some of my own sites. For those sites, I write my
content in XML, and I've created rules to run xsltproc to transform
that into HTML. I also have 'install' and 'synch' targets that use
rsync to synch up a local staging server and remote deployment server,
respectively. I also check the XML source into CVS, for version
control management.
I use Ant instead of make, and subversion instead of CVS and my own sync
script, but like he said :-)

--
John Need help with SEO? Get started with a SEO report of your site:

--http://johnbokma.com/websitedesign/seo-expert-help.html
Jan 22 '07 #20

P: n/a
On 2007-01-22, mike <gr*****@gmail.comwrote:
[snip]
Ben C. wrote:
>We don't know exact details, but what you want is fairly easy
to do with a short script in Python, Tcl, Perl etc., or even with
a powerful text editor like vim.

Here's a sample file from the site, showing the links in the top
left corner, and a second identical set at the bottom:
<http://www.repeater-builder.com/mitrek/mitrek-interfacing.html>
>If you don't know any of those tools, any time spent learning
any of them will quickly pay for itself.

I've done some playing with Perl, in fact I rewrote an auction script
that was in Perl... I did a draft web site for a Playmate and we had
an auction script going... it actually wrote the html code on the fly.
The auction never made it into the final web site...

Yes, I need to learn a lot more about text processing languages...
That's probably the quickest fix for your problem in the short term, but
you should take the advice others have given about how to set up some
proper "content management", especially if you've got four people still
updating the content.

You may need to write some Perl anyway to transform what you have into
however it's going to be stored in your content management system.
FWIW all updates are currently done by four people... the site owner
and I have complete copies of the entire web site on our local hard
drives, and the other two have copie sof their articles. The current
procedure is for the person to download a fresh copy of any web page
they are going to change, rename it to (filename).yyyy-mm-dd.html,
upload that file, then make the changes to the original file, then
upload it (overwriting the live copy). If there's a problem, then any
of us four can put the old page back.
This is what version control systems (CVS, Subversion, Perforce, et al.)
are for.

As a minimum you need one of those, since you've got four people working
on the updates. They're easy to set up and use and much less error-prone
than your current procedure.

Deciding how best to do this kind of thing is not easy. I'd be inclined
to store the HTML in a version control system, restructuring and fixing
it up one-off first with a script. But if for some reason it's desirable
to have permanent transformations between what you author and store and
what you publish, look into XML and XSLT rather than doing that with
Perl.
Jan 22 '07 #21

This discussion thread is closed

Replies have been disabled for this discussion.