@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.
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
Currently Gitlab.
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.
1 Like
No-one is suggesting that.
1 Like
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.
3 Likes
“built for CP” and “supports CP”
These 2 categories make it clear: anything else is ‘at your own risk’.
6 Likes
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.
1 Like
“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.
6 Likes
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.
6 Likes
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.
1 Like