There are commercial content management systems which may be preferable to building your own, but let's look under the hood of this one anyway to get an idea of how they work. This chapter also looks at constructing a search engine to index documents with metadata.
Presenting Web Pages using Templates
Why a Content Management System: There are two reasons for approaching site development with an eye to building a content management system. One is the notion of a team-supported site, as outlined in the text (p. 626-7), making it easy for writers or graphic artists to develop and insert content without knowing much about web technology. The other stems from consideration of the post-launch life of the site and the question, "who is going to maintain the site?" If non-web staff will update content, a CMS is the best way to set this up (and to extricate yourself from that task).
Site Requirements: This projects facilitates writing and editing content that is displayed via templates, restricting access appropriately, while allowing a balance between consistency and flexibility in site layout.
Existing Systems: Writing your own code gives you control and flexibility at the cost of substantial development time. The more you want it to do, the hard is the programming task.
The Mechanics of Loading, Storing, and Editing Content: Getting files into a system could be done with ftp, but development of control mechanisms to link text to images, etc., makes this too difficult. You can upload files via the browser (see chapter 18), which would allow you to handle it any way you wanted (e.g., store it is a database, or a file); this is a good way to handle images. You can also allow online editing in a large textarea, which is efficient but provides limited editing facility (e.g., no spell-checking, no bold or other formatting); the contents of the textarea could then be stored as text files or in a database. Images can be stored within a MySQL database (as they can in MS Access, etc.), but it is better to store them as server files, putting the directory into the database (the main issue is a performance hit when objects are stored using MySQL BLOB data). The fields created to store articles in a database obviously grow as the structure gets more complicated; the bare minimum involves headlines, body text, and images, but various subheads could also be used, as well as figure captions.
Metadata: Beyond the story's text, images, and headings, there are metadata, which are bits of additional information which can be stored with the story. These include the name of the author, keywords (normally stored in an html <meta> tag), timestamps (latest modification), etc. These can be formally organized in the database and later used for presentation (author) or search (keywords).
Basic Page Structure: Content is displayed within a typical page structure, including modules for the header, footer, style sheets, and menus, to allow efficient site-wide updates. Files for this application are listed in table 28.1 (p. 630-1), and of course are available via ftp on our class server (...common/Welling/Source/28).
Database Design: Create_database.sql (listing 28.1, p. 631-2) is the schema for database "Content," which contains tables writers, stories, pages, writer_permissions, and keywords, along with permissions.
Site Design
Front End: Index.php (fig. 28.2, p. 635; listing 28.2, p. 633-4) sets up the basic page, includes functions, and displays page descriptions and headlines, with images. It includes header.php and footer.php and uses two database queries to get pages and stories in reverse order of publication, with the headline serving as a link to page.php (fig. 28.3, p. 637; listing 28.3, p. 635-6). Page.php has two queries, one for particular stories and a second for all stories.
Images may come in various sizes, and you may want to display a single image file at different sizes in more than one place. Resize-image.php (listing 28.4, p. 638-9) provides one means to resize images; doing this on the fly may be time consuming, but it is better than simply setting width and height attributes within <img>, which will not affect the image size that is downloaded (a high resolution, large-dimensioned image might be downloaded to produce a smaller web image, wasting a lot of download time). This script can be called from within an image tag, meaning that only the resized image will be passed to the browser (see chapter 21).
Back End: Stories are added through the back end, of course, using writer.php (fig. 28.4, p. 640; listing 28.5, p. 641-2). After a write is authenticated (a login form is presented if needed, form data is checked against the database, and a session authentication will be set, etc.), a list of that writer's stories is displayed; there are also options to add a new story, or to edit or delete, and to set search keywords; a logout option is also standard (unsets the session authentication). Timestamps for creation and modification date are also stored.
Entering or editing a story is done with story.php (fig. 28.5, p. 644; listing 28.6, p. 644-6). The selected story fields are returned from the stories table using function get_story_record(). If no story was selected, query_select() generates a form with drop-list of all the stories by this author. After the fields are edited, form action takes you to story_submit.php (listing 28.7, p 647-9) for updating or adding to the database. Delete_story.php (listing 28.8, p. 649) handles story deletion, including a check to see that the user has permission to delete.
Searching
Keywords: Setting keywords is initiated from the "keyword" link on writer.php, which goes to keywords.php or keyword_delete.php (fig. 28.6, p. 650, no listing).
Searching: Searching by keywords is done by search.php (listing 28.9, p. 651-2)--->...to be continued.