WordPress Plugin Change Post Content

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.

Category:
Articles
Tags:

Join the conversation! 12 Comments

  1. From a performance perspective, I prefer to store data in the pre-rendered form. I can entirely see where you’re coming from though; I guess it depends on individual use-cases.

  2. Generally speaking, I prefer to err on the side of caution and not make permanent changes to a user’s data with a plugin too. However, in the particular case of the plugin you’re talking about, I think I would’ve.

    The use-case seems different to me. You’re effectively using a shorthand for convenience that’s not natively supported by WordPress, so the plugin allows you to use that shorthand and have WordPress understand it. If your plugin is disabled, WordPress doesn’t know what to do with your left-over shorthand.

    So perhaps it’s about intention? The user’s intention is to have <code> in the content, but for simplicity wants to use backticks instead. In other cases, the intention is to interpret the content a different way, so then you don’t want the interpretation to be permanent.

    Does that make sense, or am I just rambling now? :P

    • If your plugin is disabled, WordPress doesn’t know what to do with your left-over shorthand.

      This is true. No disagreement from me here, but in the case that the user installs some other plugin or some other syntax highlighter plugin, what once was a way to simply highlight inline code may now turn into a block of code or have a different set of styles applied to it.

      I think the potential for this is small, but I just want to avoid that possibility all together. Perhaps I’m gun shy after some other times where I’ve mucked with content :).

      Does that make sense, or am I just rambling now?

      Both. Just kidding! All makes sense :).

  3. An alternative method which is a compromise between both options, is to save the replaced content in a meta value.
    So on post save, you parse the content, do your search and replace and then save the data, but leave the original content as is.

    This way, all you need to do when displaying the content, is hook into the filter and return the pre-converted content from post meta. The performance impact is negligible, but you still leave the data in tact should someone decide to stop using your plugin.

    This is something I’ve seen done with a plugin that parses the content as Markdown.

    • An alternative method which is a compromise between both options, is to save the replaced content in a meta value

      Someone else suggested something similar on Twitter (specifically, they mentioned the post_filtered_content, but you get the idea. The thing is just

      This is something that I may end up implementing as it does a good job of, like you said, keeping original data intact all the while displaying content as it it stands after being manipulated by the plugin.

      Good thoughts, Damian.

  4. As long as you’re up front with the user about the plugin changing data, I don’t see it as a big deal. That way, the user has the choice to look for an alternative plugin if they don’t want their data changed.

    • I agree with this.

      But here’s the thing: Users don’t seem to read all of the accompanying material that comes with plugins and I hate having to introduce some sort of nag / warning because I think it interferes with the general experience of the plugin.

      So it comes down to being at an impasse of harming the experience or changing their data after the fact.

      :/

  5. One of my biggest pet peeves with plugins is when they make changes that they don’t clean up after themselves when uninstalled or make changes that aren’t easy to revert.

    I have a crazy simple plugin that removes duplicate white space. It works for what it needs to do, and I’ve thought about changing it to actually remove the spaces, but haven’t had the time.

    One way to do it is to have an option that lets people who make the actual decision to change their post content to do it, and keep the default to having it run on display. But that complicates simple plugins like these. Also, the performance issue isn’t really an issue if you’re using caching.

    I say leaving the post content alone is usually the best bet, but agree that some situations call for changing it.

    • Depending on how significant the change to the data is, caching would be helpful, but it’d have to be renewed each time a new post or page is published.

      And I agree with you in that options can often complicate simple plugins and that’s a fine line we have to tow whenever working on stuff like this. Ultimately, I think it comes to down to balancing the pragmatic approach to building the plugin while not over optimizing and over complicating stuff.

  6. I think this is one of those cases where you are expected to change the post content. With your plug-in installed when the user is entering a backtick they do not want a backtick to be displayed, but a code tag.

    And if they ever uninstall your plug-in, if you haven’t updated the post content, they will loose all their formatting.

    If you want them to edit the post content in MarkDown, you can always change it back to backticks when the post is edited (This what I do in WP-MarkDown). The advantage of this is that when the plug-in is installed the post content is left in its intended state. (There are some outstanding issue with the conversion, but if you’re just handling backticks then it should be fine).

    • If you want them to edit the post content in MarkDown, you can always change it back to backticks when the post is edited (This what I do in WP-MarkDown). The advantage of this is that when the plug-in is installed the post content is left in its intended state. (There are some outstanding issue with the conversion, but if you’re just handling backticks then it should be fine).

      I think I’m simply gun shy based on previous experiences. Like I mentioned to Japh, I think there are certain cases where, if the content if permanent modified and a new plugin is installed, styles bundled with said plugin could potentially create an unintended effect.

      Then again, uninstalling this plugin and reverting everything to backticks is no good either.

      I’m trying to be as non-intrusive as possible while also maintaining the integrity of the user’s content. A challenge, for sure. I think all of these comments have given me a lot of good stuff to consider.

      Plus, it’s why I simply versioned it 0.1.0 :).

      • I think there are certain cases where, if the content if permanent modified and a new plugin is installed, styles bundled with said plugin could potentially create an unintended effect.

        That’s true, but where the user is using backticks they mean code tags. If they then install a plug-in which does something horrible to code tags, then that’s not your fault.

        In my opinion, but converting backticks to code tags when saving, and then converting them back again when editing (you need to escape any backticks here) is no more editing the user’s content then does the TinyMCE editor. The post_content should only contain the desired HTML, and your plug-in’s job, like TinyMCE, is just to make generating the desired HTML easier for the user.

        On the other hand, with your current method, if I had any backticks in old posts, they would be interpreted as code tags.

        But I totally get the reluctance to edit a user’s content :) – to be otherwise is probably irresponsible! But I don’t think you’re editing the content so much as interpreting it.

        (Damian mentioned using meta data – Mark Jaqueth’s markdown plug-in uses this method which works equally as well. I used the method of converting between HTML & MarkDown at the editor because this method extends to comments)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.