Plugin Directory Structure

#1

Following on from the original thread, below is my take on what was discussed.

A directory, rather than repository is required, into which developers can submit plugins:

  • The plugins will be automatically reviewed, but processes for manual review need to be created.
  • The directory will hold a link to the developers repository (I imagine rules on repo structure would be required; similar to SVN on WP.org).
  • Are plugins identified on slug (as per WP) or using another ID such as a GUID? If the latter, how are duplicate names to be avoided?
  • Plugins need to be identified as Free/Freemium/Premium - this requires discussion as there is some differences on whether Freemium should be a separate category; personally, I think it should as they are middle ground between Free and Premium paid for plugins.

Types of plugins:

  • Free - completely free, un-crippled, and not soliciting in any way.
  • Freemium - some functionality free, but some requiring payment to plugin developer.
  • Premium - paid, with no functionality available otherwise.

Visibility of the directory to users via tabs:

  • Featured - A list of plugins that pay a monthly fee for placement. Non-paginated. Both free and premium plugins would be free to take advantage of this. Custom sort based on premium paid…
  • Latest - A list of the latest n plugins. Paginated. Or, even filterable down to new this week or new this month. Default to descending sort on creation-date.
  • Popular - A list of the most popular n plugins. Paginated, or filterable, based on number of downloads of current version in x period (e.g. last 90 days).
    Browse - Paginated. Default to descending sort on last-updated date, but with filters for users to include, or exclude types of plugins (Free/Premium) and tags.
  • WordPress - Does CP need to maintain a link to the CP repository in the early days due to lack of volume in CP directory? I would not mirror as this will likely cause problems down the line, but allowing users to search for a plugin in the WP Repo might be beneficial.

If I’ve missed, or misinterpreted anything, please add a comment.

#2

Are there any security concerns around it being a directory linking to the developers GitHub repo rather than a CP repo?

#3

Will the plugins in this directory be restricted to those where the developer has made a clear and definite commitment that they will remain compatible with CP in the long term?

#4

I’d suggest that apart from a possible WP.org Repo search, all plugins listed would be submitted by the developer to the CP Directory.

#5

Unless there were legal ramifications, this would just be lip service. Moreover, creating hurdles for developers to get involved should probably be avoided as much as possible. There’s never going to be a directory listing with 100% compatibility across the board, which is essentially what this request would be.

Until the CP directory takes off, it will be necessary to include the WP directory results. One option might be to include both directories in the results, but either marking CP-specific plugins as such, or featuring those plugins with priority in search results.

No more than WordPress currently enjoys. My guess is that plugins only get vetted initially (same as WP) and devs go from there. I could be wrong, though.

#6

Yes, understand that. “Restricted” probably the wrong word there. But if I’m choosing plugins to install it would be nice to know which ones are maintained by people who know that CP exists and have made some sort of indication that they will actively support compatibility. It may only be lip service of course, but it’s better than nothing. I’d choose that over a similar unsupported plugin every time.

Maybe this could be indicated somehow… with a :star:, or bringing them to the top in sort order?

Edit: Sorry, just saw you said much the same thing above.

#7

This is really down to everyone’s own due diligence which should entail more than looking for a note that says the developer is going to stick around. Such a notice might even be misleading. For example, if a developer stops development and just leaves everything in place… or if a developer is hit by a bus and never returns… People get bored. Life happens. Having that notice in place, in perpetuity, might actually be a disservice in some cases.

#8

I can see your point, and it also applies to any plugin with WordPress of course.

Currently with WP, “due diligence” for me means looking at the “Last Updated” field and seeing how active the developer is in keeping things up to date. I can feel very confident that a plugin that was last updated 1 week ago will work with my up-to-date version of WP.

That would be sort of meaningless if I was using CP. In fact, it means there would now be two ways a plugin could break my site - a CP update might no longer be compatible with the plugin, or a plugin update might no longer be compatible with CP. Especially as plugin developers increasingly revise their code to incorporate Gutenberg.

I don’t know what the answer is… I’m just thinking aloud at the moment. But I do think that confidence in plugins is going to be a very important issue for the average user.

#9

In the WP Repo results, plugins tagged ClassicPress could be highlighted as such. Likewise, ones marked Gutenberg or Block could be highlighted as likely not working unless tagged as ClassicPress.

#10

ClassicPress will be using semantic versioning, so there will be no breaking changes introduced within updates to a version. So version 1.9.9 would have no breaking changes as compared to version 1.0.0.

Breaking changes will only be permitted when going from version 1 to version 2, or (assuming we get that far) from version 2 to version 3.

#11

Certainly not a bad start. I gave a presentation on Best Practices in Choosing Plugins and Themes last summer (for my WP Meetup, but still applies here) that can give you some additional approaches to due diligence with plugins; I think the plugin-centric stuff starts around slide 15, if you’re interested; the link above is direct to the presentation.

#12

Hi Tim. I just read last night on the road map about your intention to keep version 1 as a long-term support (LTS) version. That’s fantastic and it allays all of my concerns about CP! I’ll be moving all my sites over now.

#13

Thanks. I’ll definitely check that out. I’m much more comfortable about the whole plugin thing now, since I learned about the LTS on v1. I’d still like the CP-friendly plugin developers to be marked somehow though… just to give them my support if nothing else.

#14

As a CP-friendly plugin developer, I can’t disagree with that. :slight_smile:

#15

I would suggest using the standard GitHub user/repo identifier format here, i.e. ClassicPress-research/custom-fields.

To be determined: how to integrate these identifiers into the ClassicPress code.

I think this should be only two categories: if, at any point, the plugin asks for money to unlock features, it’s not Free.

For the first version of the plugin directory, we need to leave out “true” premium plugins (where you have to pay to download the plugins). It will already be enough work to get this up and running in the first place. We can keep paid plugins in mind, but they need to wait for a future version of the directory.

Of course this means that for the initial version, any billing should be left up to the plugin developers.

This is probably something that we can handle in the initial directory. It’s a lot simpler than charging and passing along fees each time someone wants to buy a plugin.

Agree - I see no reason to remove access to the WP repo any time soon, and no reason to mirror it. We will want to consider how we handle plugins that appear in both sources.

#16

For sure… just the other day, I created a plugin with the slug local-emoji and the dashboard was reporting that it had an update available…presumably since that’s a spoken-for slug in WordPress’ system. Had I actually updated, it would have wiped out my work.

#17

As explained here, I don’t agree. But, if we aren’t going to have paid plugins to start with anyway, the issue isn’t going to crop up immediately.

#18

The question is that the plugin shouldn’t ask for money to unlock features, because those features(Premium) shouldn’t exist in the Free version code.

#19

I think two categories (Free and Freemium) is a good place to start.

I think the details of how this works should be left up to the plugin developer at first.

#20

I’ll update the post at the top once a consensus is agreed on Free/Freemium and Premium.

At this stage, it’s probably best to include everything which is intended to be there, even if not all makes the cut in v2. This at least means that one eye can be kept on what will be coming to avoid design/development decisions which might cause problems with it down the line.