6 ms·

The FAIR Package Manager: Decentralized WordPress infrastructure

210 points by twapi 1y ago

Related: https://github.com/fairpm https://github.com/fairpm, https://www.linuxfoundation.org/press/linux-foundation-announces-the-fair-package-manager-project-for-open-source-content-management-system-stability https://www.linuxfoundation.org/press/linux-foundation-annou....

tobinfekkes 1y ago
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.
samename 1y ago
this is awesome, congrats on the launch
mastazi 1y ago
Linux Foundation's announcement here https://www.linuxfoundation.org/press/linux-foundation-announces-the-fair-package-manager-project-for-open-source-content-management-system-stability https://www.linuxfoundation.org/press/linux-foundation-annou... EDIT - HN Discussion about it here https://news.ycombinator.com/item?id=44205865 https://news.ycombinator.com/item?id=44205865
- dang 1y ago
  Thanks! I've added that link to the top text as well.
- snthpy 1y ago
  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/ https://atproto.com/ 1: https://www.ipfs.tech/ https://www.ipfs.tech/ 2: https://radicle.xyz/ https://radicle.xyz/ 3: https://github.com/n0-computer/iroh https://github.com/n0-computer/iroh 4: https://github.com/fairpm/fair-protocol https://github.com/fairpm/fair-protocol
supriyo-biswas 1y ago
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 https://github.com/fairpm/fair-plugin
- lawik 1y ago
  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.
- luckylion 1y ago
  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.
  - rmccue 1y ago
roelj 1y ago
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.
- lawik 1y ago
  All names are unfortunate. There are too many things.
hajimuz 1y ago
Connection fail.
sensahin 1y ago
"What we are doing is adding a new distribution layer and putting our own governance on top of it."
deleted 1y ago
[deleted]
daitangio 1y ago
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/ https://gioorgi.com/2024/liberta-come-aria/
- KronisLV 1y ago
  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/ https://getgrav.org/
  - aquariusDue 1y ago
    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.
    - homarp 1y ago
      about KDL https://news.ycombinator.com/item?id=28510031 https://news.ycombinator.com/item?id=28510031 kdl stands for 'cuddly' document language
  - wingmanjd 1y ago
    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 https://github.com/jgonyea/wp2grav_exporter - [2] https://www.drupal.org/project/grav_export/ https://www.drupal.org/project/grav_export/
JimDabell 1y ago
Related: WordPress.org bans WP Engine - https://news.ycombinator.com/item?id=41655967 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 https://news.ycombinator.com/item?id=41676653 - Sep 2024 (245 comments) WP Engine is not WordPress - https://news.ycombinator.com/item?id=41613628 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 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 https://news.ycombinator.com/item?id=41821400 - Oct 2024 (224 comments) So long WordPress - https://news.ycombinator.com/item?id=41974637 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 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 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 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 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 https://news.ycombinator.com/item?id=42469708 - Dec 2024 - (122 comments) WordPress Is in Trouble - https://news.ycombinator.com/item?id=42687121 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 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 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 https://news.ycombinator.com/item?id=42773311 - Jan 2025 - (57 comments)
- nchmy 1y ago
Flimm 1y ago
This is the official website for FAIR: http://fair.pm/ http://fair.pm/ . It currently redirects to https://github.com/fairpm 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 https://github.com/fairpm/fair-plugin/releases
jacooper 1y ago
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.
- homarp 1y ago
  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?
  - sjs382 1y ago
    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.
    - homarp 1y ago
      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-automatically-gpl/ https://wordpress.org/support/topic/are-wordpress-plugins-au... https://wordpress.stackexchange.com/questions/406337/does-wordpress-being-under-gpl-actually-necessitate-that-the-tools-created-for-i https://wordpress.stackexchange.com/questions/406337/does-wo...
      - Tomte 1y ago
        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.
      - luckylion 1y ago
        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 }
bravetraveler 1y ago
Hey, look at that: a foundation that offers development time without demanding it back
kassner 1y ago
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).
- rmccue 1y ago
  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 https://github.com/fairpm/fair-protocol
0xbadcafebee 1y ago
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.
- vntok 1y ago
  > 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.
runningmike 1y ago
“ 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.
ollybee 1y ago
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.
- rmccue 1y ago
  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.
Coala15 1y ago
Kill wordpress please, it's abomination
vincentjuan211 1y ago
[dead]

210 points by twapi 1y ago

tobinfekkes 1y ago

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.

samename 1y ago

this is awesome, congrats on the launch

mastazi 1y ago

Linux Foundation's announcement here https://www.linuxfoundation.org/press/linux-foundation-announces-the-fair-package-manager-project-for-open-source-content-management-system-stability https://www.linuxfoundation.org/press/linux-foundation-annou... EDIT - HN Discussion about it here https://news.ycombinator.com/item?id=44205865 https://news.ycombinator.com/item?id=44205865

dang 1y ago
Thanks! I've added that link to the top text as well.
snthpy 1y ago
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/ https://atproto.com/ 1: https://www.ipfs.tech/ https://www.ipfs.tech/ 2: https://radicle.xyz/ https://radicle.xyz/ 3: https://github.com/n0-computer/iroh https://github.com/n0-computer/iroh 4: https://github.com/fairpm/fair-protocol https://github.com/fairpm/fair-protocol

supriyo-biswas 1y ago

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 https://github.com/fairpm/fair-plugin

lawik 1y ago
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.
luckylion 1y ago
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.
- rmccue 1y ago

roelj 1y ago

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.

lawik 1y ago
All names are unfortunate. There are too many things.

hajimuz 1y ago

Connection fail.

sensahin 1y ago

"What we are doing is adding a new distribution layer and putting our own governance on top of it."

deleted 1y ago

[deleted]

daitangio 1y ago

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/ https://gioorgi.com/2024/liberta-come-aria/

KronisLV 1y ago
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/ https://getgrav.org/
- aquariusDue 1y ago
  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.
  - homarp 1y ago
    about KDL https://news.ycombinator.com/item?id=28510031 https://news.ycombinator.com/item?id=28510031 kdl stands for 'cuddly' document language
- wingmanjd 1y ago
  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 https://github.com/jgonyea/wp2grav_exporter - [2] https://www.drupal.org/project/grav_export/ https://www.drupal.org/project/grav_export/

JimDabell 1y ago

Related: WordPress.org bans WP Engine - https://news.ycombinator.com/item?id=41655967 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 https://news.ycombinator.com/item?id=41676653 - Sep 2024 (245 comments) WP Engine is not WordPress - https://news.ycombinator.com/item?id=41613628 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 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 https://news.ycombinator.com/item?id=41821400 - Oct 2024 (224 comments) So long WordPress - https://news.ycombinator.com/item?id=41974637 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 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 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 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 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 https://news.ycombinator.com/item?id=42469708 - Dec 2024 - (122 comments) WordPress Is in Trouble - https://news.ycombinator.com/item?id=42687121 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 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 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 https://news.ycombinator.com/item?id=42773311 - Jan 2025 - (57 comments)

nchmy 1y ago

Flimm 1y ago

This is the official website for FAIR: http://fair.pm/ http://fair.pm/ . It currently redirects to https://github.com/fairpm 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 https://github.com/fairpm/fair-plugin/releases

jacooper 1y ago

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.

homarp 1y ago
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?
- sjs382 1y ago
  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.
  - homarp 1y ago
    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-automatically-gpl/ https://wordpress.org/support/topic/are-wordpress-plugins-au... https://wordpress.stackexchange.com/questions/406337/does-wordpress-being-under-gpl-actually-necessitate-that-the-tools-created-for-i https://wordpress.stackexchange.com/questions/406337/does-wo...
    - Tomte 1y ago
      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.
    - luckylion 1y ago
      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 }

bravetraveler 1y ago

Hey, look at that: a foundation that offers development time without demanding it back

kassner 1y ago

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).

rmccue 1y ago
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 https://github.com/fairpm/fair-protocol

0xbadcafebee 1y ago

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.

vntok 1y ago
> 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.

runningmike 1y ago

“ 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.

ollybee 1y ago

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.

rmccue 1y ago
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.

Coala15 1y ago

Kill wordpress please, it's abomination

vincentjuan211 1y ago

[dead]