Tag: WordPress

Why I still use WordPress and prefer self-hosted websites over Software-as-a-Service (e.g. Squarespace)

I don’t hate Squarespace. I’ve used it for a few sites. But I still strongly prefer building my own self-hosted WordPress sites, for a variety of reasons. But I think I just found the best one.

SaaS website builders like Squarespace have come a long way, especially in terms of letting you write your own code. But there are still some deeply ingrained, user-hostile lock-in elements to these platforms, and perhaps there’s no clearer example of this than the Asset Library in Squarespace.

As I write this, I’m in the process of migrating the website for a big band I play in from Squarespace to WordPress. The first step in the move, of course, is setting up a new WordPress site, and since I’m basically just trying to roughly recreate the single-page site we currently have (at least as a starting point), I need to download the assets for the current site: images and videos.

Squarespace has a very elegantly designed Asset Library section, where you can view and organize all of the files you’ve uploaded to your site. There’s just one thing you can’t do: download the files.

Um, what?

Yes… Squarespace offers no way to download the files from your Asset Library. Not in bulk, and not even individually. Seriously.

Sure, it’s not too hard to download the images. You can just drag them from your browser window to your desktop. Even if you drag the thumbnails, you’ll get the original full-sized image. That’s almost enough to make me not hate the experience. But then there are videos.

Video on the web is kind of weird. HTML5 has broad support for videos in an open way, just like with images. The problem is, the early web didn’t really support video because no one had the bandwidth for it, and by the time it gradually gained support — initially through proprietary plugins like Flash — the web had “matured” to a point where companies were trying to find ways to lock down their assets.

So again, even though HTML5 supports video, the way videos are presented on Squarespace, even in the admin, is through multiple layers of wrappers that obscure access to the actual files. Even if you view the raw source of the page, there’s no way to get the direct URL of the file. There is no way to download videos from your Squarespace Asset Library. At all.

Fuck.

Sorry… although my daily speech is liberally seasoned with profanity, I usually abstain from it here on the blog. But it is absolutely warranted here. Seriously, fuck Squarespace for preventing us from downloading our own files.

Their support forum has a thread where it’s spelled out quite clearly that they do not offer a means of downloading your video files. And their support staff spins it like this some kind of super-complicated functionality that they’d like to offer if only they could, but they just haven’t been able to achieve it yet.

Give me a break. They’ve put considerable resources into making it hard to download the files. It would be an order of magnitude easier to build a straightforward system that at least didn’t actively block you from directly downloading the files one-at-a-time.

Yes, some kind of bulk download feature would actually require them to do some development work. But simply allowing the browser to do what it’s designed to do with HTML5 video tags would at least give us a way to download the files individually.

So, make no mistake: the only reason you can’t download your video files on Squarespace is because Squarespace explicitly does not want you to be able to do that.

That’s reason enough for me never to choose to use their platform.

I guess I need to take back what I said at the beginning. I do hate Squarespace.

The core team (i.e. Matt) doesn’t want WordPress to be a general purpose CMS

For various reasons, I’ve kind of taken a step back from heavy client project development in WordPress over the past few months.

Today I’m back at it, trying to really actively work on something new for the first time since before the big kerfuffle started, and the time away has given me new perspective on what WordPress really is, and what the core team (let’s be honest, Matt) wants it to be.

I’ve frequently argued that WordPress owes its broad success to the malleability its plugin architecture provides. The platform is not, inherently, a general-purpose Content Management System (CMS), but thanks to plugins like Advanced Custom Fields, it can be turned into one.

The funny thing is, the platform clearly was moving in the general CMS direction for much of its early life. The availability of custom fields (not ACF specifically, but the more rudimentary open-ended key/value pair system created by the wp_postmeta table), not to mention custom post types and taxonomies, and the extensible template system, really pointed things in the direction of a system much broader than simply “blogging.”

But Matt really just wants WordPress to be about blogging. Because that’s how he uses it. And he only sees what he wants to see.

All of that natural growth in the direction of general-purpose CMS use was effectively pruned by the shift to all things Gutenberg: the Block Editor, and now the Site Editor (formerly Full Site Editing).

I won’t deny that — now that they’re reasonably mature — the elements of Gutenberg are powerful and (somewhat) intuitive tools for building an engaging blog without having to write code.

But for many of us who helped get WordPress to where it is, that’s not what we want, or need. These tools are not only irrelevant to our work, they make the work we need to do much more difficult.

Specifically I’m talking about template design. In their pure intended form, Block Themes can’t have any PHP code in page templates. Which severely limits their functionality. Even if you end up creating a theme — like I have — that’s somewhat of a hybrid of the old and new ways, you’ll find it absolutely maddening how your PHP code may no longer have access to such obvious and basic variables as the post ID.

Meanwhile, core functionality for things like custom fields has been all but killed. It seems like, at the very least, there should be a way in the Block Editor to reference a custom field value. Nope.

Even Advanced Custom Fields’ efforts to extend Block Editor support require a bunch of convoluted hoops. Assuming that creating your own ACF Blocks is overkill, in some cases you can reference ACF values using the [acf] shortcode, but that only works for certain types of fields and, as I’m learning right now, it only seems to work in the Block Editor itself, not in templates.

I’m not saying Advanced Custom Fields is the entire reason for Matt’s extreme actions against ACF owner WP Engine, or for his subsequent deranged steps, seemingly intent on tearing apart the WordPress community itself. But it’s hard to deny that Matt hates ACF for what it represents: a WordPress he can’t control, and one that doesn’t look like what he thinks it should be.

Unfortunately, that’s the only kind of WordPress I care about.

Well… that’s enough for now. Time to go and unravel my theme so I can make this new site I’m building actually do what my clients need it to do. Why did I choose WordPress again? I seem to be asking myself that question more and more frequently.

Update: The morning after I wrote this, I stumbled upon this forgotten bit of code in my theme:

function r3423_acf_disable_shortcode() {
    acf_update_setting('enable_shortcode', false);
}
add_action('acf/init', 'r3423_acf_disable_shortcode');

So, uh… yeah, that part was my fault. But I was just following ACF’s instructions since I generally don’t ever use the shortcode.

Building plugins IS contributing to WordPress

I feel at this point in time it really needs to be stated that building plugins that extend the functionality of WordPress is just as important for the ecosystem — possibly more, depending on the nature of the plugin — as contributing to core.

WordPress isn’t as huge as it is because of blogs. It’s huge because plugins make it viable as a general purpose CMS. In fact, there’s one particular plugin that is more responsible for its general-purpose flexibility than any other.

If WordPress were limited to its core functionality, no one would even be talking about it today… because it would have been abandoned at least a decade ago.

That is all.

Is WordPress a platform professionals can trust?

Here we go again…

Matt Mullenweg Announces Unexpected Holiday Break for WordPress.org Services

It’s true, WordPress has always been a little bit hard to take seriously, what with the Hello Dolly plugin being part of the base installation.¹

As much as I have devoted the last decade of my professional career to WordPress (and used it fairly extensively for several years before that), I have never had much appreciation for Matt’s sense of humor or his perspective on things. I’ve invested myself in WordPress despite Matt, not because of him.

But the turn things have taken over the past 3 months has come as a surprise even to a Matt skeptic like me. He really just seems to be going completely off the rails in this vendetta against WP Engine, and he’s absolutely dragging down the entire WordPress ecosystem in the process.

It’s an extremely frustrating and tenuous position to be in, as a developer of a plugin that is becoming an increasingly large portion of my livelihood. I know that the majority of the sales of my commercial plugin are fed by users starting out with the free version of the plugin that’s distributed through the WordPress Plugin Directory. It just does not sit right with me that the source that feeds so much of the WordPress ecosystem, both free and commercial, is controlled by a single individual (said individual’s disingenuous protestations otherwise notwithstanding). It’s especially concerning when that single individual makes unilateral decisions of great impact on the entire community with the kind of capriciousness and petulance Matt has been demonstrating lately. (Even though I do like pineapple on pizza.)

I know it’s dangerous to my very livelihood for me to be writing this. Much like the Rebellion’s one-man fighters against the Death Star, I’m too small to be a threat.² But I’m also sure Matt wouldn’t think twice about kicking my plugins out of the directory if he saw this on a bad day. I’m literally nothing to him, but the WordPress Plugin Directory is immensely important to me. That kind of power imbalance is dangerous. And it is much more of a danger to the spirit of open source software than anything WP Engine is doing. I worry that WordPress as we’ve known it is dead.

¹ I do not have any problem whatsoever with the existence of the Hello Dolly plugin. My problems are that a) the functionality it adds is superfluous and undermines the appearance of WordPress as a professional tool, and b) it is a bad example of how to write a plugin, which is the nominal reason for its inclusion in the base WordPress installation in the first place. It is not structured the way modern plugins are supposed to be written, and it doesn’t include any of the types of functionality a new plugin developer would need to see in action to gain any meaningful insight into how WordPress works.

² The significant difference, of course, being that I don’t have access to any secret plans revealing the Death Star’s weakness.

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.