WordPress whitespace formatting issues [SOLVED]
There is a well-known and long-standing point of contention in the WordPress community- how do we deal with standards-compliant whitespace formatting while allowing non-technical authors to format their own content using a robust WYSIWYG content editor? To date, the development community (quite naturally more comfortable with raw HTML input) has favored strict web standards compliance.
The WordPress whitespace problem:
WordPress strips all whitespace it deems incompatible with these (overly?) strict standards, leaving authors who wish for more whitespace saddled with the task of hard-coding HTML whitespace into the “text” side of WordPress’s TinyMCE editor.
For website developers who use WordPress “out of the box” as a CMS architecture to produce websites for less tech savvy clients, we are left without great options: either, 1) explain to the client that WordPress doesn’t want their paragraphs formatted the way they do, or 2) come up with less-than-ideal CSS workarounds, or 3) ask the client to learn how to input HTML whitespace. For websites with many authors, none of these are practical.
The wordpress whitespace problem in a nutshell: WYSI-not always-WYG
The bloaty and often dysfunctional
wpautop function in your install’s wp-content/formatting.php file attempts to automate paragraph formatting. As with many attempts at automation, the user’s options become limited. This function strips any “unncecessary” whitespace and decides where paragraphs begin and end. Can’t I just remove the filter for wpautop? Sure, but then your authors are stuck inputting HTML completely. Not a solution.
A better editor: TinyMCE Advanced
The TinyMCE Advanced editor plugin allows you to customize the editing interface of the wordpress install and has specific settings in how to deal with
< /br> tags.
I applied this solution yesterday to a current project we are managing for a large commercial client here in Bali. I found that it worked with whitespace very well, but that WordPress was still stripping some formatting from the input when the TinyMCE GUI is switched from Text to Visual and vice-versa. The remaining problem had to do with the stripping of empty
<span> elements. It is a well-known CSS trick to insert an empty
<span> row to activate the justification of a row of inline-block elements. Basically, it’s a great way to efficiently space elements evenly in a horzontal alignment.
Better client-side validation: Preserved HTML Editor Markup
Wordpress was stripping it, leaving me with a heap of images that were previously evenly spaced across the viewport. I found another plugin: Preserved HTML Editor Markup by Marcus Pope. In this plugin, Marcus actually deals with the client-side validation of the text elements when the user transitions between the “Visual” and “Text” tabs in the TinyMCE editor. It worked brilliantly to keep my
<span> elements in place.
The endgame for WordPress whitespace:
You can now supply clients with a robust GUI-oriented content editor that will preserve whitespace formatting and CSS-oriented
<span> tags when switching between views. This is great for large scale sites with many authors who may have varying degrees of technical nous. Give it a go and see how you get on. As always, leave me a question in the comments section and I will be happy to help.