Solving peanut brittle WinerLinks, part one

With the way the WordPress plugin works right now, WinerLinks are added every time a post is rendered. There’s a bit of script to parse for ‘p’ tags, and it will add the hash at the end of the graf and the anchor at the beginning. This works fine if you edit before you publish but a lot of people continue to edit a piece after it’s been pushed live. If you add or subtract a graf, a variable number of your WinerLinks will point to new locations. Oops.

Permalinks should be permanent. If they aren’t, you’re sinning against the web. The challenge with paragraph-by-paragraph permalinks in WordPress is that content is stored at the post level, not the paragraph level. There’s no such thing as a unique ID for each paragraph. Yet.

When the post is first published, we could parse the content for the paragraphs. We’d then stick each paragraph in a custom field with its canonical ID. As the post is loaded, we’d check each graf to find its corresponding custom field value and build the WinerLink from its canonical ID.

This approach would make it more possible to persist permalinks as the post is updated. When the author saves updates to the post, we’d parse all of the paragraphs again. For the ones that matched existing custom field values with 90 or 95% similarity, we’d just update the existing value with new paragraph data. New paragraphs would have new unique IDs generated for them.

We’d be backwards compatible with existing WinerLinks with a bit of Javascript on the front-end. All of the paragraphs have a specific class and we’d just match relative link to the order of paragraphs on the post.

The more obvious open question is what sort of performance cost this processing on the fly will take and whether there’s any hope of caching it.

Leave a Reply