views:

542

answers:

13

Hello,

I am managing a legacy website with a lot of static HTML websites, no server side scripting, just plain HTML/CSS, minimal javascript. I found it a huge waste of time to change the same piece of code numerous times in different pages. For example, when something in the menu changes, since the menu is just static text in each document, I have to make the same change numerous times.

I was wondering what the best tactic would be to minimize this overhead, in other words what would you recommend for managing things like navigation code across multiple static HTML pages.

I know you can use:

  1. server side scripting (like PHP), but there is no other reason to use scripting at that particular site.
  2. frames (but that's bad because its.. well, frames :))
  3. server side includes (that seems like it could lead to trouble when changing the server)
  4. javascript (bad for SEO)

What would you recommend?

Thanks.

+2  A: 

There may not be any other reason to use server side scripting, but certainly reducing the amount of written code is a pretty big reason to use it wouldn't you think? It would make maintaining the site much more efficient.

AlbertoPL
I agree. This is precisely why I started using PHP.
Nathan Long
Another argument: by not repeating yourself, you reduce errors. If you have 50 copies of your menu code, that's 50 potentially wrong menus; if you have 1, you can just check the heck out of that one.
Nathan Long
Yes, excellent point, and a big one. Reducing the possibility of human error is always a huge time-saver.
AlbertoPL
+2  A: 

In general I'd recommend PHP - its handling for includes is exactly what you need, and it makes anything dynamic much, much easier to manage.

It is also extremely easy to find hosting with PHP installed.

David Caunt
Downvoted because he clearly wasn't looking for this answer, but you recommended it anyway.
Coding With Style
He's listen 4 options and asked which I recommend. Sometimes I wonder why I bother
David Caunt
I downvoted because you gave an extremely simplistic answer mentioning everything he already knew (meaning your answer served no practical purpose) and because he didn't ask "which do you recommend" so much as he asked "what do you recommend" (ie. holding out for other options)
Coding With Style
@CWS - I think you're wrong here. OP asked for a recommendation. dcaunt thinks one of the listed options is best, and addressed one of the concerns OP had with server side includes - namely, portability. Maybe it would have been better to upvote an existing answer, but I see nothing wrong with dcaunt's response.
Nathan Long
OP never mentioned portability being a concern. Rather, the concern was embracing an additional layer of framework just for something this minor. Anyway, it just bothers me when I see answers which are by and large uninformative and/or unresponsive
Coding With Style
+2  A: 

It's been a long time since I've used it, but Dreamweaver was a great tool for working with static sites. It had a templating/repeating region mechanism that used comments for this purpose.

Edited to add: A little Googling jogged my memory. Dreamweaver has templates that are similar to ASP.NET master pages. For other content, it uses the metaphors of a Library and Assets. Since this is a static site, you should be able to pick up an older version of Dreamweaver on the cheap that meets your needs.

Edit 2: I have a soft spot for Dreamweaver. If StackOverflow is the anti-Experts Exchange than DW is the anti-FrontPage. Adobe being Adobe, at this point they've probably added enough features to effectively cripple it.

Jamie Ide
Interesting. I pretty much shied away from Dreamweaver because its CSS layout support is not that great, and the code generated was not very manageable.
Goro
+1  A: 

I would use PHP whenever my clients would present me with websites of this sort. You can easily put all of the recurring HTML in one file and call it via functions, or put it in separate files and call it via includes/requires/what have you.

Best of all, if whomever you are maintaining the site for, wishes to have some way that they can add content themselves. You already would have enough of the necessary framework in place to make it very simple for them.

Noctrine
Same issue as dcaunt.
Coding With Style
I don't know. By that same logic, your recommendation of an inline frame could be constructed as simplistic mentioning something he already knew. Also, he didn't explicitly ask for alternative options so giving my '2 cents' should have been perfectly valid.
Noctrine
There's a fairly large difference between regular frames and inline frames. Also, OP commented on Ryan's post "There is no problem with using PHP or any other scripting, and that is pretty much the direction I am leaning towards. I just wanted to see what the alternatives are."
Coding With Style
The question was solved already but, if I remember correctly I posted this before Goro's comment.I don't think that adding a +1 (with reasoning) vote isn't necessary contributing nothing to a discussion, sometimes you just need people to agree with you.Finally, I wouldn't call the differences fairly large. When it comes down to it, the iframe is still a frame. The OP did mention frames, just as he mentioned PHP, and I don't think my answer was any more simplistic than yours.
Noctrine
Ah, iirc the comment was already there when I downvoted. Also, you're right that when it comes down to it, the iframe is still a frame, BUT! the difference here is the implications in terms of design. If you make a frameset page using a navigation bar you can cause all sorts of trouble with hotlinking, tabbed browsing, bookmarking, printing, screen space, and browser history. You could fix these problems with JavaScript (which is in fact what I do when I use frames), but iframes avoid them altogether. A proper iframe here is effectively no different from a php include, except without the php.
Coding With Style
+2  A: 

You could use sed to batch-edit files containing the same page elements.

Evan Meagher
Yes. I was using Notepad++ to do pretty much the same thing.
Goro
+3  A: 

You could preprocess your website with PHP and then just upload the generated static HTML files.

Gumbo
This would work if server-side scripting was absolutely not possible. But it would be much harder to maintain.
Nathan Long
It would not be harder to maintain since every time there is a change you change it in PHP and "generate" a new version of the site as plain HTML files which you then can upload.
Luke
+4  A: 

You can use a static site generator. I recommend jekyll.

Paolo Capriotti
+2  A: 

What is the big problem with using PHP? In my opinion using an easy PHP include could save you a lot of time instead of editing numerous files. It makes sense.

<?php include('navigation.php'); ?>

Other than that the othe roption is making it on one and then copy and pasting it to the the other pages.

Ryan
There is no problem with using PHP or any other scripting, and that is pretty much the direction I am leaning towards. I just wanted to see what the alternatives are.
Goro
Ah okay hope you find somehting that works.
Ryan
+3  A: 

If you are set on maintaining a static site, I would recommend using a static site generator.

One I have used in the past is webgen

From the webgen page:

The page layout is separated from the content: if you change the layout, all pages that use that layout are automatically updated. You can have any number of different layouts and even nested ones.

Write content in a markup language: The content and layout files can be written in a markup language like Markdown, Textile or Haml which lets you concentrate more on what you write.

Automation: webgen can automatically generate, for example, menus and breadcrumb trails for you.

Dynamic content: It is easy to add some dynamic content if there is a need for it.

Bob F.
A: 

I've used Webby for this in the past and was very satisfied with how easy it made things and reduced duplication.

Mark A. Nicolosi
+1  A: 

I'd say an inline frame can be just fine for something like a menu that appears on every page and needs to be updated on every single one. Just remove the frameborder, size it properly, and it should be good.

Coding With Style
+3  A: 

Out of all the possibilities, both what you listed and anything else I know of, I'd still just run with a simple PHP-based solution. It's easy and clean, requiring next to no effort on your part. I do this with all the small sites I design.

Most often, you end up with fairly trivial structure. You write up a full page, then for each subsequent page you're just changing the bit in the middle where the content lives. In that case, just take everything above and below the content and save it in header.php and footer.php files, then put <?php require_once "header.php"; ?> at the top of each content file (and similarly with the footer file). Done!

This does have some minor disadvantages. For one, you're depending on scripting, but PHP is the most widely deployed server-side language in the world, so that's not really an issue. You don't even care if it's PHP4 or PHP5, since you're not doing anything fancy.

For two, you're running a script on every page load, in order to serve what is essentially a static file. That slows down your responses, and stresses the CPU unnecessarily. This probably doesn't matter much (the lag is very minor), but if you find it wasteful, there are some good PHP frameworks which will take your PHP-generated pages and generate static htmls out of them for you. (This is easy enough to do yourself, too, with just a bit of work using output buffering.) This way you get the best of both worlds - PHP templates (and the full PHP language if you end up wanting something fancier down the line) but static html pages for minimal CPU activity and fastest page load times.

Xanthir
Agreed - although performance for include statements is unlikely to be a consideration in most cases. (I asked about this in http://stackoverflow.com/questions/112786/php-performance-considerations)
Nathan Long
Having the server serve dynamic pages just for the sake of convenience of the developer is, in my opinion, overkill, especially considering that there exist better methods (see other aswers).
Paolo Capriotti
A: 

I think a reasonable compromise between ease and speed would encompass Server-Side-Includes first, then PHP later.

As for PHP, I'd suggest you wrap the content by using auto_append_file and auto_prepend_file directives for the Apache2 Module.

aldrinleal