Content Management

---

Maintaining content is just as important as maintaining the server itself. Large sites or those with numerous contributors will quickly degrade if special care is not taken. First, make sure there is a set policy for naming files. For example, consider avoiding using special characters such as underscores (_) in filenames because it will be difficult for users to notice them in the address line of a browser. Instead of robot_butler.htm, consider robot- butler .htm or just robotbutler.htm. However, be careful with using filenames such as RobotButler.html or even capitalizing directories. The domain aspect of a URL is not case sensitive and the user might not be consistent in his or her use of case. Also, some servers such as UNIX systems are case sensitive, whereas others such as NT are not, so moving sites between the systems could be troublesome . Always use lowercase to avoid such problems. Shorter extensions generally are better if you just consider the extra characters to type, as well as the fact that some older systems prefer three-character extensions. However, regardless of your take on .htm versus .html, pick one and be consistent.

If you are really aggressive , it is even possible to remove extensions from your URLs directly. In such a case, you will no longer reference files in links like

  <a href="products/robot.html">Butler Robot</a>  

but simply use

  <a href="products/robot">Butler Robot</a>  

Even media objects will no longer have extensions, so

  <img src="/images/logo.gif" alt="logo" />  

becomes

  <img src="/images/logo" alt="logo" />  

There are significant advantages to cleaned URLs without file extensions. They allow you to change the underlying technology at any time. So instead of referencing a GIF image, you are referencing just an image and letting the server and browser decide if a GIF, JPEG, or PNG should be sent. This is called content negotiation and is a powerful idea that should see more usage in the next few years .

Regardless of whether you use file extensions or not, consider limiting filename length, or using consistent naming schemes. For example, some files such as press releases may include dates in them. Consider that pr021299.html and pr010500.html could reference press releases on February 12,1999 and January 5, 2000, respectively. Coming up with a reasonable format can really help people find and manage information.

Make sure to use the same care with directories that you do with files. Pick short, easy-to- type and -spell directories in all lowercase letters that lack special characters. Also, consider using common directory names to hold site assets. Table 17-1 details a few common directory names and their usual contents.

Probably the most difficult aspect of dealing with site content is managing all the changes that are made. When many people are working on a site, it is easy for conventions to be overlooked and for simple errors to be introduced. To reduce the possibility that content degrades, first carefully limit who can make changes to a site. Second, resist the desire to fix site problems or add content on a moment's notice. It is far better to make regular updates, such as once a day or once a week. This allows backups to be made and provides a stable base to roll back to in case problems are introduced.

If a site is heavily updated, consider employing a content management tool. A simple source code control system can be used. A source code control system will provide an audit trail and rollback facilities, and will force site contributors to check out pages to make changes to them. More powerful content management systems that include easy-to-use, browser-based front ends, including form-based page editing, can be built or purchased. The Demo Company site (www.democompany.com) itself uses a very simple version of such a tool, as shown in Figure 17-5.

Figure 17-5: Demo Company's content management system

Table 17-1: Common Site Directory Names

Directory Name	Contents
/cgi-bin	The traditional location for executable programs on a Web server, particularly CGI programs.
/scripts	Contains scripts for the site including JavaScripts, CGI scripts, and server-parsed languages such as Cold Fusion or Active Server pages. Occasionally, the directory might be named after the type of script stored; for example, /js or /javascripts for linked JavaScript files.
/styles or /css	Should contain any linked style sheets used on a site.
/images	Contains all site images, including GIFs, JPEGs, and PNG files.
/video	Contains video assets-primarily non-streamed video clips.
/audio	Contains audio assets-primarily non-streamed audio files.
/ pdfs	Contains PDF files such as a library of datasheets .
/download or /binaries	A central location for any programs or software distributions that are to be downloaded from the site.

Regardless of the methodology used to control the update of a site, one rule cannot be stressed enough: Never work directly on a live site . Consider that users might see your changes as they happen, and even see pages in half-finished form. Furthermore, if any serious blunder is made, it may be difficult to recover from if the live site is being edited directly.

Rather than working on a live site, consider using a three-site architecture as illustrated in Figure 17-6. First, set aside a development server where a copy of the site is kept and major changes and programming features can be added and tested. Second, create a staging server with an exact duplicate of the published site. The staging server is where changes are made and tested . Lastly, a production server should be utilized to actually hold the site being delivered. Changes should only be made on the development or staging site, which is later synchronized with the production server.

Figure 17-6: Three Web servers are better than one

As Web sites become more and more important to organizations, the care and feeding of sites and servers certainly will be treated with increased seriousness and procedures and policies will be adopted to ensure that changes are made properly.

---