The solution might be the Page Links To plugin. My main concern with it is, looking at the code, it seems to hook pretty deep into the WP platform. If the platform changes, and the plugin isn’t updated, we’re screwed. Of course, tomorrow is another day 🙂
While researching the issue, I took a look at the existing code, and it was not pretty. Links have categories. Posts have categories. They appear to be separate sets of categories… but in the underlying tables, there is one category table, and one table that links categories to posts that also does double duty as the table that links categories to links. This is bad architecture.
It’s as if they couldn’t decide whether to treat posts and links the same, or different. The code eventually treated them completely different, so they should have rearchitected the tables to reflect that.
On the other hand, I can see the appeal of being able to use the same categories for links, and then sometimes select links and posts together. That’s why the Page Links To plugin exists. It’s too bad that the linking feature isn’t built-in to the posts. Having it built-in as a field would be trivial, but implementing it as a plugin that hooks into the system seems fragile.
In the old CMS, a bespoke system by Josh Haglund, which I have tweaked and modded, posts (known as stories) had a URL field. The decision to display the URL, or use the URL instead of the post, was left to the view (the template). There were no use cases that required logic for this – sometimes, we needed lists of stories, and other times we needed lists of links, but never really needed both. (Had we needed that, it would have been mostly an issue of adding display logic, or filtering the posts and then applying display logic. For example, it would have been feasible to extract links into a separate array, if we wanted them as a sidebar within a category.)
Conceptually, I think the old CMS was more correct than WP. A complete article is really like a fully expanded link. A link is like shorthand for the entire article. In between, you have excerprts, which are links with a summary of the article or a quote from the article. There are different sizes of excerpts, too – little thumbnails, big thumbnails, short quotes, long quotes. All these things enable different kinds of links – and they are all proxies for the entire article.
I can hear the programmers’ objections already: “a link is a pointer, it’s not the object itself.” Yes, true. But if you ever programmed in C, and then in C++ or Java, you know that when you treat pointers as the object itself, life is a lot easier. PHP variables are references. It’s easier to have references act like the referred-to object than as references that need to be explicitly de-referenced.
Somewhat analogously, links are like the object to which it points. Ultimately, the user/reader/programmer will want at least the title of the object, so that a human-readable link can be rendered. Most of the time, you want even more – you want a thumbnail, video clip, maybe an audio clip, a teaser, or a pullquote. Maybe you even want a copy of the article, just in case the original is pulled, or so the link is searchable locally.
Going forward, I’m going to always have a URL field in my stories table.
Getting back to WP, the way to handle the display is already supported by a feature called Category Templates. WP has a search order for template files, based on the category; the files have to conform to a naming convention. I was about to implement this, when I read the code for the template we’re using, Trademark.
Trademark’s template is in loop.php, and it has a lot of if-then logic to choose the template. That partially subverts the category template system.
I’m probably going to have different category templates, and two different loopN.php files, one for the regular case, and another one for lists of links. Our uses cases don’t have mixed articles and links: you’re either reading links to internal posts, or you’re reading lists of links to external sites.