16/05/2003 @13:59:21 ^14:42:27

tinkered site code

You may have noticed recently there have been periods where this site has been unavailable. Actually it's more likely you noticed snafu wasn't there, because let's face it the main page never has anything on it anyone would want to read, but the other sites we track here might do (even if we don't have comedy descriptions like Bex does)

1. Included pages, callback functions, and cache control headers

Recall my pages are accessed via having, say, ?p=foo on the end of the site URL. Now what happens is that the main code file index.php will php-include a file called foo.php and then call a bunch of support functions (in the included file, naturally) whose names start with foo_ (via PHP's call_user_func())

Two of these supports are pretty trivial, they just tell the main code which icon to use in the corner above the navigation bar and any extra bits to put in the <title></title>. Then there's one that is called before any content is written, which is used for sending out HTTP headers (the need for which was the point of this reworking) and a final one that does all the page content. Naturally this one tends to be a lot longer than the others, heh.

The outwardly-visible consequences of these changes are few, but in particular it means I can make the pages displaying regularly-updated information (e.g. snafu, webnewsstats) return specific last-modified times and other headers to try and coax non-retarded webcaches into ignoring them. This might fix a few problems people have been having with these pages failing to update.

2. Linking to specific entries

You may or may not be aware that to link to a specific entry on this site you can get the URL from the white box containing the dates, above each entry. It ended in the form ?t=TIME. The archive index was implemented similarly by having a link to the final update in a given month. The code would take this time (or whatever the current time happened to be) and return entries to either the start of that month or the start of the previous month (depending on whether or not TIME was before the fifteenth of the month)

The problem was that you'd get anything up to a month and a half's worth of updates prior to the one to which you were linking; this was fine for the archives, but bugged me for linking to specific updates. So the following change was implemented:

If TIME is exactly equal to the time of an entry, then you only get that entry. If not, you get the usual page of entries between that time and going back to the start of the month or the last month.

Then to do archive index links, for each month, we work out the epoch time of the start of the next month. Then clicking that link returns all the entries from the start of the previous month, up until that time. I decided that the chances of my writing an entry coinciding exactly with one of the month boundaries was sufficiently slim that this system was viable.

Okay that lot probably didn't make any sense so here's an example. If I link directly to this entry using ?t=1053089961 (that's the same link as you'd get from clicking on the white box above this entry) you'll get a page with only this entry on it. If however I link to one second after it - that is, ?t=1053089962 - you get not only this entry, but all the ones in May prior to it. If I link to one second before the time of this entry, that is ?t=1053089960, you get all of May prior to this entry, but not this one.

Got it yet?