Tag: plugins

The Lesson of the Advanced Custom Fields Pro / Secure Custom Fields Debacle: Don’t GPL Your Paid Plugins

I’ve been using Advanced Custom Fields Pro since it was a solo project run by Elliot Condon. When you contacted ACF for support, you dealt with Elliot directly. I still think of it that way, even though several years ago, Elliot (after growing the business apparently beyond the scale he was interested in managing) sold ACF to WordPress plugin company Delicious Brains, which itself was later acquired by WP Engine.

Make no mistake: for me and countless other developers, ACF is the reason we can use WordPress as a general purpose Content Management System (CMS). It’s the reason I stopped building my own custom CakePHP-based CMS!

WordPress started as blogging software, and based on all available evidence, the core team, or really its BDFL, Matt Mullenweg, still sees it that way. I suspect it burns Matt up inside that a large contingent of us developers who have made WordPress the most popular CMS in the world only use WordPress because ACF makes it possible, and that we’re using WordPress specifically in ways he never envisioned it being used.

I doubt Matt’s ongoing war against WP Engine is that much about ACF. But it’s unmistakable that with WordPress.org’s (read: Matt’s) recent hostile takeover (don’t call it a fork, because this isn’t how forks work) of the free version of Advanced Custom Fields, renamed to “Secure Custom Fields,” and their even more recent actual fork of the paid Advanced Custom Fields Pro, also confusingly renamed to “Secure Custom Fields” and released for free in the Plugin Directory, WP.org/Matt sees ACF as, at least, a useful pawn in that war.

The thing that really confused me though was how could they get away with it? Advanced Custom Fields Pro is a paid plugin, distributed directly on its own website, to paying customers only.

In order to appear in the WordPress Plugin Directory, plugins are required to carry an open source license, with GPL v2 being the preferred choice. The free version of ACF in the Plugin Directory is, of course, GPL. But the Pro version…?

Strangely, after the news broke about this, I started seeing counterarguments that WP.org absolutely had the right to do it, because there wasn’t any other copyright in the ACF Pro code.

What?

So I checked for myself. Standard practice in WordPress plugins is for the license terms to be included in either the readme.txt file, the plugin’s main PHP file, or both. Here’s the top of the readme.txt file in the latest version of ACF Pro (6.3.11):

Well, there it is. ACF Pro is GPL v2. But just to make sure we didn’t miss anything, here’s what’s in the main PHP file:

I did a multi-file search in the plugin code for any instance of the word “copyright” and came up empty.

Well, that’s not good.

In case you’re not familiar with the GPL/open source, uhhh… yeah. This says in effect that WP.org absolutely has the legal right to fork and freely distribute not just the free version of Advanced Custom Fields, but the paid Pro version as well.

But just because it’s legal, doesn’t mean it’s ethical. And reading pages of the ACF site such as their terms for embedding ACF Pro in other plugins and themes, it is clear that their intentions, while generous, are more restrictive than the GPL.

I’m not really sure how, in all of these years, it never occurred to Elliot, or Delicious Brains, or WP Engine, that they needed to change the license terms for Advanced Custom Fields Pro. There’s nothing to stop them from doing that. Earlier versions of the plugin released under GPL will always be GPL. But newer versions could have switched to a more restrictive copyright, which would have (legally) prevented WP.org from forking ACF Pro.

As it happens, I now find myself somewhat in the position Elliot Condon was in back when I first started using Advanced Custom Fields Pro over a decade ago: a solo developer of a plugin that has both a free version in the Plugin Directory, and a paid Pro version.

My plugin is far more niche than ACF, so I doubt it will ever be valuable enough for a company like Delicious Brains to snap up, or that any company that would snap it up would itself become valuable enough to be acquired by a hosting behemoth like WP Engine.

I’m less valuable than a pawn. But that doesn’t mean my work isn’t of value to me. And that’s why, although the free version of ICS Calendar in the Plugin Directory — by necessity — carries a GPL license, the Pro version emphatically does not. (The latest version’s terms were reworded in the wake of this situation to be even more emphatic.)

Update: After posting this, I read the terms of the GPL more closely, and I think the issue may be that, because ACF Pro is coded in such a way that the free version’s code is deeply integrated with the Pro code, they may legally have no choice but to make ACF Pro GPL as well.

I believe it is within the terms of the GPL, and is fairly common practice among paid plugins (including mine), to put any GPL code libraries into a vendors (or similar) folder, and keep the proprietary code separate. (That’s how ICS Calendar Pro works.)

Since the GPL was written with full operating systems in mind, interpreting its wording in the context of something like a WordPress plugin, which doesn’t exist in compiled form and can’t function outside of a much larger system, can get a little fuzzy. What can or can’t be included in that vendors folder?

This leads to a broader consideration: Do I believe in the principles of open source? Or am I just using open source software opportunistically? Can I both support and contribute to open source and make money off of my software, even if it relies (partially) on other people’s open source projects to function?

I think it is naive to suggest anyone who is actually making a living working with open source software is not in that compromised position. Automattic (Matt’s company) relies on open source software just as much as WP Engine, and does far more to blur the lines between the free and commercial sides of the WordPress ecosystem than WP Engine does. (WordPress.com, anyone?)

There is no money in pure open source. That’s kind of the point. But even the most ardent anti-capitalist still needs money to survive in any modern society. And that money has to come from somewhere, whether that’s working for a for-profit company that benevolently “gives back” to the open source community by committing employee time to working on open source projects, or from indie developers releasing the basic versions of their software for free and selling paid “premium” add-ons to provide a source of income.

The “house of cards” approach to development is a “fatal error” in itself

This morning my work of putting out a fire for one client was interrupted by the need to put out a blazing inferno for another client. Specifically, they’re running a big sale on their WooCommerce store, and the site was returning a fatal error.

Turning on debugging, I saw this message:

PHP Fatal error: Declaration of Dhii\\Container\\ProxyContainer::has($key) must be compatible with Psr\\Container\\ContainerInterface::has(string $id): bool

Ugh.

There is so much about this that I hate. Mainly, what is any of it for? I have to question whether any of the developers of PayPal Zettle POS for WooCommerce, the affected plugin, really know either. This plugin suffers from what I call the “house of cards” approach to development. Why write your own code if you can just slap together dozens of packages that already do the things you want? On the surface, that’s great. But the problem is, then you don’t really know what your own software does.

I recognize that this is a necessity in many cases. It’s just not practical to reinvent every wheel. But when your application is structured like this, you may have 6 different kinds of wheels, or wheels made out of other wheels, or wheels that also contain a kitchen sink. As usual, xkcd nails it:

Fortunately, WP_DEBUG let me see exactly where the errors were occurring, and although my 20 years of idiosyncratic PHP development experience didn’t help me to understand what the error meant, this StackExchange post did. I just had to change this:

public function has($key)

…to this:

public function has($key): bool

And then I had to do that about a dozen more times in various other files deeply nested in the plugin’s vendor folder, until the PHP fatal errors stopped appearing.

In the WordPress support forums, I discovered near the top of the list a post from someone else experiencing this same error, and the devs suggested it was probably a plugin conflict. They didn’t seem interested in pursuing the possibility that their own code was broken.

But, then again, it really isn’t their code. And that’s the problem.

I’m not above reproach here. I’m a WordPress developer. I use other people’s code all the time! I even sell a product that is substantially constructed out of other people’s code. But I am very judicious about what does or does not get placed in my vendor folder. And I realize that if something goes wrong with it, it’s up to me to fix it, even if it’s not my code.

Speaking of which… I have some updates to make. Gotta go!

Some perspective on Gutenberg

Today I had to do some work on a client’s site that I didn’t build but have ended up maintaining, which is built from an amalgam of multiple “page builder” plugins, but most prominently, WP Bakery.

I was just explaining to my wife (who is not a developer but who uses WordPress, both Classic Editor and Gutenberg/Block Editor, extensively) what it’s like to use WP Bakery:

“Imagine the most annoying aspects of Gutenberg that you find the most annoying*, then imagine something ten times clunkier, a hundred times uglier, and a thousand times less intuitive. That’s WP Bakery.”
—Me

*Yes I really did, deliberately, say it that redundantly.

On the Futility of Naming Colors

I posted this over on the ICS Calendar blog, but it’s probably of some interest to the audience of this blog, dealing with the intersection of code and design.

HTML has “named colors” which are… weird. And I have finally given up on using them in the plugin, which was a bit of a silly thing to do anyway, when there are 16 million RGB colors at one’s disposal. The post ends with swatches of both the old and the newly revised color palettes.

https://icscalendar.com/on-the-futility-of-naming-colors/

Please think twice before leaving a flippant negative review

Last week I launched a new WordPress plugin, No Nonsense, and much to my surprise, it started to pick up steam after just a couple of days. It turns out, it got featured with a nice review on WP Tavern, and people took notice.

Unfortunately, almost immediately, it got a couple of really negative reviews, both of which were clearly dashed off with very little thought, or apparently even the slightest bit of effort on the part of the reviewers to try to determine the cause of their issues before leaving a negative review — rather than submitting a support ticket, which would be the correct channel for addressing a problem… if they actually wanted to solve it.

I take pride in the quality of my work, and I try hard to make sure it performs flawlessly. I respond quickly to any issues — even for a free plugin like this — because I want to make things right. So it is really painful to have the product of my efforts permanently stained with a negative review by someone who can’t be bothered to take the time to write a single cohesive sentence detailing the issues they had with it.

I understand the temptation to rip on something you think is garbage, and I’ve left a few one-star plugin reviews myself. But I feel it’s important to at least explain in detailed and objective terms why I think something is bad. And maybe if it’s clearly something brand new, I’d wait a while to see if the creators take the time to work out the kinks first.

So, no matter what you do, no matter where you are, if you are in a position to criticize someone else’s work, I implore you to take a second and think about the impact you might be having on that person and on what they’re trying to accomplish, and whether or not your criticism is truly valid and warranted. Perhaps it is not, in which case, I would respectfully suggest you stay quiet. But maybe it is. In that case, think about whether a terse and flippant negative review is really the best way you can contribute to improving the situation, or if there’s a more effective, more constructive way to share your input.