Why a 3rd version of the Expiry Checker?
There are three problems with the existing Expiry Checker (version 2.4) that I want to address in this new version...- it can slightly delay pages being fully loaded - this is often visible to users if they watch the footer of the page - it may be browser dependent, but I've noticed it on my Mac, where the footer seems to 'click' a little bit to the right a short time after the rest of the page has loaded,
- it normally sends expired page reminder messages for pages that have been updated within the past week,
- it occasionally sends two (or even three) emails per expired page on a Monday morning.
I'm not really worried about the first point, and I suspect that any php script - now matter how quick to execute - may have a noticeable effect due to the overhead involved in simply loading the script.
The second point is the most frustrating. Page owners often get expiry reminder messages even though they know their scripts have been updated. (I normally warn them to ignore any expiry reminders they receive on the Monday after their page has been updated.) It's because if the page was updated on a Wednesday, say, by then it had already probably been recorded as being an expired page. Not only that, but locally cached old copies of recently updated pages could also give rise to false hits. I've known about this for a long time. I could have quite easily edited v2 of the Expiry Checker to check that each page was still expired before emailing the reminder message to the owner, but I never got around to it!
The third point is also frustrating. I think it's due to a failure to protect the critical sections of the script. The script does incorporate file locking, but I guess I must have overlooked some potentially unsafe interactions. I think what was happening was that somewhere during the processing of the
ExpiryData.xml file and copying its contents to the ExpiryDataLastWeek.xml file, another expired page hit caused a new instantiation of the Expiry Checker that interfered with the first in some way. I could have devised a mechanism to ensure mutually exclusive access to the script as a whole, but that might have exacerbated the first point!
Anyway, rather than try to fix v2 of the script I've decided to start again with what I think will be a better (and simpler) solution - see next blog post!