EDIT - HN Discussion about it here https://news.ycombinator.com/item?id=44205865
I have spent the last few months on and off thinking about creating something like this for some projects of mine. I've been looking into ATProto [0], IPFS [1], Radicle [2], and Iroh [3]. I was tending towards Iroh lately but I also like ATProto so going to check out this FAIR [4] protocol because I'm all for having widely adopted common protocols.
Also, the jkpress post by Matt Mullenwegg linked in TFA has to be one of the most unprofessional and caustic things I've ever seen someone write, and reflects poorly on his character.
By being unreasonably reasonable in this way I would expect they bring the most members of the community with them if a fork has to happen.
They also leave a door open for Matt to leave this effort alone or even welcome it. A potential road to recovering trust over time.
Evidently you haven't been paying much attention to Matt or WordPress. Matt Mullenweg is - and seemingly always has been - simply a caustic, manipulative, dishonest, petty, etc... person. He was generally good at hiding it, but it always peeked through on an annual basis. But it's simply been the norm for the past 9 months - sometimes on a daily basis.
Another gold nugget here (has archived links) https://news.ycombinator.com/item?id=41839864
But the best reading is the initial lawsuit from wp engine. It's just overflowing with screenshots of self-incriminating toxicity.
Goodtime line of events here https://gist.github.com/adrienne/aea9dd7ca19c8985157d9c42f7f...
If they changed their backend to disallow this implementation from accessing it, they'd also break it for older versions of WP (which feels like the majority) and cut off the upgrade-path for those sites.
WP's heavy use of filters & actions are what makes it bearable to work with for developers, and without the plugin ecosystem, Wordpress would be no serious competitor to anything.
I don't know if this will work out, the code looks worrying - they support all the way down to php 7.2, but OOP and composer don't require php8. On the other hand, so do most WP plugins, and core does too.
Blocking the way that FAIR works would break the way that premium plugins work, which would break a huge amount of the ecosystem, so we think it's unlikely - WordPress core would need to be patched.
I'm suspicious of the Linux Foundation, and am pretty much on the side of wordpress in the big dispute, but I'd switch to a distributed solution in a second if it worked 75% as well. The difference in management risk between a) dealing with a single CEO of a single organization who behaves that way in public, and b) a distributed Linux Foundation sponsored apt-style plugin repository, is huge.
If a lot of people are like me, that means wordpress is doomed. People don't want to fork because they don't want to pay for wordpress development. Taking away revenue from wordpress is going to stagnate it (even more, and it's a dinosaur anyway.) The parasites will have killed the host.
This essentially discredits you completely... A judge already granted an injunction against Matt to revert all his nonsense, which only really happens when the case is overwhelmingly strong against them.
> The parasites will have killed the host.
The problem is that the "host" IS the parasite in this case.
People don't fork because they wouldn't stay compatible with core, and thus not keep compatibility with most of the plugins if they do anything meaningful to improve the code (and if you don't, why would you fork?)
core and plugins are handcuffed together: plugins are nothing without core, but core is just a horrible mess of spaghetti code with no value without plugins. yet core can't really be improved without abandoning a bunch of plugins (on which they depend for being viable as a CMS).
So far, core seems to err on the side of plugin authors (unless they're deemed competitors to .com), i.e. rug-pulls and replacing the plugin with malware-adjacent "new functionality" is totally fine for .org's plugin masters.
I wrote about it in my blog [1]. It is an amazing tool with an unstable company behind.
Time will show us if the FAIR Package Manager will be able to improve the overall ecosystem status.
I do wonder what other CMSes people do enjoy, though. My blog runs on Grav, a flat file CMS that still allows me to easily keep the content in Git, while also having some dynamic content and search (and optionally an admin UI): https://getgrav.org/
After exporting from either CMS, it's pretty close to drag/ drop onto the grav instance and everything should "Just Work (tm)".
- [1] https://github.com/jgonyea/wp2grav_exporter - [2] https://www.drupal.org/project/grav_export/
Hopefully I'll be able to release it by the end of the summer.
Grav was what convinced me that ultimately a CMS doesn't have to be married to a database, at least for what could be conventionally considered small websites.
> The FAIR Package Manager is a decentralized alternative to the central WordPress.org plugin and theme ecosystem, designed to return control to WordPress hosts and developers. It operates as a drop-in WordPress plugin, seamlessly replacing existing centralized services with a federated, open-source infrastructure.
> There are two core pillars of the FAIR system:
> - API Replacement: It replaces communication with WordPress.org APIs (such as update checks and event feeds) using local or FAIR-governed alternatives. Some features—like browser version checks—are handled entirely within the plugin using embedded logic (e.g., browserslist).
> - Decentralized Package Management: FAIR introduces a new package distribution model for themes and plugins. It supports opt-in packages that use the FAIR protocol and enables hosts to configure their own mirrors for plugin/theme data using AspirePress or their own domains. While stable plugins currently use mirrors of WordPress.org, future versions will fully support FAIR-native packages.
You can try the FAIR plugin at this link: https://github.com/fairpm/fair-plugin/releases
Kudos to all involved behind the scenes to even get to this point. Ideas are cheap, execution is hard, especially across so many disciplines, so major props for the coordination and collaboration.
WordPress.org bans WP Engine - https://news.ycombinator.com/item?id=41655967 - Sep 2024 (490 comments)
If WordPress is to survive, Matt Mullenweg must be removed - https://news.ycombinator.com/item?id=41676653 - Sep 2024 (245 comments)
WP Engine is not WordPress - https://news.ycombinator.com/item?id=41613628 - Sep 2024 - (165 comments)
Filed: WP Engine Inc. v Automattic Inc. and Matthew Charles Mullenweg [pdf] - https://news.ycombinator.com/item?id=41726197 - Oct 2024 - (659 comments)
The ACF plugin on the WordPress directory has been taken over by WordPress.org - https://news.ycombinator.com/item?id=41821400 - Oct 2024 (224 comments)
So long WordPress - https://news.ycombinator.com/item?id=41974637 - Oct 2024 (211 comments)
WordPress.org's latest move involves taking control of a WP Engine plugin - https://news.ycombinator.com/item?id=41826082 - Oct 2024 (211 comments)
Is Matt Mullenweg defending WordPress or sabotaging it? - https://news.ycombinator.com/item?id=41872628 - Oct 2024 - (143 comments)
Mullenweg threatens corporate takeover of WP Engine - https://news.ycombinator.com/item?id=41712617 - Oct 2024 - (120 comments)
Matt Mullenweg cries foul and threatens me with legal action - https://news.ycombinator.com/item?id=41727888 - Oct 2024 - (43 comments)
Matt Mullenweg temporarily shuts down some Wordpress.org functions - https://news.ycombinator.com/item?id=42469708 - Dec 2024 - (122 comments)
WordPress Is in Trouble - https://news.ycombinator.com/item?id=42687121 - Jan 2025 (439 comments)
Matt Mullenweg deactivates WordPress accounts of contributors planning a fork - https://news.ycombinator.com/item?id=42667766 - Jan 2025 (236 comments)
Mullenweg Shuts Down WordPress Sustainability Team, Igniting Backlash - https://news.ycombinator.com/item?id=42672675 - Jan 2025 - (172 comments)
Matt Mullenweg, Automattic's CEO, Seems Bound and Determined to Wreck WordPress - https://news.ycombinator.com/item?id=42773311 - Jan 2025 - (57 comments)
Here's another timeline https://gist.github.com/adrienne/aea9dd7ca19c8985157d9c42f7f...
I wish this was an evolution from bedrock, or that it used some composer infrastructure (which works with just static files).
Doubt this is going to be the case if FAIR takes over.
Can you explain how this would allow any other license than gplv2 for the plugins?
WordPress.org demands that plugins they host are GPL.
FAIR is a protocol that allows access to additional repositories. These other repositories may not have this same demand.
https://wordpress.org/support/topic/are-wordpress-plugins-au...
https://wordpress.stackexchange.com/questions/406337/does-wo...
The plugin‘s author breaches the core‘s license, but that doesn‘t make the plugin GPLv2 by itself.
Something like the following would be a valid plugin, but it doesn't directly or indirectly use _any_ code by WP. It's only executed by WP. I don't believe that it would be considered a derivative work of WP, because that file would happily run without WP as well.
<?php /* Plugin Name: My Plugin Version: 0.1 */
if($_SERVER["REQUEST_URI"] === "/my-url") { // do something interesting, use curl to fetch some content }
In addition to your example, I can imagine a very defensible scenario where a plugin is "standalone" with a shim layer to connect to WordPress (and maybe other CMSes, too).
The one case I just remembered where it was remotely challenged was Thesis [1], but Automattic chose to throw money into bullying the challenger rather than going after the alleged license violation.
[1] https://wptavern.com/mullenweg-and-pearson-square-off-on-pat...
Even the managed hosters have barely adopted modern practices. Do you know it's actually easy to treat the database as an ephemeral, versioned object? Nobody I've talked to does. You just back up the logical database, and rename the database name in the backup to a unique string (including a version, or datestamp, etc). Now you have versioned, uniquely-named database, so you can do immutable infrastructure. Load this backup into a database server (even the "live" database server, as it won't conflict with the old db name). Start a new WordPress container and pass env vars pointing to the new database name. Now you can pair a snapshot of the code with a snapshot of the database. Upgrade or downgrade in seconds, with confidence. (that is, after you've done all the manual work to upgrade, test, and fix in an ephemeral environment)
This simple method makes operations more robust and predictable, makes dev & testing easier, and is used by.... nobody, as far as I'm aware. All the managed hosters I've seen just give you an admin portal, and a "dev", "test", and "live" instance. No ephemeral environments. No snapshots or diffs of configs or databases. Plugin upgrades are largely left to the user, because there's no way to know other than by manual testing if any change breaks everything. There doesn't even seem to be an open source project for containerizing & deploying it immutably (or there wasn't wasn't when I created one 4 years ago). Because everyone's mind is stuck in this box from 2003. Of the bad designs and cloistered practices that were passé 10 years ago.
Organisms can't evolve if they live forever. In order for CMS to evolve, WordPress needs to die. Please just let it die.
There is a good reason why nobody does that: it makes very little sense on any sort of web platform more complex than a static website. Indeed, as the WordPress database schema is quite normalized especially around metadata and taxonomies, there are many INSERT/UPDATE queries running/queued basically all the time on a busy website.
For example, 1ms after you've snapshot your DB and "versioned it" (renamed it rather) locally, it's already obsolete because 2 users have just logged in and their last logon timestamp got updated as metadata stored in the _usermeta table. Switch to the versioned snapshot in the meantime and you lost that information. This is Bad(r).
Even then, say 30s after making the snapshot and before you've "deployed" the code upgrade, a cronjob has triggered an image optimizer plugin, inserting various optimized copies of the image objects in the main _posts table (it also updated the metadata of all those images). Rollback the DB because your deployment caused a crash and you've lost images. Again, a big no-no.
The simplest WordPress-safe upgrade path in case of code changes impacting the database is for the code to support rollup/rolldown migration queries on the database: rename a meta_key when upgrading and rename it back when downgrading.
Use WP abstraction functions to interact with the database, and generally treat the database itself as a blind storage medium, to be restored only in extreme cases.