The Dilemma of Maintaining Responsive and Highly Formatted Content in WordPress

One of the best features of a Content Management System like WordPress is that it empowers non-developers to edit and update their own site content. The Theme Customizer, Widgets, and various plugins allow non-technical users to control many aspects of their site, from colors and fonts to page layout to selecting a site Logo image.



Adding to this is the “Visual” Post/Page editor, a basic WYSISYG-ish Post/Page editor which can be used to create and edit text and images with rudimentary HTML markup such as H1/H2 tags, Bold, Italic, etc.



Problem One: Dense/Embedded Tags and Classes

In many cases, the use of the Visual Editor is a genuine benefit, allowing non-technical people to create Posts and Pages with a moderate of amount of formatting.




However, as any site developer/content creator can tell you, Visual Editor can also be a real problem.

These days, to create carefully formatted and Responsive content, it’s often required to work in the Post/Page Text Editor to wrap content with a blizzard of HTML tags and CSS classes, carefully nested and laid out.

It’s not unusual for the amount of formatting tags exceed the size of the content itself.



Needless to say, when non-developers look at this content, their eyes swim, and they immediately switch to the Visual Editor so they can make edits and get their needed changes made.



And then things are broken. The Visual Editor blinds the person making the edits to all of your carefully laid-out tags, making it impossible for them to preserve these delicate structures.

The results are never good, and usually horrific, the careful indentation gone, embedding trashed, or sometimes all of the formatting tags gone completely, and with non-breaking-space constructs splattered randomly around.



Expecting regular users to operate in Text Editor working in your formatting tags is not going to end well, and disallowing the Visual Editor pretty much negates the ability of people to make their own changes.



Problem Two: The Very Tall Page

You don’t have to be in the activity of creating web content long before you’ve created what I like to call a Very Tall Page, especially if the page contains a lot of formatting HTML.



It can be a real headache to find and correct the problem once there is an embedding error or a typo in the HTML of a Very Tall Page. The error cascades down into subsequent content, and often it requires the help of the Inspector to even find the latitude on the page where the error originated.



As the page gets taller and taller, the endpoints of nesting tags get further and further apart, making a challenge to find the pairs, making it difficult to visualize and understand the markup, and making it more likely that a difficult-to-fix embedding or nesting error will be the result.



Problem Three: Updating The Very Tall Page

Those of you who are familiar with the CMS known as Joomla know that in Joomla the “Save” button can be made to work via AJAX – the result being that the content saves but the web browser does not have to reload the page.



WordPress doesn’t work this way. The Update button forces the browser to reload the whole page, and if you were scrolled down working on a tall page in either Text or Visual editor, now you’re back at the top of the page.



Doesn’t seem like a big deal, but after a few dozen saves it’s maddening, and after long enough will cause an editing error, as the constant scrolling eventually results in a misplaced edit.



The Goal: Keep Complex Markup and Visual Editor separated

It’s too much of a sacrifice to give up the Visual Editor, but at the same time, to prevent markup disasters, it needs to be kept away from complex markup tags so that people can continue using it.



Solution One: Page Sections

As a solution to address this problem, I created the ASD PageSections plugin.



The ASD PageSection plugin defines a Custom Type of the same name, and includes a shortcode for inserting these PageSections into other page content.



PageSections can be used to address the above problems in several ways.



(1) Complex markup can be set up in the Page, and text and images in simple PageSections inserted into the Page using shortcodes . This allows non-technical users to use the Viual Editor on PageSection content, because there are no formatting tags in the content, they remain untouched in the Page.



(2) Complex markup can be stored in PageSections, and inserted into Pages which use more basic markup. This allows the complex content stored inside the PageSection to remain untouched while the Page is edited.



(3) Very Tall Pages can be broken down into a series of PageSections and inserted in order on the Page using shortcodes. The PageSections can also be grouped for easier use and editing with the “PageSection Groups” taxonomy.



(4) The same PageSection can be inserted into multiple locations on different Pages, with reusability much like a Widget.



(5) It’s also possible to add some Custom Fields to the PageSection, to contain “wrapper” HTML… more on that in the next section:



Solution Two: Wrapping PageSections with Leading and Trailing HTML

Adding custom “Leading HTML” and “Trailing HTML” fields to each PageSection allows the PageSection to effectively be “wrapped” in formatting tags and CSS classes, retaining their functionality, while moving them out of the hazard of the Visual Editor and protecting them in separate areas.



The Results

The Downsides

ASD PageSections successfully work in solving all of the five issues mentioned above, and have been tested in select live/production WordPress sites.



There are only two downsides that I have encountered in using PageSections:



(1) More locations for Content in the Dashboard. This is really a trivial matter, and this small increase in complexity is more than compensated for by decreasing complexity that wastes time and causes errors.



(2) The built-in WordPress Search feature tends to find PageSections instead of the Pages where they have been inserted.
This search problem can be avoided by the use of Relevanssi Search or Google Embedded Search.

NOTE that PageSections have NO negative effect on Google Search or any other internet search service



So if you’ve read this far, go ahead and give the ASD PageSections plugin. a try, see if they help to simplify your site.



Leave a Reply