Keeping Code out of the WordPress Text-Editor

Reading Time: 5 mins

I’m sure we’ve all seen this at least once. Maybe it’s the aftermath of a poorly estimated project charging right towards a deadline. Or perhaps it stems from a quick fix at eight in the evening from an overworked developer. It might even be the client’s attempt at re-gaining control of his own site no thanks to the suspiciously cheap development he paid for overseas.

Either way, it’s a bad idea no matter the reason. What am I talking about? I’m talking about HTML and inline styles in the WordPress text editor. Bad, bad, bad!

Feel guilty yet? No worries, I’ve been there. And learning from my own mistakes, I’d like to share a few reasons why this practice should be avoided. Then I’d like to offer some solutions to keeping code out of the WordPress text-editor and instead, leaving it where it’s safe within the theme templates.

Doesn’t WordPress Natively Allow HTML?

First, of all, what’s with leaving code out of the text-editor? Doesn’t WordPress already let us put HTML in the text-editor? What’s the difference between WordPress HTML and our own?

Let’s go over what WordPress’ text-editor currently supports first out of the box. WordPress’ text-editor is powered by Tiny MCE. Some of the options currently supported in WordPress 4.0 that insert HTML into the text-editor from the visual tab are:

Bold:

Italic:

Strike-through:

Underline:

Font-Color:

Ordered and Unordered Lists:

  • Pancakes
  • Waffles
  • Crepes
  1. Pancakes
  2. Waffles
  3. Crepes

BlockQuotes

Aligning styles for:

Align Left

Align Center

Align Right

Links:

Headings:

There are more options in the visual text-editor, but for the sake of moving on, let’s just use these examples above. No, you are not seeing things, WordPress is inserting HTML into the text-editor. However, what it’s inserting is basic HTML used for formatting text only. Meaning anything design-related aside from text color is non-existent. No background images, no rounded edges, no divs and no classes/IDs.

There must be a reason for that. One can only guess, but my hunch says the reason that the text-editor only offers these straight forward HTML options are because anything more complex would go against WordPress’ philosophy:

Design for the Majority
…The average WordPress user simply wants to be able to write without problems or interruption…

Decisions, not Options
…Ultimately these choices end up being technical ones, choices that the average end user has no interest in….

If you get a chance to read those entire paragraphs on the WordPress philosophy page, the point is that WordPress is intended for the average user, and therefore, that’s who they built the software for. Ideally this is also who we, as WordPress developers, should be building for. So in most cases, having all of these extra bells and whistles in the text-editor does little, if not nothing, to benefit the average user.

Which brings me to my next point…

Why Should We Avoid Putting HTML in the Text-editor?

We’ve already gone over the WordPress philosophy, but there are other, more obvious reasons.

  1. To future-proof your site for development
  2. To keep it out of the client’s hands

The first reason, is future-proofing. What I mean is building a WordPress theme while keeping the future “what ifs” in mind, and preparing for those what ifs. What if a new developer inherits this project that knows nothing about it? What if the client changes themes? What if the site moves to another server? What if the client removes xyz from the text-editor?

Imagine all the ways your WordPress site can break if you’re putting a bulk of design dependent HTML into the text-editor, heck, you might even be using IDs being referred to from a script file. If breaking the site is as easy as messing with the text-editor – that’s what you want to prevent at all costs. You’ll thank yourself later.

The second reason is since WordPress is intended for the average user, keep it simple. Anything extra that the client has to remember to do or not to do is just going to make content management difficult, the opposite of WordPress’ purpose as a CMS. Not to mention, should you trust sensitive code in the hands of your client? Even if your client happens to be a code monkey, a WordPress theme is meant for your HTML and CSS loveliness. Why clutter the text-editor if you don’t have to? Your client will also appreciate less obstacles in the text-editor – and we aim to please, right?

Now to my final point…

How Can We Avoid HTML in the Text-editor?

Unfortunately, this isn’t a simple answer. It really depends on the project, the budget, how much experience the developer has and so on. Ultimately, you want to develop a mindset where building a theme and usability go hand in hand. That mindset is achieved by experience and is an ongoing process. Until this day, I’m still discovering new and better ways to build WordPress themes while maintaining a clean dashboard.

Although I don’t have all the answers, here are some suggestions that have helped me keep the text-editor HTML/CSS free:

  1. Learn to write Shortcodes. If it’s a simple style or wrapper that your client will use often, Shortcodes are a great way to allow that freedom without them having to remember syntax.
  2. Custom Fields or plugins that enhance custom fields like ACF/Magic Fields. Maybe all your content doesn’t have to be in the text-editor. Think about it. If you needed to separate the content within the text-editor, how would you do it? Once you know that answer, these fields can assist you in separating that content into their own text-editors/text-fields where you can then have finer control in your theme templates.
  3. Creating new loops or editing existing ones. You can use custom post types that get pulled into a main loop. You can create a page template for a parent that displays it’s children with get_post or get_children. There are many ways to take advantage of loops, you’ll just have to practice. 🙂 Here’s an older article of mine that teaches how to call child pages within a parent.
  4. Use your theme’s stylesheet. Once you understand what WordPress’ text-editor offers, think about how you can take advantage of that using the CSS in your stylesheet rather than adding new HTML/styles directly into the editor.

Conclusion

You can usually tell a novice developer from a seasoned one by whether or not there’s a chunk of custom HTML in the text-editor. It’s really a matter of knowing what WordPress is capable of, and this is still something I’m learning everyday. Keeping the text-editor clean will future-proof your site from breaking and will improve UI for your client.

I hope that I’ve at least helped you on your way, and if you have any suggestions to offer or questions on how to keep the text-editor as HTML free as possible, feel free to leave a comment below. Until next time!

PS: My web accessibility series for WordPress will start up again soon. Stay tuned!

 

 

4 thoughts on “Keeping Code out of the WordPress Text-Editor

  1. Great tips! I try my best to keep markup out of the text-editor for the reasons you stated but sometimes it just isn’t possible.

    I was writing a post recently that required me to display some sample code in the post so I had to wrap that content in pre tags. I see you’re doing something similar in this post but am guessing you’re using a shortcode for it.

    I haven’t experimented with this yet but I’d really like to start writing WordPress posts using markdown. I’m already really familiar with markdown as GitHub uses it for it’s various messaging systems.

    There’s a few plugins out there that will allow you to do this but I haven’t invested the time in checking them out yet.

    • Hi Chris, thanks for the comment. And I agree, there are some rare cases where you’ve gotta do what you gotta do. I guess the point I was trying to make is to get others to try not to put code in the text-editor unless they really have no choice.

      As far as the pre tags, I’m using a plugin called Crayon Syntax Highlighter to drop my code in. I was thinking of converting to Github/Gist and then all of my code snippets would be in one place and I wouldn’t have to worry about a plugin becoming deprecated at some point. But then I realized, I probably would have to go into my old posts and convert my existing snippets to the new github markdown for consistency and then procrastination kicked in haha. I think pre tags are okay to have in the text-editor as WordPress supports them out of the box. I think anything WordPress already has in the TinyMCE is fine so long as people aren’t dropping entire html layouts and JS dependent classes on elements. I’ve never seen that not cause a hassle at least once.

      Thanks again for stopping by. 🙂

  2. Mark Hallam says:

    Theme shortcodes can be problematic as well because they are theme specific. It is fine if they are only related to a plugin but if a user has to change themes and the site packed with shortcodes, it is not efficient. i.e. X theme and Avada themes.

    • Hi Mark,

      I agree – it’s a matter of weighing your options as a theme developer. For the clients I’ve worked with in the past, their themes are very customized and tailored for their business so it’s not usually something they’ll randomly swap out for another theme. Not to mention, if the shortcodes are only responsible for just making some styling changes in the content while keeping the text-editor clean, switching a theme will mean the styles are changing anyway so if it’s only styles, the client wouldn’t have to worry so much. Now throwing in some heavy functionality using shortcodes – that’s another story.

      Anyway, thanks for the comment. I appreciate your feedback.

Leave a Reply