How to avoid plugins disappearing "en masse"

General Discussion
3

The directory currently checks for the latest version of any plugin.
At this time, if a new version is detected, it can trigger some kind of script that downloads the new version, and store this (and past versions) somewhere.

When you make a mirror, now you have a plugin repository like WP does

For me this is more a “backup” in case someone decides to fork that plugin.

How is the plugin directory supposed to reflect the existence of plugins? If this isn’t handled, making a mirror wouldn’t help, since you have an abandoned plugin anyway and wouldn’t be able to tell. This is the problem that WP has already.

If CP ask for update information for xxx-abandoned-plugin the directory could respond with something like {status:"has-gone"; custom-text:"xxx-abandoned-plugin is dead. Sorry. You should try yyy-adopted-plugin that might be a beautiful alternative."}.

1 Like
4

I don’t think we need to mirror all plugins. I think part of the plugin removal process, the plugin should be forked under official account like Abandoned/Closed Plugins .

Users should be able to download the last available version, in case they accidentally deleted it.

1 Like
5

We’d need an ongoing mirror of the plugin as someone might not bother to flag the plugin in our directory at all, or until after they’d hidden/deleted the GitHub repo.

6

Yeah, but as history shows people don’t care about guidelines
We already ask folks to let their plugins be adopted if they can’t handle them.

So we need a mirror because folks leave things and delete before we even can react
The mirror would solely serve the purpose to allow other folks continuing the plugin maintenance thru a fork.

Right now once a dev deletes the git repo we’d have to ask actual users to share a copy back so we (someone) could continue maintenance

7

Going to the root of the issue: when someone just does something so disruptive as deleting all their presence on a project without thinking twice, it means something bad happened.
First and foremost, before even thinking about the mirror (that to me is just a palliative solution because it doesn’t “solve” the issue of people going away due to communication issues, lack of motivation and the like) i think the real question is: how can we communicate better to avoid this situation to happen again?
I can live with someone who really wants/needs to abandon the project, but I think these people all believed in the project, invested time and skills into it and were in for the long haul.
We can think of many fallback solutions to their going away but we need to solve the real issue.

8

I think the fundamental issue in almost every case has been a mismatch between expectations and reality. If that’s right, then the only thing we can do is manage expectations. But even that is much easier said than done.

9

Yes, that may be the root or the cause why this all happens, but bottom line, no matter why it happens, and no matter what we do - it will always happen.

Having a existing copy (mirror, fork) of everything before that happens would avoid a lot of work chasing down those “disappeared” plugins, so someone could adopt them - or at least, remove the updater from the source and ship a new version, because there you have another issue: updater included in those plugins now ping a website that probably does not have anymore updates for those plugins!

While we couldn’t push the update and would need to make some posting about it, at least we could do it.
As it stands now, I wouldn’t even have a plugin to start working on assuming I would be willing to adopt those plugins, which seem to have been used, after all.

Yes, we can chase them down one by one. And we can do so again, when the next person disappears. Or, we can think ahead, and make a fork of each plugin that gets added to our dir. This can, I think, also happen with some automated process.

Trusting guidelines are followed (they are not), or “finding the root cause and do expectation management” are surely also things we need to consider, yet, they wont avoid the issue. They just minimise it. Having a mirror would allow no one to delete those plugins since the mirror would be cp owned
I would already have set it up, but I have no access to the GIT repos of CP

@James, @wadestriebel - are you the only ones with these caps? If so, can we add such repo at least as a start and then we can think about either manually mirroring those plugins or create some sort of script to do that?

BTW, I want to ask on a sidenote, what happens when we cannot reach out to you 2 anymore for whatever hopefully never happening issue?
Would CP project be inaccessible for “us”?
I find it a little disconcerning that we have only 2 folks with the keys to things :slight_smile:

Perhaps it is time to extend the directorate or “people with access” (with folks who are steadily around, as I have pointed out in past, not all directors are actually present in this community), just in case?
Because if someone of you decides to leave “that way” (I am not saying you will, but I have learned in my almost 40 years on this earth that “thinking and believing is less good than being prepared”)… then the rest of this community would literally be fu**** because not having access to the important parts, if I don’t get it wrong.

We alway discuss a lot, then have to wait for a very narrow amount of folks to permit or actually do things.
Not because “we others” could not or would not want to, but because we simply do not have the keys in hand to do the things.

We already have resolved this issue with DOC and main website access/maintenance, I think. We also need to resolve it with GIT, and other aspects of CP, such as plugin dir, and other important aspects.
But I am diverging. The sole purpose of this thread was to create a mirror to have a emergency copy of plugins or themes that “disappear overnight”
Would that be possible to set up?

10

Unfortunately, misunderstandings can’t be avoided in a multinational forum like ours. Someone with English only as his second language won’t be able to communicate as effectively as a native speaker. For example, he might mean to speak only as clearly and directly as he could, but someone else could take offense for his lack of “tact.”

I agree. As someone pointed out in a thread I started, we could have lots of expectations about the project, but we simply lack the manpower and the resources to deliver them.

I’d been manually installing plugins, and I still have the downloaded ZIPs of most of the plugins I tried. Perhaps I have copies of some of these disappeared plugins. Just send me a list.

11

I think the assumption here is wrong.
The CP directory was intended to be a list of plugins/themes that are available for users. The list needs to be accurate or it’s less useful. But there is no intention to store or maintain the code in the list.
The WP repository actually provides storage space, forums, and visibility in the admin. For that privilege, authors follow the rules. When they don’t, the code is removed.

CP has a roadmap that includes some visibility in the admin, installation and updates for code in the CP directory. But there really is no reason for a mirror or state of emergency over plugins disappearing. It is out of scope for CP to be concerned about external plugins. If, however, this plan for core plugins ever happens, there would need to be a place for those plugins to be stored, and they would need maintenance just like core. (I think splitting things up makes more work than keeping it all together.)

2 Likes
13

Just one thing to think about: one of the plugin we are talking about was not GPL. Don’t know about the others, but eula.txt in the one I’ve installed it’s clear about it.

14

If I understand this right we listed non gpl plugins on our directory?

That’s breaking rule 7 of the directory guidelines:


All Plugins must be compatible with the GNU General Public License; using the same license as ClassicPress (GPLv2 or later) is strongly recommended, but any GPL-compatible license is acceptable.

So I guess it’s good it’s gone. If the others also weren’t gpl … then they never should have been available for cp?

2 Likes
15

I’m not asking to store code
I’m asking to create a git repo where we can mirror plugins and themes so they are available when they are disappearing

That’s all.
I don’t ask to create a code repo from which we can access to in admin or similar.

All that takes as work is:

  • create a repo
  • click “fork” as the owner of that repo so to “save” a plugin to the repo (and for that I am pretty sure we could somehow create a script which would avoid all manual work)

Now, done that, assume a plugin disappears, a wiling dev comes along, they can fork it out of the repo and continue maintenance.

As it is now, we also can do that, but a user would have to come forward and ask + share said plugin for someone to pick it up eventually.

Perhaps that’s ok. Since consensus seems to be no such backup repo is needed I’ll consent …

2 Likes
16

Seems quite simple. And even if you have to manually fork a plugin the first time it’s approved in the directory (it adds very few to the approval process) then a simple cron that uses GitHub API to keep the fork even seems quite easy to set up.

1 Like
17

Yes, Tim is correct about the fundamental issue. But managing expectations is actually not that difficult… you only need to tell people what to expect. The problem is that no-one appears to know.

To me, CP consists of a bunch of random people doing random jobs in a random manner. There is no coherent plan of action, no goals, no timeline, no priorities. It is littered with projects that are half-finished, stalled, forgotten or abandoned. Maybe this is typical for open source projects… I don’t know, it’s my first experience. But I can certainly understand why people get disheartened, lose interest and leave.

And please don’t point to the “roadmap” as if it has any answers. It’s not a roadmap. A roadmap is something you can use to plan a journey from A to B. ClassicPress only has a wishlist. It mentions some vague goals in a vague order and basically says: “We hope these will happen some day”.

The result is that contributors work in a sporadic way and have no idea whether their input is important, or somewhat useful or a total waste of time. That’s how I feel now - I spent a lot of time working on something that I thought was a significant contribution, but maybe I was just wasting my time. Who knows?

By the way, I think the plugins under discussion were never in the directory, nor were they on GitHub. They were made available to CP users via a private website.

2 Likes
18

I agree with plugins being automatically forked (to a private GitHub repository) as soon as they are submitted to the ClassicPress directory.

This is technically feasible, and (in my opinion) ethical as long as we inform developers that this is what will happen and why. I’m envisioning that submitting a plugin would require agreement to a statement that explains that we would use this backup repository in case of the original plugin disappearing and ClassicPress needing to provide a way for existing users of the plugin to receive support/updates.

The plugin directory should provide the ability to change “ownership” of a plugin, so that when a plugin is abandonded, and CP staff changes it over to a new owner/maintainer, existing sites which ask for upgrades would be pointed to the new repository.

2 Likes
19

For the record… any piece of code that is a derivative work of WordPress (same as CP btw…) automatically lies under the GPL2 license, no matter what the developer of the code says, or suggests otherwise.

So, any theme or plugin, free or premium, one that costs $0 or $1,000,000 once someone obtains that piece of code, because it cannot run as a standalone application, it needs WP or CP in order to work, they automatically come with a GPL2 or later license, and nobody can change that license - period.

And because the license is GPL2 or later, once you get a copy of the said derivative work, you can do anything you want with it. Distribute it for free, sell it, change the code, re-brand it, adapt parts of it in another theme/plugin, etc…, you have all the freedoms in the world !

3 Likes
20

@James - would you be able to set up said git Repo?
I am willing to - for now and if I get access to it - fork each one of the plugins manually out. We can write the code later, as we have time and go along, there are not 1000 plugins each month in CP, rather like one a year.
So I am even willing to keep this doing manually for a long time, until it become unbearable.

That would move the topic to a “somewhat resolve Status”

Next up is - please - if possible give me access to the plugin directory so I can start doing that work needed in revising and removing/contacting developers with the bad apples, because … it doesn’t move. We seem to be waiting for something, but I am not sure what we are waiting for.

5 Likes
21

This shouldn’t be too difficult to do as part of the submission process, we require CP plugins to have a repo so we can just fork it automatically. We will want to run it on existing plugins but that should be pretty easy too.

Can we add this to the project list?

2 Likes
22

… not what I see happening… and probably also because we say it is not always needed (too many “if” make any rule even less useful than they are by nature)
Would we maybe want to make it strict and “a GIT is required, no matter what”?
Right now we say

  1. The developer will maintain their own GitHub repository for each plugin which will include a stable version of the plugin (as defined by the creation of a release).
  • It is recommended best practice, but not required, that a release zip is included in a release (added in the Attach binaries by dropping them here or selecting them section).
  • Plugins defined as “Working with ClassicPress” do not require a GitHub repository, although it is recommended, but source code must be available. Plugins without a repository will not benefit from full ClassicPress Directory and core integration.

In either case, yes, it should not be too hard and I have receive access from James for the repo already, so asap I will start forking out plugins. I will then also add this to the project list under “Plugin directory” as a task.

And while doing that, I would really love to prune the bad apples. I already have the list, while forking I will find more. How can we ensure this time we really remove those plugins? It is been a couple weeks now since we know about them but I have no tools/access to remove those plugins and/or devs, or start contact with them, which perhaps would be the friendly way (one week time, then delete)

1 Like
23

A lot of the plugins were added before plugin guidelines were written/finalized. The plugin list needs pruning to bring plugins up to “code”.

1 Like