I’d support a filter over a category. Still, to me, if it’s not built-for, it only works-with, regardless of the level of support. As I mentioned earlier about zombie plugins… if a plugin is not being actively developed for ClassicPress (even if it fully works with CP) it shouldn’t be in the directory. If we don’t have those types of plugins in the directory, then those that are actively developing for the dual platforms won’t be diluted by having them under works with.
My 2c: some nuance is definitely needed:
- Plugins developed specifically for CP (they may work on WP too but that’s irrelevant)
- Plugins that were developed for WP but the developer has pledged support for CP (whether they use CP-specific features is totally irrelevant)
Anything else (eg. WP plugins that “currently happen to” work with CP but have no developer pledge) needs to be out of scope because otherwise you’d spend forever checking whether they still work with CP.
Using the above, Shield would be (2), which seems right to me.
Most of mine would be (1) if the Github requirement was relaxed (edit: but that’s a topic for another day).
5 Likes
Yep, I like this.
Also agree. I don’t find the “happen to work at the moment” thing of any use at all.
2 Likes
So, it sounds like you guys would be happy with “Built for CP” and “Supports CP” … and there’s no need for a “Works With” category. If that is the case, I could get behind that.
5 Likes
I’d be happy with that too. And people who say " “Hmmm, well I can’t see any reason why it shouldn’t work and will give conditional support for now ” don’t get listed until they get off the fence. 
6 Likes
While an interesting idea, I disagree with having three types. This just adds more complexity and confusion for the average user, and more work for you guys.
I realize there is crossover between what works with CP and WP. But once Gutenberg is full on, that line will be pretty clear. So, keep it simple. 
- CP Supported
Built for CP. Whether these plugins work with WP or not is irrelevant. These plugin developers have either developed exclusively for CP, or have commited to their plugins fully supporting CP. So that includes all of you CP developers; as well as plugins such as Beaver Builder and Shield Security.
- CP Compatible
This includes everything else. Sure the plugins will work on WP 4.9 and CP, but there is no official support for CP.
Easy and done…
3 Likes
Exactly…
1 Like
Not quite… if category 2 is just “works with”, who is going to take responsibility for adding such plugins to the directory and then checking on an ongoing basis that these plugins continue to work with CP ?
And as a CP user, why would I want to know about a plugin that might work fine now, but has no support commitment for the future? If I wanted that risk I would just go to the WP repo and look for plugins that worked on 4.9.
3 Likes
There shouldn’t be a CP Compatible category… which is just another way to say “Works with”.
The bins of “built for CP” and “supports CP” seems to have gained the most agreement thus far.
4 Likes
@anon71687268 I fully agree with that. Built for CP and Supports CP.
I agree this makes the most sense…
4 Likes
From the perspective of ClassicPress:
-
The primary reason for the plugin directory to exist is to handle plugin dependencies; they’re needed for Core plugins and they’re great for everyone else too.
-
The second most important reason is to do a better job of dealing with plugin security events.
So no, we couldn’t just use the WP directory.
From a User perspective, it’s a place to find plugins they can rely on to work properly with ClassicPress.
So no, we couldn’t just use the WP directory.
1 Like
That’s the same as 1 and 2 on my list, and I’d be perfectly happy to stop there.
My issue with the existing choices is that it’s currently 1 and 3, with 2 merged into 3. That doesn’t make much sense, and I’m glad others agree!
5 Likes
The structure of the directory as it stands is based on work that had already been started by the community here on the forums. None of this should be new. We already had two categories well before the directory started to take shape: Plugins Confirmed Working on ClassicPress v1 and Plugins built specifically for ClassicPress.
These lists were then assembled into separate spreadsheets for ease of import into the directory.
When the WP repo spreadsheet was being collated, a manual check was made to confirm that the plugin was a) still compatible with WP 4.9 and b) still being maintained.
So, everything on this list has been both added by the community and confirmed as working by the community.
The new directory will, using the wp.org API, check the repo for updates on a regular basis (exact schedule tbc). This will include checking the requires field. If this returns anything greater than 4.9, the plugin will be hidden from the directory and flagged for manual review.
One other aspect to consider is, as @anon95694377 is well aware, only plugins hosted on GitHub will initially be listed. Support for other platforms - such as GitLab - will be included as soon as is reasonably practicable.
Regarding those WP plugins for which the dev has confirmed support for CP (i.e. “Supports CP”), there was some talk of perhaps using a badge type system (and yes, possibly a filter) though I’m not sure if this will make it into the first release.
If we were to only show “Supports CP” plugins, it would greatly reduce the number of plugins available in the directory. This would exclude some great plugins such as Advanced Custom Fields and I don’t think that’s helpful to anyone.
Hope this clarifies things.
To sum up, I agree with James:
4 Likes
Of course, but people’s perspectives change with time and experience.
It’s taken me a while of using CP to realise that a “currently confirmed working” is as much use to me as a chocolate teapot. A “not specifically CP but developer has pledged support” is something I can base decisions on (like the time-consuming process of migrating many sites from Wordfence to Shield).
If category 2 were to stay as “currently working with CP” then this would be very helpful absolutely vital.
I honestly don’t think “currently working with CP” is worth anything to anyone (a plugin’s min version could be bumped to 5.0 a couple of weeks after someone finishes a project that relies on the plugin).
A developer pledge means at least some expectation of longevity.
Footnote: yes I know there’s the Github requirement at the moment but I’m not in this discussion on behalf of my own plugins and I don’t think it affects this particular aspect of the directory.
6 Likes
I totally agree with everything @anon95694377 has said here. Even the wonderful chocolate teapot analogy.
Yes, well… there was actually a third that seems to have been overlooked: "Must Have" Plugins List
This was a list that I was curating that tried to break plugins up into broad categories and then add in examples that could be used for that functionality… NOTE: this included both examples built specifically for CP and those where the plugin developer had made a firm commitment to support CP.
I initiated this list because, as a developer building sites for clients, it was exactly what I needed to know. I have no interest in “currently working with CP”. I need to know what I can rely on into the future.
4 Likes
Yes but how many developers have actually pledged to do this? How many are likely to? How many have been asked?
Post an enhancement request in this subforum.
You’re preaching to the converted.
The number of plugins “currently working with CP” far outnumber any other plugins. Many other people still depend on these.
Don’t shoot the messenger.
2 Likes
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.
3 Likes
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.
5 Likes
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.
5 Likes
@anon95694377 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.