Table of Contents [Show]
There is a "page.php" file which is pretty much the first thing to load on almost every page. It doesn't generate anything visible on the page but is essential to making other things work. For instance, it processes the URL arguments to determine what content to load. It sets up the base URL that will be used for most of the links on pages. It sets the meta tags in the \so that the title of the browser tab and the description of the page reflect its contents. It also loads the Google site verifaction, viewport size and other basic page information. Another fairly unused thing that it loads is error reporting code. This is used if an invalid URL argument is provided, but is flexible enough to do a lot more. I just haven't added tests for some things that I normally would if this were something I was being paid to support.
Each article is generally previewed in a couple of places. The first is the banner on the home page which provides the thumbnail and the description as hover text. The second is on the respective list page depending on whether it was classed as a project or a journal. That page provides a more robust preview with the full title and the descriptions as actual text. That same information is then included in the article itself. These all share a common source for that information which is a "meta.php" file in that article's directory. That file also provides the edit date which the lists use to sort the articles and which is displayed in the article itself. The list pages do a "glob" search through either or both of the journals and projects directories for any folders that have a "meta.php" file. They then populate an associative array with the path to those folders and the date, title and description information. None of the articles contents are included. Once sorted, the only other file needed for the lists is the thumbnail which is always in the article folder and always has the name thumb.ext, where another glob search will find any image file extension with that name. All articles of each type use the same page to load the article contents, the only distinction for the URLs used by each is the "topic=name" argument.
Anatomy of an Article
Each article on the site is defined by a sub-directory which is not directly fetched by the base URL. The URL string has a "topic=" argument which tells the PHP code which sub-directory to load the content from and it dutifully does so. The sub-directory consists of two main files, the "meta.php" file used for the list page and the "content.php" file used to provide the bulk of the text content. There is at least one thumbnail for the banner but there can also be another for each block of text as well as larger images and galleries of images. I will describe the purpose of each further.
foreach ($content as $item)
Given the "topic" argument, the "article.php" page will simply load everything it needs from a directory with that name. The most important of these files is "content.php". This is another associative array which stores the content of the entire article in a fairly human readable format. I'm considering moving article content into an actual database system, but that adds an extra level of complexity and security considerations that isn't really necessary at this point. There are some additional steps to load the content of the page, but primarily the "article.php" page just loops through all of the elements of that array and prints them.
It has a few options when loading each array element. There is the article banner, a block of text like this one, a thumbnail and text combo that flip-flops sides depending on the array counter, and then there is an under-utilized gallery. The banner is always and only used for array element 0. The thumbnails are used if there is a description defined in that array element with "thumb"=>"description". It then also loads a lightbox with a large image if there is a description for that larger image with "img"=>"description". If the "thumb" is not defined then it is treated as a block. The images use the same glob search as is used for the list pages except that they look for a thumb or image file with the array element number before the extension. Thus "thumb.jpg" is the preview thumb, "thumb0.jpg" is the thumb used for the banner, "thumb1.jpg" is the thumb for the block immediately after the banner and so on. If there is not a thumbnail for that block there simply is not a file with that name and no description is provided in the array.
The banner in general doesn't have much in the "content.php" file because it takes its attributes from "meta.php" where possible. For a couple of hidden articles those might be manually defined in the absense of "meta.php". The gallery sections also don't contain much content. It simply has a "gallery" attribute used for the gallery name, and "content" for the text used for the gallery link. The gallery name is used to fetch the images, their descriptions and to generate a set of lightboxes with these. Again, this is done with a glob search of that directory for "gallerynameN.ext". However, there is also a "galleyname.php" file for each gallery in the article directory which contains the description for each image as an array where the array position matches the "N" of the image filename. These are sorted and the lightboxes are loaded in a similar manner to others except that it has forward and back buttons and the image description gets a counter of where the viewer is in the gallery.
Table of Contents
Each array item in the content.php file has an optional "heading" attribute for that section. That attribute defines the content of the heading while one called "size" defines it's heirarchy in terms of an HTML
The "offset=N" tells the page generation code to skip to the Nth elements of the array before starting the print loop. The generator then has a separate variable that tells it how many loops to run for that page. This is normally hard-coded at 10 but can be overridden - again, this discussed in Easter Eggs. If there is currently any offset greater than 0, then the very first thing that is added to the main "Content" section of the page is a pagiation tool to go back to the previous content. Likewise, if the loop finishes before the entire array has been printed then a pagiation section will be added to the bottom with a link to the next page. In both cases, if there is content in the other direction then a link is also added for that direction for convenience. Both will have a page counter if the current offset is a multiple of the number of elements displayed per-page. For instance, given the default of 10, this means that "2 of 3" will be displayed if the offset is 10 and there are between 21 and 30 elements total. If you use the Table of Contents you may land on a page that is not an even multiple and so the page count is not shown.
A similar section gets added at the bottom when the end of the array has been reached. This allows the reader to jump to the next or previous article of the same type as the one being read. This is done using the same technique as is used to generate the lists of articles but it only uses those that fall immediately before or after the current article in the sorted array. This also directs the reader back to the list of articles of that type. Facebook taught me that you've gotta keep users on the site for them sweet, sweet page views (although I'm not sure how I'm going to monatize those...).
Some pages of the site are fairly stand-alone. They have all had as many elements as possible abstracted away to remove code duplication and to make it easy to replicate the same behaviours elsewhere but, in general, much of that has not been used elsewhere, nor is there a very automated way of replicating behaviour like exists for the articles and list pages. That said, each has something interesting to discuss.