smackfoo.com | I find your lack of faith disturbing.

If you are a text-link-ads publisher and provide a canvas for the display of fine hypertext wares via the tla wordpress plugin, might I point out a small, but somewhat pivotal part of the process. Within the wp-options table is the row tla_last_update.

This little beasty stores the surprisingly boring yet none-the-less critical-for-functionality last update time — that is, the last time the publisher’s XML feed was fetched and ‘anything’ happened as a result.

Now, in the typical boring world we live in, this little dohicky will quietly update, in the background, every so often. But what might happen if the update time is wrong?

Well, obviously if the date and time was something like 2003-08-13 17:16:18, then obviously a check of the XML feed will happen pretty much as soon as the very next GET occurs for any template that carries the <?php tla_ads() > plugin hook. Because that date falls well outside the ~700 second update cycle, as of now.

“Ahh, but what happens if the date is in the future, yo?” — that’s a damn good question.. and here’s the answer.

Nothing. Nada. Zip. Zilch. Zero.

At least until well after the date rolls around. So if the date is incorrect, or the local server’s time is erroneous, such as 2009-08-13 17:16:18 then there will be no further updates until that date.

That’s a bit of a problem, particularly in this author’s instance, when TLA sent an email, indicating a newly minted sponsor’s listing hadn’t updated, thus they would immediately HOLD my account, for at least 24 hours, assuming the issue is cleared. If not, another 24 hours will roll past.

Thus the above was discovered after carefully inspecting the tla_last_update table and the discovery of the specific row and it’s erroneous content.

So the next question, obviously, is how can I prevent this from happening again? And that’s a little tricky, because how does one ‘know’ when the date is wrong? And how does one then fix the problem?

Well, from a SQL perspective, a way to touch the row and update it, might be expressed thus:

UPDATE `wp_options` SET `option_value` = '2007-08-13 19:05:01' WHERE `option_name` =tla_last_update AND `blog_id` =0 AND CONVERT( `option_name` USING utf8 ) = 'tla_last_update' LIMIT 1 ;

Obviously we want to ‘force’ an update - so setting the date and time to zero should do the job nicely. Creating a whole new db query seems a little overkill — indeed the task has already been done for us. So let’s take advantage of two get and update functions that already exist and simply updates the tla options in table wp_options:

< ?php
    // reset tla options to enforce update
    require("../wp-config.php");
    echo 'Updating TLA table..';  // fetch date
    $current = get_option('tla_last_update');
    echo 'Last update time was: '.$current;   // update date
    update_option('tla_last_update', '0000-00-00 00:00:00');
    $current = get_option('tla_last_update');  // echo results
    echo 'New update time is: '.$current;
    // add any further option updates as needed below
?>

In my case, I have dropped this in a php file, in a .htaccess protected directory, thus restricting the php to internal calls only. Create a weekly (or daily) cron job to access that via wget or some such other contrivance and you are done. Indeed this opens up a number of ‘options’ as far as automated option changes are concerned.

Indeed I have a small handful of db related cleanup jobs run weekly to help improve overall performance as it is, so this slotted right in. Or, you could simply drop the code into a suitable wp-cron accessed file if your web host does not provide cron access.

I’ve already sent feedback to text-link-ads suggesting they build in some date sanity checking to ensure a malformed future date (say > 3 days) is reset. So hopefully this will become redundant - but, well, until then.. I have it covered.

After quite some experimentation, much of it fruitless, that has resulted in a mass tug-of-war with Wordpress and it’s infernal re-write rules, the structure of the ‘foo has changed. This has primarily been driven by a fundamental flaw in Wordpress that will likely never be addressed, as it’s simply not considered a “problem” to begin with..

Whilst I am not at all pleased with the final result, it’s the closest I can come to a workable solution, that scales well and will be as ‘fluff’ free as I can make it.

It means I have to go back to using pages for semi-static content, rather than using a fluid rewrite rule set that blurs the lines to make pages and posts interchangeable.