Skip to Main Content

How to Disable Gutenberg BEFORE it’s Released

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.

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

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

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.

read more »

2018 is the year I learn JavaScript

I have a confession to make. I don’t really know JavaScript. Some of you, who know my plugins, like WP SmartCrop, Blockade, and WP jSlabify, might say “But that’s some pretty heavy JavaScript!”, but that is where things get complicated. You see, I know math, I know programming, and I know the DOM, inside and out. By knowing those things really well, and treating JavaScript like any other language, I can make pretty cool things! But that’s not the same as knowing JavaScript anymore.

read more »

ADVERTISEMENT:

Search by Location with WP Query

I get a lot of client requests for “Store Locators” or “Location Finders”. There are some plugins like MapPress and WP Store Locator that work well for simple Location Searches, but as soon as the client has requests for specific functionality or designs, these pre-made options start to fall short, and you end up spending more time fighting their code than writing your own. read more »