The Problem

Blockade was created in response to one of the most annoying issues of WordPress development: How do you handle single-use HTML in a page’s content?

There are several common ways to deal with the issue, but each existing solution has its own flaws:

  1. Switch to text mode and write raw html

    Although the simplest option for simple modifications, it also has the most flaws. WordPress runs filtering and sanitization functions on the editor’s contents, even in text mode, that can and will overwrite or modify html in unexpected ways.  In addition, switching to visual mode will often completely destroy or corrupt your code, and even if it works, visual mode offers no feedback as to the boundaries or purpose of the custom html, effectively requiring you to stay in text mode at all times. This also means all edits will require the assistance of someone who knows HTML, as well as the vagueries of how WordPress messes with it.

  2. Place all content in custom templates and leave the editor empty

    This is close in simplicity to writing raw HTML in the editor, but it also essentially strips all CMS functionality from those pages, making it a rather short-sighted solution.  On many sites, all pages need some level of formatting, making this option actually less effective than simply installing WordPress in a “Blog” folder of an otherwise static HTML site.  And, once again, to edit content, users need to understand HTML and, in this case, SFTP/FTP.

  3. Build custom templates that draw content from custom fields (e.g. ACF, Pods, Piklist)
    This solution has its place, and is extremely effective in building templates for custom post types that require specific layouts and specific data to be stored, indexed, and displayed.  However, when you are dealing with one-off page designs, it leaves you in a similar state as the flat HTML option. Editing design for a single page requires creating a unique template, and editing it in HTML/PHP, and page content is not stored in the post_content database column, but rather in unique metafields, thereby affecting search, excerpts, and plugins like Yoast that leverage these fields.  Finally, these solutions often involve tying information stored in the database (such as field names in ACF or Pods) to PHP code, creating very fragile relationships between the two.

  4. Use shortcodes for formatting

    This is a fairly effective option, but nesting shortcodes involves some custom magic and increasing the resources required to render a page exponentially. Also, the editor becomes swiftly cluttered and hard for end users to understand (especially since WordPress converts new lines to paragraphs or breaks, and preserves whitespace), and WordPress’s core functions (like post excerpts) fail to read any content wrapped in shortcodes. Generally speaking, shortcodes are a strange solution to provide formatting, as they simply are a translation from one markup language to another.

  5. Use a shortcode-based visual page builder (e.g. Visual Composer or Beaver Builder)

    These builders somewhat solve one issue with using shortcodes by adding an interface layer on top of them that replaces the WordPress editor (TinyMCE). However, the new interfaces are heavily overbuilt, unintuitive, and often share very few similarities with the rest of WordPress.  Furthermore, they still have the same underlying issues as shortcodes, and they add a layer of complexity that can heavily affect interoperability with other plugins.  In practice, they also tend to attempt to be a complete drag and drop solution for website design, which leaves a lot of dangerous power in the hands of content editors.  Even the best designed WYSIWYG can be easily destroyed by an overeager content editor.

  6. Use a widget-based visual page builder (e.g. Site Origins Page Builder)
    These editors take all the issues of a shortcode-based builder, and add the complexity of the widgets system (meanwhile often butchering the traditional widgets interface). In addition, they add all the issues of custom fields, by fragmenting the content into multiple places in database, and removing the effectiveness of all content-related WordPress functions.


Blockade is not designed to solve all these issues, but instead provides a solution for lightweight, single-use HTML.