Planning Your Page Layout for SSI
When you first think about using server‑side includes (SSI) on a website, the idea of juggling dozens of HTML files can feel overwhelming. But the secret lies in the layout you choose. Think of a layout as a skeleton that holds all the moving parts together. By deciding which sections of every page will stay the same, you make the rest of your life easier.
Start with a simple, repeatable pattern. Most sites use a header at the top, a footer at the bottom, and sidebars or content blocks in between. Decide which of those you need. If you only have a header and a footer, that’s fine. If you want two sidebars, add them. The more sections you can isolate, the fewer lines of code you’ll have to update when you change a logo, a menu, or a copyright notice.
Sketch your layout on paper or in a design program. Even a rough wireframe helps. Notice the vertical space between header and footer. Consider whether you’ll need a second header row for a sub‑navigation bar or a banner. If you foresee future growth, give yourself a placeholder for an extra bar and leave a small gap where you can insert it later.
Remember that the layout is not just visual; it’s structural. It will guide how you split the HTML into files. Keep the main content area separate from the static sections. In practice, this means you’ll create a template that includes the header, footer, and any sidebars. The page‑specific content will live in the middle of that template.
Once you have the layout fixed, think about how you’ll manage the CSS. Keep the styling in a separate stylesheet so you can tweak colors or fonts without touching any HTML. If the header is white, set its background color in the stylesheet, not in the file you’ll include. This approach keeps your included files clean and focused on structure, not design.
Now that you have a clear visual map, you’re ready to translate that into a reusable template. The goal is to write the template once and reuse it across all pages. The template will contain SSI directives that pull in the parts you defined in your layout. It’s the foundation of the dynamic content strategy.
Building a Reusable SSI Template
The first time you create a template, treat it like a blueprint. You’ll open a new file with the .shtml extension so the web server knows it needs to parse SSI directives before sending it to the browser. Inside, write the standard HTML header, meta tags, and a link to your CSS file. Keep this section minimal; the bulk of the file will be the table structure that holds your dynamic sections.
Below the head tags, you’ll place an SSI directive to include the header. The syntax is straightforward: <!--#include file="header.html" -->. The file name can be anything you prefer, but keep it short and descriptive. Once the server processes the page, it will fetch header.html, insert its contents, and send the result to the client.
After the header, add a horizontal line or a blank row for visual separation. It’s helpful for debugging because you can see where each include starts and ends in the raw HTML source.
Next comes the main table that holds the sidebars and the content area. Use a two‑column layout: the left column for the first sidebar, the center for the page content, and the right for the second sidebar. Each cell will have its own SSI directive. For example, the left cell could contain <!--#include file="sidebar1.html" -->, while the right cell has <!--#include file="sidebar2.html" -->. The center cell will hold the content specific to each page. When you create individual pages, you’ll copy the template, replace the middle cell with the page text, and save the file with a unique name.
After the table, include the footer in the same way you included the header: <!--#include file="footer.html" -->. That way, any change to the footer file propagates instantly to every page that uses the template.
Finally, close the body and html tags. When you save the file as .shtml, your web server will process all SSI directives and deliver a complete page to the browser. The beauty of this method is that the only time you touch the template is when you add or remove a static section. You never edit the actual content of each page to change a logo or a link.
Creating and Managing Included Files
Now that the template is ready, the next step is to create the files that the SSI directives will pull in. Each file - header.html, footer.html, sidebar1.html, and sidebar2.html - should contain only the HTML that belongs in that section. Keep them simple: no scripts, no repeated meta tags. If you need a script in the header, place it in the main stylesheet or use a separate include for scripts.
When you design the header file, think about navigation. Use a <nav> element with unordered list items linking to the main sections of your site. If you plan to add a secondary navigation bar later, leave a small gap or a comment in the file so you know where to insert it. The header file can be as minimal or as complex as you wish, but avoid hard‑coding colors. Use CSS classes that the header will share with the rest of the site.
The footer file is similar. It usually holds copyright information, a link to your privacy policy, and perhaps a small list of partner logos. If you want a newsletter signup form, put that in the footer. By keeping the form in an include, any change to the form’s action URL or styling is made once, not on every page.
Sidebars can contain anything from recent posts to a search box. If you have a sidebar that will change often, keep its content in a separate file and include it in sidebar1.html or sidebar2.html. That way, you update the sidebar content in one place and all pages automatically show the new information.
When you first upload these files to your web server, place them in the root directory. This makes the include paths simple: just file="header.html". If you need to organize them into a subfolder, you can, but then you’ll have to adjust the paths accordingly. Also, always use the virtual method for simple includes. The exec directive is for executing scripts, not for pulling in static content.
Remember that if you reference an include file that does not exist, the browser will display an error message inside the page. That’s why it’s important to keep a placeholder file - even if it’s empty - for every include you plan to use. It’s a small safety net that prevents broken pages when you add a new sidebar later.
Deploying and Testing Your SSI Setup
With the template and included files in place, the final step is to create a few test pages. Copy the template, replace the center cell with unique text, and save the file with a .shtml extension. Upload it to the same directory where the template lives. Open the page in a browser and inspect the source to confirm that the header, footer, and sidebars appear correctly. If any include is missing, the page will show a placeholder message; fix the path or create the missing file.
Once the test pages load correctly, you can scale up. For a 50‑page site, create 50 .shtml files, each with its own content block. The only effort needed is to keep the static files - header.html, footer.html, sidebar1.html, and sidebar2.html - up to date. If you decide to add a new link to the footer, edit footer.html once, and every page will instantly reflect the change.
Testing on a staging server is advisable before going live. Check that the server is configured to parse SSI directives. On Apache, the Options +Includes directive must be enabled for the directory. On Nginx, you’ll need to use the ssi on; directive in the server block. Without these settings, the includes won’t run, and you’ll see the raw SSI tags in the browser.
Performance is another factor to consider. SSI adds a small overhead because the server must read and combine multiple files for each request. For most sites with low traffic, this is negligible. If you have high traffic, consider caching the generated pages with a reverse proxy like Varnish or use a content delivery network that supports SSI.
In the long term, SSI can save you hours of repetitive editing. By centralizing static sections, you reduce the risk of inconsistent links or mismatched branding. Whenever you need to update the site, you do it in one place, and the entire site reflects the change automatically.
No comments yet. Be the first to comment!