Yesterday, I released Markdown Code For WordPress – an extremely simple plugin that makes it easy to replace Markdown backticks (`) with inline code comments. As mentioned in the post, it scratches an itch of my own that I’ve opted to share just in case anyone else shares the same, y’know, itch.

In the comments, Konstantin left a great question that I felt was worth discussing further:

Why not carry out the search and replace once before the post is saved and not every time it is displayed?

I left a response in the comments:

I didn’t want to do prior to saving the post just in case people use it, opt to disable the plugin, and then want to go with some other markdown editor or some other plugin. This keeps the original tokens in take so they can do a search and replace for it.

In short, I’ve had less than stellar experiences (read: back feedback) when it comes to mucking with data prior to saving it with the database especially when users want to abandon the plugin.

But I thought this was a great question that warranted a deeper discuss and wanted to bring it up here to get the rest of opinions from fellow developers.

A WordPress Plugin Change Post Content?

To be completely honest, I like Konstantin’s suggestion. In fact, it’s something I’ve done in previous in previous plugins.

Here’s why: I like the idea of making the change once and then being done with it. Instead, the plugin currently works in such a way that it replaces the token just before it renders it to the browser.

Specifically, it retrieves the data from the database, parses the tokens, then displays the formatted content. For a plugin like this, the performance impact is negligible, but if you were to be doing this for a larger data set then it may be a bit heavier and the users may able to feel the delay.

In this case, not so much.

It’s About Tradeoffs

The truth is, when it comes to working on data manipulation, it all comes down to tradeoffs. At some point, you have to find the best place to make the tradeoffs so not to sacrifice the integrity of the user’s data while simultaneously not impacting the performance of their page load.

It’s a Learning Experience

As I previously mentioned, I really like Konstantin’s suggestion and that was the original plan; however, I’ve learned from previous experience that user’s aren’t big fans of their data being permanently changed.

After all, what if they opt to disable my plugin and go with another Markdown-ish plugin? They can’t because I’ve effectively stripped out all Markdown tags from the post or page content.

What’s My Verdict?

Straight up: It honestly all depends, but I generally leave it alone.

I’ve made a judgement call not to permanently change the user’s post content should they opt to disable the plugin and because the performance is negligible.

In other cases, I may not do the same – in fact, it’s completely possible to setup a routine to “undo” whatever a plugin has done.

But I think this does raise the question: When is it acceptable to permanently alter a user’s post (or page) content, and when should it be done prior to rendering the content to the page?

I’m genuinely curious as to what the rest of you developer-types think so chime in. I’m always interested to hear.

Share:

Leave a Reply