_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI The FAIR Package Manager: Decentralized WordPress infrastructure
Coala15 wrote 4 hours 44 min ago:
Kill wordpress please, it's abomination
ollybee wrote 6 hours 2 min 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 wrote 1 hour 47 min 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.
runningmike wrote 6 hours 31 min 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.
0xbadcafebee wrote 8 hours 27 min 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 wrote 4 hours 2 min 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.
kassner wrote 9 hours 26 min 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 wrote 8 hours 14 min 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]
URI [1]: https://github.com/fairpm/fair-protocol
bravetraveler wrote 10 hours 42 min ago:
Hey, look at that: a foundation that offers development time without
demanding it back
jacooper wrote 11 hours 31 min 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 wrote 10 hours 22 min 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 wrote 4 hours 34 min 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 wrote 3 hours 36 min 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. [1]
URI [1]: https://wordpress.org/support/topic/are-wordpress-plugin...
URI [2]: https://wordpress.stackexchange.com/questions/406337/doe...
luckylion wrote 2 hours 34 min 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.
sjs382 wrote 2 hours 1 min ago:
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).
luckylion wrote 6 min ago:
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.
URI [1]: https://wptavern.com/mullenweg-and-pearson-square-...
Tomte wrote 3 hours 19 min 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.
Flimm wrote 12 hours 1 min ago:
This is the official website for FAIR: [1] . It currently redirects to
[2] . 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: [2] /fair-plugin/releases
URI [1]: http://fair.pm/
URI [2]: https://github.com/fairpm
URI [3]: https://github.com/fairpm/fair-plugin/releases
JimDabell wrote 12 hours 23 min ago:
Related:
WordPress.org bans WP Engine - [1] - Sep 2024 (490 comments)
If WordPress is to survive, Matt Mullenweg must be removed - [2] - Sep
2024 (245 comments)
WP Engine is not WordPress - [3] - Sep 2024 - (165 comments)
Filed: WP Engine Inc. v Automattic Inc. and Matthew Charles Mullenweg
[pdf] - [4] - Oct 2024 - (659 comments)
The ACF plugin on the WordPress directory has been taken over by
WordPress.org - [5] - Oct 2024 (224 comments)
So long WordPress - [6] - Oct 2024 (211 comments)
WordPress.org's latest move involves taking control of a WP Engine
plugin - [7] - Oct 2024 (211 comments)
Is Matt Mullenweg defending WordPress or sabotaging it? - [8] - Oct
2024 - (143 comments)
Mullenweg threatens corporate takeover of WP Engine - [9] - Oct 2024 -
(120 comments)
Matt Mullenweg cries foul and threatens me with legal action - [10] -
Oct 2024 - (43 comments)
Matt Mullenweg temporarily shuts down some Wordpress.org functions -
[11] - Dec 2024 - (122 comments)
WordPress Is in Trouble - [12] - Jan 2025 (439 comments)
Matt Mullenweg deactivates WordPress accounts of contributors planning
a fork - [13] - Jan 2025 (236 comments)
Mullenweg Shuts Down WordPress Sustainability Team, Igniting Backlash -
[14] - Jan 2025 - (172 comments)
Matt Mullenweg, Automattic's CEO, Seems Bound and Determined to Wreck
WordPress - [15] - Jan 2025 - (57 comments)
URI [1]: https://news.ycombinator.com/item?id=41655967
URI [2]: https://news.ycombinator.com/item?id=41676653
URI [3]: https://news.ycombinator.com/item?id=41613628
URI [4]: https://news.ycombinator.com/item?id=41726197
URI [5]: https://news.ycombinator.com/item?id=41821400
URI [6]: https://news.ycombinator.com/item?id=41974637
URI [7]: https://news.ycombinator.com/item?id=41826082
URI [8]: https://news.ycombinator.com/item?id=41872628
URI [9]: https://news.ycombinator.com/item?id=41712617
URI [10]: https://news.ycombinator.com/item?id=41727888
URI [11]: https://news.ycombinator.com/item?id=42469708
URI [12]: https://news.ycombinator.com/item?id=42687121
URI [13]: https://news.ycombinator.com/item?id=42667766
URI [14]: https://news.ycombinator.com/item?id=42672675
URI [15]: https://news.ycombinator.com/item?id=42773311
nchmy wrote 9 hours 44 min ago:
Doing the lord's work!
Here's another timeline
URI [1]: https://gist.github.com/adrienne/aea9dd7ca19c8985157d9c42f7f...
daitangio wrote 12 hours 24 min 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]
URI [1]: https://gioorgi.com/2024/liberta-come-aria/
KronisLV wrote 11 hours 58 min 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):
URI [1]: https://getgrav.org/
wingmanjd wrote 3 hours 5 min 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]
-
URI [1]: https://github.com/jgonyea/wp2grav_exporter
URI [2]: https://www.drupal.org/project/grav_export/
aquariusDue wrote 11 hours 34 min 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 wrote 10 hours 26 min ago:
about KDL [1] kdl stands for 'cuddly' document language
URI [1]: https://news.ycombinator.com/item?id=28510031
sensahin wrote 13 hours 57 min ago:
"What we are doing is adding a new distribution layer and putting our
own governance on top of it."
hajimuz wrote 14 hours 23 min ago:
Connection fail.
roelj wrote 14 hours 30 min 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 wrote 12 hours 52 min ago:
All names are unfortunate. There are too many things.
supriyo-biswas wrote 14 hours 38 min 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.
URI [1]: https://github.com/fairpm/fair-plugin
pessimizer wrote 7 hours 42 min ago:
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.
nchmy wrote 2 hours 19 min ago:
> 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.
luckylion wrote 6 hours 46 min ago:
> 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.
nchmy wrote 9 hours 47 min ago:
> 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) [1] 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
URI [1]: https://news.ycombinator.com/item?id=41839864
URI [2]: https://gist.github.com/adrienne/aea9dd7ca19c8985157d9c42f7f...
luckylion wrote 12 hours 50 min 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 wrote 6 hours 27 min ago:
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.
lawik wrote 12 hours 53 min 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.
mastazi wrote 14 hours 45 min ago:
Linux Foundation's announcement here [1] EDIT - HN Discussion about it
here
URI [1]: https://www.linuxfoundation.org/press/linux-foundation-announc...
URI [2]: https://news.ycombinator.com/item?id=44205865
snthpy wrote 12 hours 59 min 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: [1] 1: [2] 2: [3] 3: [4] 4:
URI [1]: https://atproto.com/
URI [2]: https://www.ipfs.tech/
URI [3]: https://radicle.xyz/
URI [4]: https://github.com/n0-computer/iroh
URI [5]: https://github.com/fairpm/fair-protocol
dang wrote 14 hours 41 min ago:
Thanks! I've added that link to the top text as well.
samename wrote 14 hours 46 min ago:
this is awesome, congrats on the launch
tobinfekkes wrote 14 hours 55 min 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.
DIR <- back to front page