Crossover between plugin directory and WP repo

Something occurred to me regarding the planned CP plugin directory.

What happens if a plugin author has a plugin in the WP repo and wants to also put it in the CP directory? Can they use the same name/slug? (e.g. myplugin/myplugin.php)

If so, how will CP determine where to check for plugin updates?

Or will CP be insisting that plugins in the CP directory have different identifiers from anything in the WP repo?

5 Likes

That’s a good question.

I’ve not prototyped this yet so don’t take this as gospel, but I’d like to support author/plugin/plugin.php, where author is the CP directory display name slug.

We can’t stop devs creating a plugin with the same slug as an existing one - e.g. if they fork one - so by prefixing with the author we don’t have to jump through many hoops to ensure things are unique.

It also means we can inherit the WP repo under the wordpress author.

3 Likes

I’ve experienced this issue… I wrote an internal plugin that matched a WP repo plugin’s structure which caused my plugin to keep notifiying me for his updates. Of course, updating would have wiped out my plugin. I’ve resorted to prefixing all my (top-level) directories with my vendor name: codepotent-this, codepotent-that, presuming nobody else will use that prefix, of course. As an added benefit, it keeps all my plugins together in the directory tree.

3 Likes

I quite like that idea - including an author slug in the plugin path.

I guess an alternative would be to have a line in the comments block at the start of the plugin main file (where the name and version are), something like:

Ecosystem: ClassicPress

That could also work, if ClassicPress plugin updater code looked for it when determining the URL to fetch.

1 Like

Yes, but then we’d need to make sure every plugin slug was unique - if we use the author we don’t need to worry about that.

As for fetching things, the CP update code is going to be very dumb: dependency resolution will happen server-side, as will determining the URL for the plugin zip.

1 Like

I haven’t tried this either, but I suspect it would break a bunch of stuff.

2 Likes

So do I, which is why it’s not part of the spec yet, but if it does we can restrict it to CP plugins; not as clean or elegant as having all the WP plugins in a wordpress directory, but if it works…

1 Like

Wouldn’t it be a good idea that every plugin slug is unique anyway? Avoids confusion.

2 Likes

I prefer the author-plugin/plugin.php method as already used by @anon71687268. That shouldn’t break anything.

4 Likes

Yes, on reflection that should be a fairly safe and therefore sensible approach.

4 Likes

To clarify, I use the author-plugin/author-plugin.php scheme. The way @1stepforward mentioned (with author only on left of slash) is also viable. Is there a difference? Not really. I just like the directory and primary filename to match because it adds a tiny bit of predictability. :slight_smile:

4 Likes

I use the azrcrv abbreviation on my folders and main plugin file (e.g. azrcrv-avatars/azrcrv-avatars.php)

4 Likes

+1 for this!

But another thing could be to prevent users from registering plugins that already exists on the WP Repo (if it’s not the one in the WP repo). It’s not just a matter of the software working right… it seems me more transparent to users and more politically correct with WordPress.

Stupid example… what if tomorrow I publish my plugin called “Gutemberg” that is for dealing with google fonts?

This can allow to say something like “The plugin name should be in the form author-plugin/author-plugin.php and must not have the same name of another plugin in the WP repo”.

5 Likes

If this were a rule, it would automatically remove 50-60k viable slugs from our ecosystem right out of the gate.

3 Likes

Sadly true! :laughing:
But having the same name of another plugin could be misleading for users.
And, if “avatars” in the CP directory is better than “avatars” in the WP repo +1 for CP, but reversing things…

3 Likes

I thought a new method was going to be used to ascertain that the correct plugin was referenced. There was some talk and code produced for WP for using hashes to make sure that the plugin was the right one even if it used the same slug or was renamed to a different slug. This fix got bogged down (the person driving it went off to do something else), but I thought that was what would be built-in to the CP directory. Learning from the mistake of using just the slug, we would proceed by making a new system that uses a hash instead. (of course, you would have to store the hash)

2 Likes

Yes, that’s why I made the suggestion of adding something in the comment block further up this thread.

There is still a fundamental issue that ClassicPress core should know which repo/source to check for an update without having to try one source first and then try the other if the plugin wasn’t found in the first one. That would double the cron load for plugin updates.

2 Likes

Is there some kind of scoping document for the new directory floating around anywhere?

1 Like

Plugin Directory Design

3 Likes