Categories
Blog

Is A Decentralized Plugin Repository Possible?

With all the news floating around about the lawsuits filed between Auttomatic and WP Engine, one important topic has arose, the control over the plugins repository and what can be done to mitigate centralized control. But it begs the question, is this even possible?

With things heating up between Automattic and WP Engine, questions have been raised about the Plugins repository and if a fork should be necessary going forward to preserve access. But exactly how would this work, can it work, and what are the trade offs.

A quick recap of the current situation; a dispute between Matt Mullenweg, Automattic, and WP Engine has caused a rift in the community. The blocking of access to the Plugins repository for WP Engine users has caused concern. The result has been met with some developers to remove their plugins, choosing to host them on their own website.

With that being said, there has been a handful in the community who have wondered if it was possible to remove or replace the built in Plugins API with one of your choosing. A decentralized attempt at running the Plugins repository or at least the option of running/selecting your own.

The How

Duane Storey, former co-founder of popular plugin, WPTouch, ran a recent article, A deep dive, and came to the conclusion that there are close to 1,500 hard coded wordpress.org URLs in the WordPress core. And while changing the domain name is one thing, it’s another on what all these API calls functionally do.

So it should come as no surprise that the Plugins API is not open source, or at least there is no clear documentation about exactly it does and how it works. Reverse engineering is therefore required, tracing all 1,500 API calls and figuring out what each one does.

The Can

This in of itself will be a challenge, although not theoretically impossible. There are already a few communities working on this very endeavor such as WhitelabelPress and AspirePress.

WhitelabelPress has decided to fork an already accomplished version of this back when WordPress was forked before the launch of Gutenberg called ClassicPress. ClassicPress uses its own Plugins repository to make sure their forked version has working plugins, since all code changes made to WordPress from 4.7 onward can have removed/modified hooks and/or additional hooks for Gutenberg and the block editor.

So its not like this hasn’t been done before, since ClassicPress has already accomplished this back during their fork. Although not without controversy since the majority of WordPress plugins no longer work with the forked version and vice versa.

And About those Tradeoffs?

What about the security issues around using an unknown repository? Should the wall garden approach get another look over?

Interestingly enough, this too has been recently debated when WordPress’s X account posted a tweet about downloading themes from an outside source when discussing concerns about vulnerabilities from 3rd party sources for themes:

“When you see articles about vulnerabilities like this… note that this is not a theme that goes through the .org directory. It’s a theme distributed by Themeforest, CodeCanyon, and WPLMS directly. Be wary of non-.org distribution.”1

Which at this point was then quickly challenged by the CEO of PatchStack, Oliver Sild, a well-known security researcher, who responded to the WordPress account:

“90%+ of all security vulnerabilities found in WordPress plugins/themes come from those that are distributed via .org,”2

So its not like there are no vulnerabilities in the official Plugins repository, although one can argue that more would be audited from there since it is by far the largest known and default location.

But caution should be advised when using a 3rd party from an unknown source. And it is true that many have had their websites compromised when using a “nulled” version of a plugin (the process of removing any licensing restrictions on a paid plugin).

One could state that downloading plugins from a notable/reliable 3rd party source such as CodeCanyon which up-keeps plugin development is not the same as to replace the built-in plugin repository to another hosted source.

The question is still out on whether going forward there will be options to select a different Plugins repository. There are people working right now on a solution and it remains to be seen whether the WordPress community as a whole is welcome to the approach.

  1. https://x.com/WordPress/status/1856111633258701114 ↩︎
  2. https://x.com/OliverSild/status/1856256292882469347 ↩︎

Leave a Reply

Your email address will not be published. Required fields are marked *