This is my first post since July. I’ve been working almost exclusively on the development and build for the National Air Traffic Controllers Association (NATCA) website. As with projects of this caliber, I like to do a thorough write-up of my experiences during the process — the good, the bad, and the ugly.
But First, My Disclaimer…
I am going to comment negatively on Divi, Stackable, and some aspects of the block editor. This is not to say that I do not appreciate and recognize the hard work and dedication of the plugin authors and the WordPress team. I will be as objective as possible in airing my grievances and articulate why the software did not work for this project. On the contrary, these page builders laid the foundation for the block editor — transforming the monolithic WYSIWYG editor and breaking down pages and posts into components/modules/atoms/widgets/etc.
For this reason, I believe that WordPress’s block editor will cause 3rd-party page and theme builders to become obsolete. It’s the same for web technologies. The community creates useful and needed functionality that gets absorbed into the standards. jQuery and Flash are excellent examples of this. jQuery’s intuitive API for selecting and manipulating DOM elements became part of the Selectors API with querySelector and querySelectorAll. Flash’s animation became part of the CSS Transitions and CSS Animations modules, providing the ability to create performant, keyframed animations. In the end, the standard wins. The block editor is now the standard.
The Block Editor and Page Builders
Before my decision to use the block editor, I did create a prototype of the homepage using Divi. I am very familiar with Divi and was comfortable using it to create custom modules. Then, I considered what I’ve outlined in my disclaimer and created the same homepage prototype using the block editor. Before I applied any optimizations such as caching, lazy loading, minification, etc., I did a head-to-head comparison using Google’s PageSpeed Insights.
When compared against Divi, the block editor:
- Reduced requests by 34% (88 down to 58)
- Reduced assets by 35% (6.13 MB down to 3.96 MB)
- Decreased load time by 49% (5.46 seconds down to 2.79 seconds)
In addition, Divi has a lot of technical debt. Anyone who
has ever had to override the styling of one of Divi’s modules will recognize
this. Divi has been around long enough that it predates the adoption of
mobile-first design — the media queries are defined max-width, not min-width.
In addition, it’s hard work to increase the specificity of style declarations
in order to overcome the rampant use of !important in the Divi stylesheets.
I get it. I’ve been using Divi since the early days of version 3 back in 2016. Version 4 came out in October. In that time, I have never had a backwards compatibility issue when upgrading versions. Never. That is impressive, but that comes with a cost. Divi must keep all of the legacy styling decisions intact to not break the websites that use it.
Finally, Divi’s greatest asset — the ability to easily customize the appearance of its modules — was a detriment to this project. I needed to provide less customization and styling options to enforce adherence to a component library and style guide. I didn’t want content creators to change colors, font-sizes, borders, etc. A team card always needed to look like a team card. An accordion always needed to look like an accordion. This was to ensure consistent branding and consistent UI elements to both the public and NATCA members.
The Block Editor and Block Libraries
My primary issue with the block editor has been discussed at length within the community. The technology stack to create custom blocks has raised the barrier to entry for beginner programmers. I relied heavily on Ahmad Awais’s excellent and well-documented create-guten-block for all the configuration and dependency management.
I wound up using ServerSideRender a lot because it transferred all the heavy logic to reliable, old PHP. This is not ideal, as I should be using the REST API wherever possible. WordPress even says:
“ServerSideRender should be regarded as a fallback or legacy mechanism, it is not appropriate for developing new features against.”
Block Editor Handbook
As I became more comfortable with creating custom blocks, I did like how lean the code was to create reasonably sophisticated functionality. That said, my biggest gripe is that the block editor needs to catch up with private functionality. As setting page and post visibility to “Private” is built-in functionality, I was disappointed how lightly this was integrated with the block editor experience. For example, private pages are not listed in the Parent Page dropdown of Page Attributes. Private pages and posts are also not listed during the automatic search when specifying links either in the Text or Button blocks.
Inevitably, I needed common functionality that I did not want to create from scratch, such as testimonials, team members, etc. For this I turned to a block library called Stackable. When the block editor was first introduced, it sorely lacked a container block. WordPress 5.2 remedied this with the introduction of the Group block. But I chose Stackable because I liked their implementation of a container block more than other comparable libraries.
However, Stackable released version 2 of their library in
November. And with it, came all the same pitfalls as Divi. To remain
competitive, Stackable provided tons more styling options, and in order to be backwards
compatible, layered on additional markup and style declarations that required
!important to override their style declarations. So, that late into the project,
I decided to eliminate Stackable’s container block in favor of the block editor’s
Group block. It was a lot of work, but worth the simpler markup and leaner
styles.
Advanced Access Manager
Another disclaimer…I am not financially vested in Advanced Access Manager (AAM), nor do I get any revenue from their sales. I say this because I can’t say enough positive things about this plugin. NATCA had a sophisticated – albeit well-defined – role structure that required specific functionality dependent on those roles. After much research, I decided on Advanced Access Manager by Vasyltech.
At the start of the project, AAM was version 5. When I purchased the Plus Package, I subscribed to receive product updates. It was refreshing to see the plugin author give a peek behind his thought process when he decided to completely refactor his codebase for version 6. After the upgrade to version 6, I needed some support and got a response within a couple of days.
Get to know how to create AAM’s access policies. This is the core of the plugin and is well-documented. The policies are incredibly powerful, flexible, and unobtrusive.
Lessons Learned
Design and development best practices such as mobile-first and content-first, are often derailed by the realities of project deadlines, stakeholder engagement, and remote teams. Several times, late into the project, some design aspects had to be changed to accommodate recently received content. Lorem ipsum makes prototypes pristine with perfect grids and edges. But a long title, or a long name, or a missing image could change one’s approach when creating a durable component library and style guide.
I am immensely proud of this project. Technology decisions were ever-evolving, with performance and accessibility oftentimes at the heart of those decisions. Stay tuned for a case study of NATCA in the new year.