Skip to Main Content

Are all WordPress Plugins and Themes Open Source? It’s not a simple answer.

Posted on by gschoppe

Recently, I’ve been seeing a lot of posts on reddit telling users that they can do whatever they want with WordPress themes and plugins, and demand or pirate free copies of paid themes and plugins, because they’re all GPL licensed. Unfortunately, this isn’t the whole story. I figure it’s time to clear the air about how this all works.

Note: I am not a lawyer, and one of the most important things to take away from this article is that you shouldn’t make your own legal interpretations without the support of a lawyer, specializing in intellectual property law. read more »

Add a Translate Button to WeGlot Pages

Posted on by gschoppe

Recently, I started using the WeGlot WordPress plugin to translate a client’s site. I’ve been happy with the service so far, but it was frustrating to continually need to switch back and forth between the WordPress dashboard, and the WeGlot dashboard, just to populate content. To make things easier, I added a button to the WordPress admin bar, that links to the WeGlot visual editor for the current page being viewed. I’ve found this makes client training much simpler. read more »

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

Posted on 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 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.

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

ADVERTISEMENT:
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 »