You should think about site architecture before you create your first content page. Site architecture should be arranged so that you can make global changes to the look and feel of a site with no impact on the content. You also want to be able to change the code for an ad program, or even swap one ad program for another, once and have the changes take effect across your site in all the content pages.
When you create content websites, it’s imperative to use mechanisms that separate web page content from design. The purpose of separating content from design is to let you:
Easily change the look and feel of a site without the change in overall site design having any impact on the content
Tweak positioning and other ad-related variables to maximize revenue without having any effect on site content
The simplest way to achieve these goals is to use includes—server-side includes—to position site graphics such as navigation bars. A server-side include is a file that the server includes within another file (the inclusion is specified by a special directive). When you view the HTML source code in a browser, you have no way of telling whether the main file was generated using includes or not.
Includes can also be used for advertisement code, such as that provided by Google’s AdSense. By changing the code in a single include, you can change the navigation bar or advertising parameters across all the content pages on an entire site.
The most important thing, as a content web publisher, is to be on board with the concept of separating design from content, and advertising content from normal page content. The overriding reason for doing this is so you can tweak both the site design and the advertising content.
The mechanics for separating advertising content, published content, and design aspects of a site are fairly simple.
Server-side includes work well to separate key design elements (and advertisements) from content, provided your content site doesn’t have too many pages, and assuming that each page doesn’t have a great many repetitive elements.
If many of your content pages are essentially the same—meaning they have the same elements but the value of the elements differs from page to page—you should probably be using a templating system. Templates use special tags for the common elements, with the actual content for each page that replaces the special tag specified, often using content stored in a database table. This means that an appropriately written template file and one or more database tables can populate and create a whole raft of web pages—one for each row in the table.
PHP is one of the most popular server-side programming languages available on the Web (most inexpensive Linux/Apache web host services let you program in PHP without any additional configuration effort).
If you are a programmer, or have access to programming talent, you can create your own templating system using PHP or some other language. But why reinvent the wheel? A popular PHP templating system, available for free download, is Smarty. One of the great features of Smarty is that it caches a web page the first time it is generated from a template. Subsequent calls to the page, unless the template or data have changed, open the cached page—meaning the website isn’t slowed down by page generation each time the templated page is opened.
A server-side include mechanism is a great start for creating a manageable content site and—from a technology standpoint—within the grasp of almost anyone. (I explained the server-side include mechanism and how to use it to lay out a content site to receive advertising in Content Architecture.)
Templating is a good next step if you (or an associate) have the technological sophistication and expect to be managing content sites with thousands of pages. It’s particularly important to use a system of templates if you expect to generate pages using data from a database.
Suppose you are managing a site with not thousands, but hundreds of thousands of pages. You have multiple authors, a team of editors, and a workflow process to make sure that work is fact-checked, copyedited, and approved before it is published. In this case, you’ll want to use Web Content Management (WCM) software to provide content and design separation, template features, workflow management, and more. Commercial WCM packages are available from vendors including IBM, FileNet, Interwoven, Microsoft, Stellent, Vignette, and others.
Note
Not everyone recognizes that, in fact, blogging software such as Movable Type and WordPress in effect manages web content using special tags and a template system. You can use WordPress in particular to manage pages that are not part of a blog. So if it’s appropriate for your particular project, consider creating a “blogosite”—a content website managed by blogging software such as WordPress.
No matter what mechanism you use, it is vitally important to separate form from content so that you can easily keep your site design fresh and tweak advertising positions.
The simplest mechanism for implementing a “change code in one place, change the whole site” architecture is to use server-side includes (see Separating Content from Design).
Most web hosting accounts provide a server-side include mechanism. You tell the web server which file extensions mean that a file can have includes. When the web server processes the file to send back to a browser for display, it looks for the special syntax that means there is an include. When it sees this syntax, it expands the page it is serving to the browser by expanding it with the file indicated by the include’s syntax.
The default file extension for a web page is usually .shtml, although you can add other file extensions so that your web server will look through them for includes (there is, of course, a slight performance hit for this).
Figure 1-8 shows a typical Linux and Apache web host administrative utility with the mouse cursor pointing at the button that lets you add file extensions to be parsed for includes.
For example, suppose you have a simple .shtml home page like this:
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> <head> <title>A simple little home page</title> </head> <body> <h1>Hello!</h1> ... </body> </html>
You could create two include files:
Note
You can link to an external CSS style sheet or define your CSS styles in an include file. Either way, to change styles site-wide, you just have to change the style definitions in one file.
The site home page, and every other content page on the site, includes these two files as follows:
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> <head> <title>A simple little home page</title> <!--#include virtual="includes/styles.html" --> </head> <body> <!--#include virtual="includes/top-bar.html" --> <h1>Hello!</h1> ... </body> </html>
Now it’s easy to change the appearance of the text on each page of the site by just making one change to styles.html. And, if you need to change the appearance of the navigation bar, you can simply make the changes to top-bar.html, and it will be replicated across the site.
Note
There’s generally no requirement that included files be named with any particular file extension—instead of .html you can perfectly well use .foo, or anything else you’d like. One tip is to avoid a file extension that begins with “z”—some search engines will assume it’s a type of .zip file and they won’t index it!
If you are constructing a dynamic site using PHP (see Separating Content from Design) or using PHP for other programmatic purposes on your site, it makes sense to use the PHP include mechanism.
Note
Whatever technology you use to serve your site, it undoubtedly has an include mechanism that works pretty much like server-side includes and PHP includes.
Most Linux- and Apache-based web hosts provide PHP scripting automatically for files named with a .php file extension. Within these files, PHP includes work almost exactly like server-side includes.
For example, suppose you have a simple little web home page in a file named index.php:
<html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Simple Little Web Home Page </title> </head> <body> ... </body> </html>
If you put the CSS styles for the elements of the website, such as the appearance of website text, in a file named style.inc, it can be included in PHP code like this:
<? include 'style.inc'; ?>
The code for the top portion of a page, to be shared in common across the site, might be put in a file named top.inc. It could now be inserted at the top of the body of a content page using the PHP include directive:
<html xmlns="http://www.w3.org/1999/xhtml"> <head> <title> Simple Little Web Home Page </title> <? include 'style.inc'; ?> </head> <body> <? include 'top.inc'; ?> ... </body> </html>
As with the server-side include example, if all the pages in a site use the PHP directives to include style.inc and top.inc, then site styles and the top element can be changed globally just by changing the contents of these include files.
Note that you can include PHP code—including other PHP include directives—within PHP includes, and that there is no requirement that includes be named with any particular file suffix.
The optimal include layout is to provide includes for both geographic areas of your web page and for specific ad programs. The two should not be the same, although one can go inside the other, and (at least initially) consume all its area. If you don’t follow this organizing principle, down the road—to take one example—you’ll find that you named the include for the entire right side of your content pages Google_ad_right, even though by now it contains a variety of graphic elements, but no Google skyscraper.
The composition of PHP includes used on a site with optimum flexibility is shown in diagram form in Figure 1-9.
Figure 1-9 shows that there is an include for each geographic area of a page that will carry graphics or ads: top include, left include, bottom include, and right include. Within the geographic includes are ad-program-specific includes for each ad program or type of ad, such as a Google ad module. A final include holds a navigation panel at the top of the site above the page individual content. The point here is to allow for flexibility both in terms of page geography and in the ads or ad modules that will appear on specific pages.
This arrangement gives the maximum flexibility and won’t have you contorted like a pretzel in the future. You can change any of the graphics in a geographic include. Alternatively, you can change ad code, swap, add, and delete ad programs in a very granular fashion. Changes take place globally across a site, but they have very little impact on the rest of a page.
Get Google Advertising Tools, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.