Previous Page

Next Page

Table of Contents [ Show]

I'm pretty happy with where things are at right now. I will continue to update the software that is currently in use, but I doubt it will change significantly aside from adding features to my PHP code. I may upgrade to a more powerful VPS if that becomes necessary, but this would be more likely to happen if I add on additional services like GitLab or NextCloud. Web traffic is unlikely to take me down any time soon. UPDATE: It did happen, at the time of writing, the VPS had 1 core and 2GB of RAM. I did end up installing a Git server, moved my email filter to a VM on this same machine and run a bunch of other containers and applications here now.

The Code

The following discusses the basic mechanics of how pages on the site are generated. There are only a few basic classes of pages and then a few special cases that are still relatively static.

Common Files

There are a few visible page elements that are used on most or all pages, however there are also several that work in the background that are quite important. The obvious visible examples are "header.php" which loads the top banner. There is then also the social media column on the left, creatively loaded by "left.php". Then there is the Social/Contact boxes loaded with "contact.php" which don't exist on all pages but which are pretty widespread. Many other visible elements like the banner on the homepage are written to be as modular as possible, but have not yet found uses elsewhere.

The only visible thing that is particularly notable about the header is the Easter Egg explaining the site name, as discussed earlier. That said, it does serve a few other purposes. Notably, it loads the "lightbox" functions which display and hide the large images. It also uses those functions for an optional "Under Construction" shade which it defines but hides by default. Finally, it also loads in some CSS.

Both the left panel and the "Social" section of the Contact block fetch their links from a specific file. This file lists my social media details as an associative array including the name of the social media site, the location of the image used and the external link to my profile on that site. Each of the two blocks then loads it in using it's own rules. The site is mostly mobile-friendly in that the content re-flows and generally fits nicely onto a small display, however it is not actually responsive to the actual page width given that PHP does not get that information. As a result the "Social" section only display 3 images with the rest hidden under the fold because this seems to be the most that will fit on really small displays before line-wrapping. One of the images used, I cannot recall which, was pulled from a creative commons site and altered slightly and I made the rest to replicate that style with Inkscape.

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.

List Pages

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.

Previous Page

Next Page