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.
After looking at their repos, especially [1], I think it'd probably have been better if they made a soft-fork of Wordpress with its own infrastructure instead of the current setup where they try to hijack core wordpress with alternative implementations. This approach is doomed to fail, as the core Wordpress developers would be forced by executive directives to break said mechanisms.
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.
Seems smart to start by contributing a more openly governed path. If Matt starts to fight, sabotage and shut that down it gives the important yeah-we-did-try style cover to the reasonable next step of forking.
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.
I don't think it's likely that core will actively break these things. If they removed the ability to filter HTTP requests, they'd break a lot of plugins and likely a lot of sites, which would become a nightmare, because their main selling point is "one click install, never worry about it again" -- they primarily compete with Wix, Jimdo etc, not with other CMS.
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.
The contributors who worked on this project (including myself - I'm one of the TSC co-chairs) are very familiar with the internals of WordPress - we were the ones who wrote them :)
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.
> 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.
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.
I suspect, without knowing anything, that WPEngine's lawsuit will put wordpress in a position where they can't do anything to suppress alternative implementations of their infrastructure.
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.
> People don't want to fork because they don't want to pay for wordpress development.
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.
> am pretty much on the side of wordpress in the big dispute
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.
Migrating to SSG is definitely one of the options!
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/
I feel like Grav was waaay ahead of its time. For the past year I've been chipping away at something inspired by it but written in Rust with KDL as the format for storing pages (and page data).
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.
I wrote a Wordpress to Grav exporter [1], which brings over most content (posts, pages, users, groups, attachments, some site-metadata, etc). I also wrote a Drupal 7 one, but I haven't touched that in a long while.
After exporting from either CMS, it's pretty close to drag/ drop onto the grav instance and everything should "Just Work (tm)".
> 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.
This is very exciting to see momentum going in this trajectory.
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.
Are they going to be able to maintain the volunteer team who curate the catalogue? Currently a fair amount of work goes into making sure that hosted packages do not contain malware and also add value in that they don't replicate the features of existing packages. This workload has increased recently with AI generated submissions.
TSC co-chair here - one of my fellow co-chairs (Mika Epstein, aka Ipstenu) was the lead of the plugin review team for a long time, and several other contributors have been very involved in the plugin review processes, so definitely something that’s top of mind for us.
Somewhat unfortunate naming as it may be confusing with the FAIR Principles (Findable, Accessible, Interoperable, Reusable), for which software package managers are emerging as well.
Any TLDR on how actually use it, from the plugin developer perspective? I was immediately put off by having to run a WP plugin just to obtain a “did”, and having to run WP to host the repository is also far from ideal.
I wish this was an evolution from bedrock, or that it used some composer infrastructure (which works with just static files).
The protocol repository [1] has more documentation on how to implement your own repository and we expect there’ll be many implementations of it over time - for launch, our proof-of-concept repo is built on WP since it integrates with Git Updater which is already widely used. (We’ll try and publish to Packagist now that it’s public too!)
It's unfortunate that WordPress.org has to be replaced, it requiring plugins to be gplv2 licensed has forced the ecosystem be almost fully open source.
Doubt this is going to be the case if FAIR takes over.
Has that ever actually been tested though? Ultimately, to work, a plugin only needs to call a handful of WP functions, if at all -- hard to argue it's a derivative work, just because it can be used _with_ WP. Is grep a derivative work of bash because you can use bash to execute grep?
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
}
I've always been confused by this assertion, too. It's often the justification for privacy of paid plugins, too.
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).
Yeah, the infectious nature can hardly infect a third party software, even if the shim itself would be infected.
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.
“ a federated and independent repository of trusted plugins and themes for web hosts, commercial plugin and tool developers in the WordPress ecosystem and end users.” The goal of this project is blurred. They want to move away from WP and allow commercial plug-ins. Both are very hard to accomplish. Forking WP and build a community was more transparant and easier to do. Since WP is gpl , there has for a long time been too many violations by commercial plugin sellers. You can sell your plug-in, but you must apply with the gpl terms. So release all the code. Too many plugins are malware, since code is loaded by an api call. No trust, no security and no privacy.
I currently work for a multi-million dollar company that is completely dependent on this lumbering geriatric. A design from the turn of the century, that limits how we can configure it, modify it, test it, version it, deploy it, roll it back. A rotting piece of fruit with so many bugs and holes we need to constantly look for a newly-announced bug so we can rush to patch it so the rot doesn't spread to our business.
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.
> 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)
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.
This is my point. The problem is WordPress's design. Despite that, there are better practices... but the best practice would be not to use a design from 20 years ago.
Linux Foundation's announcement here https://www.linuxfoundation.org/press/linux-foundation-annou...
EDIT - HN Discussion about it here https://news.ycombinator.com/item?id=44205865
Very cool!
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.
0: https://atproto.com/
1: https://www.ipfs.tech/
2: https://radicle.xyz/
3: https://github.com/n0-computer/iroh
4: https://github.com/fairpm/fair-protocol
Thanks! I've added that link to the top text as well.
After looking at their repos, especially [1], I think it'd probably have been better if they made a soft-fork of Wordpress with its own infrastructure instead of the current setup where they try to hijack core wordpress with alternative implementations. This approach is doomed to fail, as the core Wordpress developers would be forced by executive directives to break said mechanisms.
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.
[1] https://github.com/fairpm/fair-plugin
Seems smart to start by contributing a more openly governed path. If Matt starts to fight, sabotage and shut that down it gives the important yeah-we-did-try style cover to the reasonable next step of forking.
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.
I don't think it's likely that core will actively break these things. If they removed the ability to filter HTTP requests, they'd break a lot of plugins and likely a lot of sites, which would become a nightmare, because their main selling point is "one click install, never worry about it again" -- they primarily compete with Wix, Jimdo etc, not with other CMS.
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.
The contributors who worked on this project (including myself - I'm one of the TSC co-chairs) are very familiar with the internals of WordPress - we were the ones who wrote them :)
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.
> 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.
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...
I suspect, without knowing anything, that WPEngine's lawsuit will put wordpress in a position where they can't do anything to suppress alternative implementations of their infrastructure.
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.
> People don't want to fork because they don't want to pay for wordpress development.
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.
> am pretty much on the side of wordpress in the big dispute
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.
Sad to say, but for the meantime Wordpress is a dead end at least for my personal needs.
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.
[1]: https://gioorgi.com/2024/liberta-come-aria/
Migrating to SSG is definitely one of the options!
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/
I feel like Grav was waaay ahead of its time. For the past year I've been chipping away at something inspired by it but written in Rust with KDL as the format for storing pages (and page data).
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.
about KDL https://news.ycombinator.com/item?id=28510031 kdl stands for 'cuddly' document language
I wrote a Wordpress to Grav exporter [1], which brings over most content (posts, pages, users, groups, attachments, some site-metadata, etc). I also wrote a Drupal 7 one, but I haven't touched that in a long while.
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/
This is the official website for FAIR: http://fair.pm/ . It currently redirects to https://github.com/fairpm . Here's a description:
> 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
This is very exciting to see momentum going in this trajectory.
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.
Related:
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)
Doing the lord's work!
Here's another timeline https://gist.github.com/adrienne/aea9dd7ca19c8985157d9c42f7f...
Are they going to be able to maintain the volunteer team who curate the catalogue? Currently a fair amount of work goes into making sure that hosted packages do not contain malware and also add value in that they don't replicate the features of existing packages. This workload has increased recently with AI generated submissions.
TSC co-chair here - one of my fellow co-chairs (Mika Epstein, aka Ipstenu) was the lead of the plugin review team for a long time, and several other contributors have been very involved in the plugin review processes, so definitely something that’s top of mind for us.
Somewhat unfortunate naming as it may be confusing with the FAIR Principles (Findable, Accessible, Interoperable, Reusable), for which software package managers are emerging as well.
All names are unfortunate. There are too many things.
"What we are doing is adding a new distribution layer and putting our own governance on top of it."
this is awesome, congrats on the launch
Any TLDR on how actually use it, from the plugin developer perspective? I was immediately put off by having to run a WP plugin just to obtain a “did”, and having to run WP to host the repository is also far from ideal.
I wish this was an evolution from bedrock, or that it used some composer infrastructure (which works with just static files).
The protocol repository [1] has more documentation on how to implement your own repository and we expect there’ll be many implementations of it over time - for launch, our proof-of-concept repo is built on WP since it integrates with Git Updater which is already widely used. (We’ll try and publish to Packagist now that it’s public too!)
[1]: https://github.com/fairpm/fair-protocol
[dead]
Connection fail.
Hey, look at that: a foundation that offers development time without demanding it back
Kill wordpress please, it's abomination
It's unfortunate that WordPress.org has to be replaced, it requiring plugins to be gplv2 licensed has forced the ecosystem be almost fully open source.
Doubt this is going to be the case if FAIR takes over.
FAIR plugin is gplv2. They will continue to use the core of Wordpress, also gplv2.
Can you explain how this would allow any other license than gplv2 for the plugins?
I think what the parent is saying is:
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.
and what I am saying is: wordpress core is gplv2. A plugin is therefore under gplv2 per the definition of the gplv2 of derivative work.
https://wordpress.org/support/topic/are-wordpress-plugins-au...
https://wordpress.stackexchange.com/questions/406337/does-wo...
Has that ever actually been tested though? Ultimately, to work, a plugin only needs to call a handful of WP functions, if at all -- hard to argue it's a derivative work, just because it can be used _with_ WP. Is grep a derivative work of bash because you can use bash to execute grep?
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 }
I've always been confused by this assertion, too. It's often the justification for privacy of paid plugins, too.
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).
Yeah, the infectious nature can hardly infect a third party software, even if the shim itself would be infected.
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...
No, it must be according to the core‘s license, but if the plugin author doesn‘t license it as GPLv2, it isn‘t.
The plugin‘s author breaches the core‘s license, but that doesn‘t make the plugin GPLv2 by itself.
“ a federated and independent repository of trusted plugins and themes for web hosts, commercial plugin and tool developers in the WordPress ecosystem and end users.” The goal of this project is blurred. They want to move away from WP and allow commercial plug-ins. Both are very hard to accomplish. Forking WP and build a community was more transparant and easier to do. Since WP is gpl , there has for a long time been too many violations by commercial plugin sellers. You can sell your plug-in, but you must apply with the gpl terms. So release all the code. Too many plugins are malware, since code is loaded by an api call. No trust, no security and no privacy.
I currently work for a multi-million dollar company that is completely dependent on this lumbering geriatric. A design from the turn of the century, that limits how we can configure it, modify it, test it, version it, deploy it, roll it back. A rotting piece of fruit with so many bugs and holes we need to constantly look for a newly-announced bug so we can rush to patch it so the rot doesn't spread to our business.
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.
> 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)
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.
Are there any particular plugins you could point me to that implement a db rolldown functionality?
> The simplest WordPress-safe upgrade path
This is my point. The problem is WordPress's design. Despite that, there are better practices... but the best practice would be not to use a design from 20 years ago.