Support for plugin dev/update on Github

[discobot]

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.

---

Read-only archive: Issues · ClassicPress/ClassicPress · GitHub

Author: Terence

Vote count: 26

Status: planned

See ClassicPress | Stable. Lightweight. Instantly Familiar. and https://forums.classicpress.net/c/plugins/plugin-directory

~ posted by James Nylen

Tags:

• request-modify-feature
• difficulty-moderate
• request-add-feature

---

Comments

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.

~ posted by Fabian Wolf

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

~ posted by Terence

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 …

~ posted by Fabian Wolf

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

~ posted by Terence

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.

~ posted by Daniele Scasciafratte

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.

~ posted by Terence

Github Updater, anyone? GitHub - afragen/git-updater: This WP plugin will update GitHub, Bitbucket, GitLab, and Gitea hosted plugins and themes

~ posted by Fabian Wolf

I am more for GitHub - YahnisElsts/plugin-update-checker: A custom update checker for WordPress plugins. Useful if you don't want to host your project in the official WP repository, but would still like it to support automatic updates. Despite the name, it also works with themes. 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.

~ posted by Daniele Scasciafratte

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 ClassicPress.net 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:
Shopify and the Power of Platforms – Stratechery by Ben Thompson

Example of a meta-engine directory:
https://www.staticgen.com

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…

GitHub - littlebizzy/plugin-boilerplate: PHP boilerplate used in all WordPress plugins released by LittleBizzy that supports automatic updates for both public and private GitHub repos.
GitHub - littlebizzy/repo-man: Adds GitHub search for WordPress plugins and themes to avoid WordPress.org lock-in, and supports one-click installation and automatic plugin updates.

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 WordPress.org 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 Issues · ClassicPress/ClassicPress · GitHub

~ posted by Jesse

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: ClassicPress | Stable. Lightweight. Instantly Familiar.

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: https://forums.classicpress.net/c/plugins/plugin-directory

~ posted by James Nylen

[wadestriebel]

Making good progress towards this, please see Directory Discussion - Jan 17th, 2021 for some discussion that happened re the directory after the Marketing Meeting on the 17th. Any input is welcome

[viktor]

This will be achieved with the new ClassicPress-powered plugin/theme directory.

GitHub - ClassicPress/Directory: ClassicPress Directory for plugins, themes,...