Improving WordPress

WordPress still needs a better shortcode parser.

Posted on December 31, 2018 by gschoppe

WordPress 5.0 has now been released, with the new block syntax front and center. This data structure is completely new, and lays on top of all the existing structures that modify post-content, such as shortcodes, leaving many people wondering “why didn’t they just use shortcodes to store block data?”. There are several reasons for this, one of them being the Gutenberg team’s preference for HTML comments since they default to being un-rendered by browsers. However, the biggest reason for the switch that I can see is a bit more fundamental than that. Simply put, shortcode parsing in WordPress is terrible! read more »

Gutenberg Can’t Switch Semantics, and that’s a BIG Problem

Posted on April 3, 2018 by gschoppe

I’ve been critical of WordPress’s new Gutenberg editor since day one, primarily because of its “HTML+comments as structure” language, and I’ve blogged before about the importance of context-aware rendering of blocks, but with the complete lack of complex block layouts in the initial set of beta Gutenberg blocks, It was hard to show people a hard and fast example of how HTML as structure is insufficient in the real world.

Then the columns block was released. read more »

How to Disable Gutenberg BEFORE it’s Released

Posted on March 29, 2018 by gschoppe

Many agencies and managers are concerned about the changes the new WordPress Gutenberg editor will cause for their users and their editor customizations. In many of these cases, changes will need to be made to accommodate the new Gutenberg editor, and clients may not have time to do so before the aggressive launch date that WordPress has put forward.

With the recent announcement that WordPress 4.9.5 will incorporate a call to try Gutenberg that is shown on the admin panel for all users with plugin installation privileges, the time to take action is now.

The WordPress team is using the Classic Editor Plugin as a metric for the success or failure of the launch methodology that they have chosen for Gutenberg, and when the merge proposal occurs, the method of replacing Gutenberg will likely change, so it is important that it be used to disable the editor, rather than writing custom functions in themes or plugins to do the same. The Classic Editor plugin is also promised to receive official support, so as Gutenberg becomes more ingrained, it will be important to use this method.

NOTE: The Classic Editor plugin page is covered in warnings about not installing it on production sites yet. Since it checks to see if Gutenberg is installed before doing anything, and its only function is to remove actions and filters set by Gutenberg, these warnings can be safely ignored.

However, the classic editor plugin doesn’t suppress this call to install Gutenberg, and by default leaves Gutenberg as an optional editor in the admin panel. Both of those features are counter to the goal of stripping Gutenberg entirely until workflows can be evaluated and training can be done.

To that end, I’ve published a new plugin along with Pieter Boss, that will strip the “Try Gutenberg” messaging before it is released, and will allow you to run the Classic Editor plugin and have it truly strip Gutenberg with no configuration or management, before the merge occurs.

If you are running a site management dashboard like MainWP, ManageWP or even Jetpack, pushing this solution to all your clients can start today, and is as easy as bulk installing Classic Editor, and the plugin available here:

Get Classic Editor Addon

Store specific post types in dedicated DB Tables (an exercise in pain)

Store specific WordPress post types in dedicated database tables

Posted on February 27, 2018 by gschoppe

Over the last few years, I’ve run into a few situations where the standard database structure of WordPress causes some real frustration. There are two specific examples that come to mind immediately.

In one case, a client wanted to be able to make their edits to posts and pages on a staging site, but also had a massive amount of data that needed to be uploaded nightly from an ORM system. They needed all the trappings of the standard WordPress post structure, but for efficiency, the imported posts needed to be deleted and recreated nightly, in a slow import that ran on the staging site. We ended up building them a custom data structure, but that meant re-implementing many of the features that WordPress provides automatically.

In the other, another client also needed to import a massive amount of data, but nightly modifications were able to be incremental. We chose to store their data in a custom post type, since it could be handled incrementally, but after the fact, we ran into performance issues, caused by the size of their data (over 20,000 posts, with 100+ metafields each), and discovered flaws in the structure that required us to perform several full reimports to solve. We saved time by being able to use the functions that WordPress provides, but lost time dealing with re-importing data and syncing up post ids with metafields. read more »

Benchmarking Gutenberg

Posted on February 20, 2018 by gschoppe

As the release of WordPress 5.0 comes closer, I was curious about performance of sites running Gutenberg (the proposed replacement for the WordPress post editor). To answer the question, I wrote a lightweight benchmarking mu-plugin, that I’ll write more about in a future post, once I’ve given it a little more polish.

As a test, I generated two identical pages, one with the Gutenberg editor, and the other with the Gutenberg plugin disabled, and ran my benchmarking script on each.