Global Menu Options

[D Raymondson]

I'm maintaining a corporate website of several dozen pages. Currently, if I update the main menu, I have to change it on every page. I'd like to set up a global menu as a single document accessed by each of the pages. What are my options?

I'd like to stick to html5/css3 and avoid frames.

Our systems engineer suggests this approach: calling out a single javascript file from each html document and then embedding the menu's html and css into that javascript file. He's seen html embedded that way, and thinks it ought to be possible to include css as well.

Any thoughts?

With any solution, what are the SEO implications?

[ParkinT]

Welcome to Sitepoint.

This is one of the areas where languages that create pages dynamically have a bit of a leg-up. In PHP, or example, you could define a call to the same code that generates (renders) the global data you want on every page.
However, another alternative is to use a Server-Side include. Assuming your hosting server is configured to support it(90% chance it does).

Among the numerous people here with far more expertise and ingenuity than me, I am certain you will get several more ideas.

[Stevie D]

I'm maintaining a corporate website of several dozen pages. Currently, if I update the main menu, I have to change it on every page. I'd like to set up a global menu as a single document accessed by each of the pages. What are my options?

I'd like to stick to html5/css3 and avoid frames.

Our systems engineer suggests this approach: calling out a single javascript file from each html document and then embedding the menu's html and css into that javascript file. He's seen html embedded that way, and thinks it ought to be possible to include css as well.

With any solution, what are the SEO implications?

It's definitely worth changing it. The good news is that it's very easy to do.

I use SSI (server-side includes) on several of my websites. You just include a line like

<!--#include virtual="/menu.htm" -->

at the appropriate point, and the server will insert the contents of /menu.htm at that point. The included file should just be an HTML fragment, not a complete page, so that it makes sense in the context of the page(s) it's being dropped into. Then you just need to configure your server to parse .htm files as SHTML in order for the SSI to work (if you call them .stm or .shtml they will automatically be parsed as SHTML, but that involves renaming or redirecting all your current files, so it's easier to change the server settings); just add the following lines to your .htaccess file:

AddHandler server-parsed .htm

You can also use PHP to achieve the same result, but the code setup is different.

DO NOT use Javascript to call up the menu. It is a major accessibility fail, and will lock out a significant minority of users who then won't be able to use the navigation menu. That is likely to include search engine robots, so you would run the risk of pages on your site not being indexed if they could only be reached through this menu.

If you go down the SSI/PHP routes, there are no SEO implications. As far as anyone else is concerned, they've just been given an HTML page that has, within it, a navigation menu along with the rest of the content. They won't be able to tell that it has been 'included' and wasn't hard coded into the page in the first place. The only SEO implications are if you go down the Javascript route, but you're not going to do that, are you!

[ralph.m]

Here is a hopefully simple explanation of how to do this with PHP:

http://pageaffairs.com/notebook/enha...h-php-includes

[D Raymondson]

Thank you. We're now looking at the SSI option, in particular, so you comment was very helpful. We are currently hosted by Network Solutions, but may move to our own server this year.

What puzzles me is why "includes" aren't part of the core HTML.

[D Raymondson]

Thank you. I much appreciate your comment. an SSI looks like a good way to go.

[Stevie D]

What puzzles me is why "includes" aren't part of the core HTML.

Because it puts extra work on the server. If the server knows that everything in a file is just pure and simple HTML that it can send straight to the user-agent that's asking for it, that's a whole lot easier than if it has to read through every file looking for comments and then checking those comments to see if there are 'include' commands, and then actioning them.

And while that might not seem like a big deal now, remember that when the internet was being developed 20 years ago, computers, servers and connections were a whole load slower and less powerful than they are today.

Imagine you're a librarian, and any time anyone borrows a book you have to go through and wherever a town or city is mentioned, stick a tourist leaflet for that town or city in the book. That's a pretty big job, and it's going to really slow you down. Wouldn't it be so much easier if books that mentioned towns or cities had a nice big marking on the cover so that you could tell them apart? That way, any book without the marking on the cover, you could just hand straight over, knowing you didn't have to check through it – that would speed your work up immeasurably. It's a bit like that for web servers, except that they can read quicker.

[D Raymondson]

Thank you, again. That clarifies a bit, but look at it this way. In HTML and CSS both, there are ways to reference other documents in the web site file structure. For example, the IMG attribute is used to point to an image file (.jpg, .gif, etc.) that is not part of the .htm document itself. Multiple page can access the same image file. Similarly, why not forget about comments entirely and use a TXT or similarly attribute to do this with a snippet of text or a menu? I know that HTML doesn't work this way, I'm just saying--with a touch of moral indignation --that it ought to.

[Stevie D]

Thank you, again. That clarifies a bit, but look at it this way. In HTML and CSS both, there are ways to reference other documents in the web site file structure. For example, the IMG attribute is used to point to an image file (.jpg, .gif, etc.) that is not part of the .htm document itself. Multiple page can access the same image file. Similarly, why not forget about comments entirely and use a TXT or similarly attribute to do this with a snippet of text or a menu? I know that HTML doesn't work this way, I'm just saying--with a touch of moral indignation --that it ought to.

The key difference with <!--includes--> compared to other ways of referencing a file is that in all other cases, it is the browser that requests the file, whereas the browser never even knows that an <!--include--> has happened. So when you have an <img src="/image.jpg"> tag, the browser is reading through the code, gets to that line and then sends a note back to the server to say "Hey, could you send me /image.jpg please?", the server doesn't send it automatically. But if you've got <!--#include virtual="/menu.htm" -->, the browser never knows that part of the page was pulled from /menu.htm, as far as it is concerned, it was just given a complete page. What you're asking for is more along the lines of <iframe> or <object>, where a complete HTML page is inserted within another, but that only works with complete pages being inserted as a block, and so is less flexible than <!--insert-->.

[BillO]

PHP! Use an "include" to include the main menu, and keep the menu in a subfolder of your includes folder; i.e., "ncludes-->navigaiton-->mainmenu.htm." That way when you update the menu, you only need to do it in that one file.

[D Raymondson]

I wanted to let everyone know that we went the SSI route and have successfully implemented it. You can see the site at www.greatrivertech.com

Thanks to ParkinT, ralph.m, BillO, and especially Stevie D for their input.