ClassicPress PetitionsClassicPress Petitions
This is a read-only archive. Post or comment on the live version of this page on our forums.

Support for plugin dev/update on Github

September 8, 2018 · 14:37 · Terence

CassicPress should start to avoid using the WordPress repos, develop its own repos and an alternative plugin and theme developmen platform by actively supporting native Github repos for each, and providing the interface people need to fnd what they want without having to scroll through years of outdated, irrelevant and totally pointless dead plugins and themes.

+20 more
Difficulty: Moderate
Request: Add feature
Request: Modify feature
Fabian Wolf

As written on Slack: Maybe go as far as to create a rudimentary package manager, and enable the user to choose which additional repos to use (or not use). Just like its handled within most current Linux distributions (eg. Debian, Ubuntu, Fedora / Redhat, SuSE etc.).

cu, w0lf.


Good idea, only later. First we need the repos. Then the interface. Then the bells and whistles, I would have thought.

Fabian Wolf

Actually, we need the interface first. Similar to adding F-Droid as a separate source for apps on an Android device vs. the regular Google Play Store. Normally, both co-exist. Which could actually be done using a feature plugin .. :)


OK, as I am not a coder I'll take your word for that.

Daniele Scasciafratte

We was thinking initially to do a cache/proxy that use the official wordpress repository for updates and install plugins initially.
With growing of the community we can evalaute what to do next.


I am a long-time critic of the short sighted view WP has taken on the value of their repositories. Dummy test content in the theme repo hasn't been changed in 10 years or more, and they have only ever done a few easy tweaks in the plugin repo for as long as I can remember, preferring alway to provide community searches with quantity rather than quality answers. I would very much like to be involved with CP doing it right, and supporting developers in the way they choose to operate, rather then forcing them to use a WP-like silo, over which they have little to no control. This was the basis of my proposal. I believe its something CP can do much better, if there's a will to tackle it.

Fabian Wolf
Daniele Scasciafratte

I am more for that support also other systems like bitbucket.
The problem of using an external provider is on security as example.
Now if a plugin version like the last has a security issue with the WP repository this version can be banned or blocked for new installation, also the Tide project in that way can also report and suggest fix for this cases. If we support external provider not under our control we cannot address this cases.


I was going to submit a new Petition on here called "Support installing plugins (or themes) via GitHub" but I think this one is nearly the same.

Ultimately, I think one of the fastest ways that ClassicPress could attract serious attention among developers is not just by being "lighter" (and I think the 'Business-focused CMS' slogan should be dropped), but by making the entire ClassicPress "world" lighter and more dev-friendly as well.

Instead of trying to "aggregate" and control third party extensions, CP could act more like a platform that empowers agencies and beyond. A directory could act more like a meta-engine to index various extensions and perhaps power user reviews of plugins (etc), track active install counts, etc without actually requiring any of their code to be stored on its servers...

Recent Hacker News story:

Example of a meta-engine directory:

Our plugin boilerplate for LittleBizzy has experimented with automated updates via GitHub and its not very difficult. Literally, it could be applied to any repo if they simply add a releases.json file to the repo root. In just a few minutes, volunteers could submit Pull requests to various plugins (etc) to add such a file, and automatic updates would be immediately supported. Of course, this would depend on ClassicPress Core already supporting this approach...

The meta-engine could also warn users when they're installing plugins that are known to have security exploits, etc by recognizing the vendor/product namespace or even the PHP class names in the plugin.

But again, trying to over-moderate anything is a bad idea. Criticizing Automattic for allowing pretty much any plugins fails to recognize the business genius of how they've empowered an entire ecosystem of security plugins, web hosts, and free market (esque) competition. I'm not saying all their decisions are good, but not recognizing their genius hurts CP's chances of success... I also strongly oppose cutting off plugin installations, at least for a very long time, because that would shoot ClassicPress in the foot.

If there is truly going to be decentralization of WordPress, its not going to happen just by slapping up some Democracy values or disabling some of the spam and tracking forced into WordPress by Automattic -- it's going to happen by actually turning over all plugin and theme development AND micro-community management over to the agencies and developers behind them, via GitHub.

In essence, the primary role of the so-called ClassicPress founders and Committee would be to guide Core development, while fielding suggestions and making decisions based on feedback. As a small team, this would be less demanding in financial terms or otherwise, and would also avoid turning CP into yet another dramatic and corrupt OSS fiefdom by emphasizing decentralization. Choosing the right battles, knowing when to honor "upstream", and knowing how to differentiate ClassicPress in simple yet powerful ways is key to any success...

Edit: See also

James Nylen

This is already planned, and I'm updating the status of this petition accordingly. The main focus of ClassicPress v2 will be moving lesser-used or less-wanted features out into "core plugins" which can be disabled or deleted as desired. More info under the "Version 2 Roadmap" section here:

In order to do this, we need to build a directory to host these plugins, and we'll also use this directory to continue growing our own plugin ecosystem. This is currently in the planning stages on our forums. Here is the subforum specific to this effort: