One thing I always wished I’d had in my last “real” job (as an editorial director) was a way to link from web content I was currently writing to content I knew we were creating in the near future. A future URL. Of course, I could have just written in the links, but they’d by definition have been broken, at least until the scheduled pieces actually went live.

TLDR: I wrote a WordPress plugin to do it, which, if it’s of any use to you, can be found on GitHub here.

Back at the old job, we were, in point of fact, required to find places to link to our new content from existing older content and there were people on the staff tasked with editing the older stuff and putting those links into the older posts. And going to this extra trouble absolutely made sense from an SEO standpoint (and still does, and is routinely ignored by content teams far and wide).

What I wanted was a way to embed the link, but not have it go live until a certain date. Now that I run my own shop, it occurred to me that there was no reason I couldn’t just build this for the current WordPress-based version of PeakZebra.com.

Now, part of the point of PeakZebra is to migrate from WordPress to a Jamstack site, something I’ve written about here and here, to take a couple of examples. So I didn’t want to create something that would break on a static site. As we’ll see in a moment, I can actually do a somewhat better job of this forward linking in a hybrid site that’s half statically generated and half dynamic WordPress.

Plugins and Filters

To handle the job in WordPress one wants a plugin. From my point of view, there was no reason not to write this in PHP, the core WordPress language. Architecturally, WordPress operates by executing a series of “actions” and “filters” as each page is dynamically created and served to requesting web browsers. The execution of each action and filter is hooked to various functions, and a developer writing a plugin gets most of the work done by hooking custom functions to the appropriate actions and filters.

As an aside, actions and filters are secretly the same thing, so basically all I’m saying here is that I can pick a moment in the page-creation cycle and tell WordPress I want it to call a custom function I’ve written at that particular moment.

In this “future url link” scenario, all I really want to do is grab the main bunch of content on the page (what we’d typically call the blog post), search for my special kind of date-sensitive link, and enable or disable it before letting WordPress continue to serve up the page.

The Future URL Format

I called the primary function for this processing “handle_future_urls” and then hooked what is arguably the most important of the WordPress filter hooks, namely “the_content”. Setting up the callback looks like this:

add_filter( 'the_content', 'handle_future_urls' );

This statement is the first bit of code in my plugin and it executes as WordPress is getting ready to serve a page. Later in the process, when the page’s primary content has been called up from the database, WordPress will call my function handle_future_urls();

When that function gets called, it’s with one parameter, $content, a string that contains all the words that make up the center of the page. This can be lots and lots of words—it’s all the stuff on the middle of the page that isn’t the header, footer, or sidebar widgets.

You’re handed the content, you do whatever you want to it, and then you return the modified string of content from your function. In all honesty, it’s easy peasy and I think it makes it clear why WordPress has proven to be so extensible, versatile, and popular.

In this case, I decided I’d work with a format that put the future link not in the standard HTML a tag, but in a nonstandard tag that took this format:

[[http://example.com/theurl|September 1, 2021]]then some anchor text[[end]]

It’s probably pretty obvious how the future URL format works. If you put a link like that while you’ve got the futureURL plugin loaded and activated, you’ll either get a link in your copy or you won’t, depending on the date when it’s being viewed.

It’d be nice if the page updated to just an ordinary URL once the date had passed, just to save processing time. So… that's coming along… And in case you were wondering, yes, there is a future link embedded in this paragraph, linking forward to the post I'll write when I've made that update