Yeah, that’s fine. Add 2, remove 3… that seems to be what got the most (er, only) agreement. And it doesn’t needlessly segment the directory further.
No shooting going on here - I guess I was just explaining why I’m sticking to my position that category 2 should be “CP supported by developer” rather than just “currently working with CP”.
I sympathise with James’ point that it’s early days and he wants to see how things settle out, but I also think that if some folks have a view that things should be a little different, it’s good to get it out there as early as possible.
And now I’ve both given and done my best to justify my 2c, so I’ll stop. What will be will be.
Not a lot. But you certainly won’t get many more if you contact them and say “Please support CP. If you do, you’ll still be lumped in with all the others, but one day you might get a badge”.
I’m not trying to shoot down anything that has been done already, and I really didn’t give it a lot of thought till @invisnet posted. Then it sorta became obvious to me. But that’s only my view so, like ZP, I’ll leave it there and let you get on with what you think is best for the widest user base.
@zigpress with the implementation of the new features I have ensured to allow flexibility for any providers in the future, so I am working on it! Who do you use so we can bump that implementation to the front of the line?
I think we need more input from the community who aren’t plugin developers but rather end users as we have just over 300 users on the forums but only ~5 plugin developers have given their input so far. If there is more consensus from the wider community then I am happy to make the change.
This also will take a little bit of work to update so it may not happen right now, so if we can split off this topic with a new feature request that I can track that would be helpful.
I also wanted to add, the original implementation had a badge on plugins and developers who had pledge support for CP, however we couldn’t narrow down the requirements to receive that badge nor the wording of said badge.
I agree with @wadestriebel this is still only 5 people giving input.
As it is, the plugin type or category is okay as is, from a user perspective, I want to know the plugin that is specifically developed for CP, and NO, I don’t want a plugin listed in the “Developed for CP” category just because the author or the dev says he is committed to supporting CP., they might decide not to support CP down the line if they don’t have the capacity anymore.
In fact, this happened to me recently, I was using a plugin where the dev claimed it supports v4.9 upward (CP works fine with the version 2 of the plugin), and he released version 3 which also claims to support v4.9. Out of curiosity, I asked the dev if he would be willing to support CP officially, he said that shouldn’t be a problem but he is gonna get back to me.
He got back to me saying v3 is not compatible with ClassicPress or WP v4.9 anymore because it depends on features that were introduced in version 5.0.0 which is quite extensive and would require a rewrite specifically for CP. Still stuck on version 2 of the plugin until I think of what to do.
How many of this would you test yourself when the plugin directory grows?
So, If it is developed for WP but working with CP, it should be immediately dumped in the “Works With CP”, this is still from a user perspective, I want to know what is what.
If you feel the need to improve the ecosystem or if you feel the need to welcome WP devs that are making a commitment to CP, you might create a new category specifically for them, but you don’t have to. Just don’t merge anything together, please don’t!!!
Please let’s not further complicate things
Edit: but I host release zips myself. I just use Gitlab as a way of keeping a backup and my repos are currently all private.
No-one is suggesting that.
Replying as a plugin user.
Having the plugins indexed by function would be first search then choose from (in order of preference) developed for CP, is a WP plugin but works with CP and developer is aware of CP, is a WP plugin but currently works in CP no positive developer contact. This might give an idea of hoped for longevity.
Premium, paid plugins, is no guarantee of long term support, I have “bought” plugins with lifetime/5 years/1 year etc and developer has change mind/circumstances/WP made too big a change, etc. and support/updates stopped.
I do realise the time taken to both develop and to maintain a plugin, so plugins are not always perfect or going to get “updated” each week. I am still using some plugins that have not changed in over 2 years, they work, if no security issues why change.
One plugin i use says it needs version 5+ but changing the version/compatible with number and update date seems to be the only change, so I carry on using it.
Hope I have not rambled too much.
“built for CP” and “supports CP”
These 2 categories make it clear: anything else is ‘at your own risk’.
Oh, sorry to y’all, I was misreading . Still want the best for this community, so, whatever stuff we do choose, let’s have a second taught about it.
“Built for CP” and “Supports CP” are what matter.
“Happens to work with CP” is a hostage to fortune that the CP directory should not be taking on.
I’d agree with this.
Plugins developed for ClassicPress or which explicitly support it would need to be submitted by the developer to the directory. Other plugins which happen to work with it would be in the WordPress Repository.
As an user, developed for is first choice. Publicly supporting second. Third with no guarantee is wp repo…
The plugin directory is a great challenge.
Users & devs can feel positive or negative about the “challenge” depending on how we structure it.
It makes sense only plugins for cp or directly supporting it are included, and all the rest instead is excluded.
Hey devs, wanna be included in the directory and make money in a new, exciting market developing under your eyes? Just develop with CP in mind
Users, want to be sure your site is stable? Rely on plugins that were made with love for CP or publicly support CP
There is no use having wp plugins around in the long round. WP will differ more and more with time, and we need to develop with a long term goal in mind. Hybrid solutions are not suitable for a moment 5 years ahead.
I think these categories are pretty silly, and come from a perspective of having only one version of CP. You need to plan for when there is CP v2 also, and an even larger gap between plugins available for the multiple versions of WP and the then multiple versions of CP.
These sound like manual assignment into the category. That’s going to be difficult to maintain. And anything that is in the readme isn’t very trustworthy either, as plugins can be abandoned or changed.
Why are there categories?
As a user, I mostly want to solve my problem. I don’t really care if it was built for CP or not. I need to match up the version I’m running with the version it can work with. Just the fact that it’s in the CP directory is enough to say it should work with CP.
Exactly, this is the idea - and of course it will be part of our guidelines that a plugin that is published in the CP directory must work with CP.
The other main type of plugin is the ones in the WP repository that are confirmed by some group of users and/or developers to work with CP, for some versions. I don’t really see a way around including this functionality - CP v1 and v2 both will still need to be able to install plugins from the WP directory as our users do today, and the best we can do is make this easier and safer.
If a plugin wants to move from “published in WP repository, works with CP” to “supports CP as a first-class option”, which many people will be looking for - and rightly so - then the step developers need to take is very simple: publish their plugin in the CP directory as a ClassicPress-specific plugin hosted on some
git repository provider.
This naturally gives rise to just two main types of plugins, and not coincidentally, they are the same fundamental types of plugins that are planned to be supported by directory.classicpress.net at a technical level:
- Plugins in the CP directory.
- Plugins in the WP repository that work with ClassicPress.
This is essentially the same as @Web242’s scheme of “CP Supported” and “CP Compatible”, with a built-in and very natural way for developers to move from group (2) to group (1) as they are ready. There are also various ways to incrementally refine and enhance this scheme over time, in no particular order and with no guarantee or even a suggestion that we should actually implement all of these:
Split the CP plugins (group 1) by whether the plugin was developed specifically for ClassicPress, or whether it started as WP first. This does not seem to be key functionality that’s needed by a significant portion of users, but in any case it’ll be very easy to add later - just a tag and a filter.
Add a system for ClassicPress users to verify that WP plugins (group 2) work with ClassicPress, and update these verifications for each new version of each plugin. This could be made easier and safer using a combination of automation and crowdsourcing, depending on how much time we want to spend on solving the problem of knowing which WP plugins can be safely installed, and whether they can safely be updated to a new version.
Split the WP plugins (group 2) by whether the author has confirmed official support for ClassicPress in some way. May not be particularly necessary or valuable - we should be pushing these developers to publish their plugins on ClassicPress instead.
Regardless of what enhancements are built on top of the basic structure of the directory in the future, we have to start with (1) CP plugins published in our directory and (2) WP plugins that happen to work with CP, because from a technical perspective these are two very different kinds of data. This is also the most natural way to formalize the two main lists of plugins that have evolved over time on our forums. It really doesn’t make sense to get hung up on the details and sub-categories of those two major groups, we have to build the base first and then see what else we really need on top of that.
Picking out one specific example from all of this:
The simplest solution to this requirement (which is perfectly reasonable and will be shared by many) is that you filter for plugins that are published in the CP directory. I am assuming that developers who have previously offered official support for ClassicPress will be willing to also publish their plugins with us - if that turns out not to be true, then some of the enhancements I listed above (or other similar ideas) will help to address that issue.
James, can you just clarify something for me? (and possibly others)
When you you say developers will publish their plugins with us, do you mean it will go into Group 1 along with CP specific plugins? If so, can they publish it as a pre-existing WP plugin that is modified to also work for CP, and fully supported for CP users? Or will it need to be a separately developed CP-specific version? (eg “Shield for CP”).
Yes. If we find that (for example) developers are willing to support CP but not willing to publish on our directory then we will adjust accordingly. But again, we have to lay the foundation for those later potential refinements first.
Yes - and in most cases changes needed in order to do this properly should be either none at all, or minimal, with security plugins being an exception because they usually look a bit more deeply into the internals of the CMS.
OK, thanks. Well, I’d be fully in favour of this approach as well.
But I also know there are others who think that Group 1 should only be for plugins that are solely written for CP (ie no hint of any Gutenberg-bloat).
I think that’s a very important and useful piece of information, but it also raises another issue which is:
- What exactly do developers need to do to “offer official support for ClassicPress”
Or, to put it another way, what criteria needs to be met before we will accept a plugin as being “fully supported on ClassicPress by the developer”.
For instance, does this need to be stated in the plugin’s readme or do we need a comment / post from the developer on these forums? Both?
It’s a question I’ve been asked quite recently.
I think we need to be consistent with this.
Good question. I quoted your post in a new thread to garner discussion around support criteria. I didn’t move the post as it was still relevant to this discussion.