This is Interesting: Free Magazines for Graphics designers and webmasters
Home > Archive > Webmaster forum > January 2007 > Large web site, need to do some major rearrangement of files...
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Large web site, need to do some major rearrangement of files...
|
|
|
| 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?
| |
| Sherm Pendley 2007-01-27, 11:09 pm |
| "mike" <grouchy@XXXXXXXXXX> writes:
> 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
| |
| Lars Eighner 2007-01-27, 11:09 pm |
| In our last episode,
<1169413601.710590.159680@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.
| |
| William Hughes 2007-01-27, 11:09 pm |
| On 21 Jan 2007 13:06:41 -0800, in comp.infosystems.www.authoring.html
"mike" <grouchy@XXXXXXXXXX> 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.
[...]
>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: cvproj@grandecom.net
The Carrier Project: http://home.grandecom.net/~cvproj/carrier.htm
Support Project Valour-IT: http://soldiersangels.org/valour/index.html
| |
| Chris Beall 2007-01-27, 11:09 pm |
| 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
| |
|
| "mike" <grouchy@XXXXXXXXXX> wrote in message
news:1169413601.710590.159680@a75g2000cwd.googlegroups.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/e...eb/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.
| |
| David E. Ross 2007-01-27, 11:09 pm |
| 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/>
| |
| Matt Probert 2007-01-27, 11:09 pm |
| On 21 Jan 2007 13:06:41 -0800, "mike" <grouchy@XXXXXXXXXX> wrote:
>
>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
| |
| Toby Inkster 2007-01-27, 11:09 pm |
| 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
| |
| Chaddy2222 2007-01-27, 11:09 pm |
|
David E. Ross wrote:
> mike 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.
>
> 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
| |
| Nick Kew 2007-01-27, 11:09 pm |
| On Mon, 22 Jan 2007 10:18:38 +0000
Toby Inkster <usenet200701@tobyinkster.co.uk> wrote:
> 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/
| |
| Andy Dingley 2007-01-27, 11:09 pm |
|
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.
| |
| John Bokma 2007-01-27, 11:09 pm |
| "mike" <grouchy@XXXXXXXXXX> wrote:
> 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
| |
| Toby Inkster 2007-01-27, 11:09 pm |
| Nick Kew wrote:
> Toby Inkster <usenet200701@tobyinkster.co.uk> wrote:
>
>
> 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
| |
|
| 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/mit...nterfacing.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/e...n-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:
>
> 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><br> and then complains that <br> should be <br />
[color=darkred]
> 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:
>
>
> 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
| |
| Andy Dingley 2007-01-27, 11:09 pm |
|
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.
| |
| Sherm Pendley 2007-01-27, 11:09 pm |
| "mike" <grouchy@XXXXXXXXXX> writes:
> I'm going to reply to all the messages above here...
>
> From: Sherm Pendley - view profile
> Sherm Pendley wrote:
>
> 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
| |
| John Bokma 2007-01-27, 11:09 pm |
| Sherm Pendley <spamtrap@dot-app.org> wrote:
> 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
|
|
|
| | Copyright 2003 - 2008 forum4designers.com Software forum Computer Hardware reviews |
|