Table of Contents [Show]
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 tag. These attributes are then used to generate the Table of Contents which provides links to the appropriate section the article. The table of contents is generated once per page any time that the array counter is greater than 0. This means either after the banner or at the start of any other page. The code simply looks for any defined "heading" attribute and populates a set of unordered lists. The "size" is used to determine how deeply nested that item needs to be depending on the size of the previous heading. As is discussed in the Easter Eggs section, the link to the particular content is simply provided by adding an "offset=N" attribute to the url.
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.
A homepage of almost any website is a special case. It's meant to provide easy and clear access to the information visitors might actually want without cluttering the page with much of that information directly. As such this is the only page that currently uses the "banner" code, regardless of my having made the code as modular as possible. It otherwise just provides links to things that seem sensible to highlight. Those blocks load in much the same way as the articles where each is an element of an associative array which is looped through. However this is the only place where that particular text block formatting is used.
One kind of neat thing on the homepage is the weather data. This is only useful to folks in Ottawa, but I actually use it directly or indirectly on a daily basis. All of the data is sourced using Darksky.net's API which allows for 1000 free calls per day, enough to update the data every 5 minutes. I have a simple shell script that fetches the data and translates it into another PHP associative array using standard UNIX utilities. It requires the API key as an arguments, but can then easily be run as a cronjob. The basic data is provided in a reasonably compact "widget" and the more complex data is hidden until various parts of the visible blocks are clicked. My Magic Mirror project actually fetches the same data file from the website in order to provide me with my current weather and the forecast information discussed next.
The "weather-data.php" file that is generated by the DarkSky script actually has a lot more data than what is displayed on the homepage, so I gave that data it's own page. Even then, darksky provides 50 hourly forecasts and I only use 7 (spaced in 3 hour increments), so as not to be overwhelming. The content is extremely standard and predictable, so I basically just copy and pasted the current weather code and made some small changes for the daily reports, like adding a neat-o phases-of-the-moon widget entirely with CSS.
The resume actually hails back to an earlier website that I made years ago called johnsdesk.ca. That site was cutesy, gaudy and a horribly skeuomorphic representation of what my desk might actually look like. To my chagrine Archive.org did save just enough of it to make it look even worse than it really was. When it was live, each of the images had an "active" alternative which replaced it and they all lead to pages that were similarly atrocious in their own ways. Remember, I said I was the runner-up to that web development job... It ways basically the "Microsoft Bob" of websites except uglier and even more useless. That said, I mostly kept the fundimental design of the resume page.
I rewrote the functionality of that page and it is now set on a tame grey instead of woodgrain, but the "dosier" concept with the headshot and tabs is still the same. It did actually get me to a second interview, so it can't be too horrible, right? Functionally, the main content used to load with an iframe which made the "paper" scroll independently of the actual webpage; so that's better now. One thing I do want to add to this is a URL argument with a unique id for the coverletter. That way there is default content page for anyone who finds it in the menu, but I could email a link to a potential employer with a coverletter specifically for them. If I get itchy feet this might become a priority, until then it's just a thought.