Sure it is. And if you click the link you will realize it is what I intended to say from the beginning. What kind of person would I be if I came to a community preaching to fork it?. This community is beautiful, apart from many of my ideas being different. I want it to succeed. Maybe it has been a misunderstanding 
Still waiting for reasonable and valid alternatives to this proposal.
The work on the plugin directory has resumed. This means that many plugin developed for CP are going to be published in the coming weeks. And devs will make available what plugins the community needs by listening to people’s requests.
As soon as the plugin dir is done, I think we all should have a talk about themes dir.
And then we need to start inviting all the theme devs who published their themes on the forums to publish them in the theme dir also.
Is this a reasonable answer to your concerns?
Not really. I’m starting to think that many people here don’t even read what’s being said before answering.
It doesn’t mean that. It means that a member of the plugin review team reviewed two plugins that were hanging since some time and that they commited to review more. But stating that “many” are going to be published is misleading.
And for the rest, you more or less repeated the same thing that I am trying to say, which is:
But you missed the fundamental point that I made, which is:
And for that point, I’m really intending to say very very very simple things, nothing crazy. Things like:
The whole thing that I described here and that not many really seem to care about. And which is a very logical approach. I’m not saying anything crazy, just: “gonna have a new plugin directory? okay let’s first set some MINIMAL requirements and ideas so that the new plugin directory doesn’t block the future potential of CP”.
I suggest being careful when saying people ain’t reading but talking, when you are assuming to know how many plugins got reviewed but de-facto have no idea about it.
(FYI, it was a tenfold of what you stated and additionally just as many developers as well have been reviewed. Yesterday alone 20+ emails and messages have been sent out.)
The reason you do not know about this, is that the team was not here bragging and discussing what might be the best finger-nail-polish for this job, but just did it.
I believe that is what others here should be doing a bit more as well, instead of writing books about growing peaches on Apple trees and wasting time of those who try to do things instead of talking around them.
Really, no offence but please stop talking and start doing what you think will save CP so easily.
Nope, it does not imply this. Not necessarily.
What I mean is that by speeding up the process with the directory we can then INTEGRATE it in the core with the API or with the JSON file as I have seen a proposal for.
And that this will lead to more people knowing that the dir is there and developing FOR CP.
And this leads to an ecosystem growth.
It could be a slow growth and on this I can agree, but fact that WP plugin can be forked is going to only speed it up.
Without a place for plugins, and a way to make it accessible to users, you go nowhere.
About the second point, yes absolutely. we can slowly introdice breaking changes by announcing them beforehand and giving time to devs to comply. This just for the fact that having our own ecosystem ALLOWS US TO DO SO (and that is why people are asking the directory so much).
On the fact “less talk more action” I agree with @anon66243189
Yes it does. Sooner or later, it’s a need. Why? Because some plugins are a must for some people. They have to be forked so that those people can keep using them. Examples: Contact Form and Query Monitor. And many others.
Yeap, I made that proposal and not only that, but it’s actually already working (there you have your action).
Slowly? Very wrong. If you do it slowly, there will already be 100+ plugins in the directory and then the excuse will be: “no we cannot do that because there are already many plugins and blahblahblah”. It has to be done BEFORE (also known as having a plan).
This whole thing leads to apple trees growing peaches and talking without doing. You cannot “just do things”. You have to have a plan before doing something. That is the fundamental base for any project.
If you don’t have a plan then you end up doing whatever and then boom, you have “WordPress: a total mess”.
I am talking and talking and also doing (see what I have done here). And I will keep talking as long as I see a minimum of potential in this project, to push planing and reasonable ideas as much as I can.
No plan → You end up with a total mess.
No talk → No plan.
If you read through this whole topic for example, nobody has given serious feedback on the proposal. It’s all just critics without alternatives and blind nos.
There is a plan. it’s called roadmap and it says we will place the dir in the core in v2
so to make v2 possible the dir should WORK
then, yes, people are also going to fork plugins, but devs will write also CP PLUGINS so if elementor does not exist in CP we can have some builder specifically coded for CP for example.
since having the plugins developed for CP might take some time, forking will be very common at the beginning when we will place the dir in v2
the people will start to see CP plugins more and more and use them as time goes by.
the forks ipso facto are going to become plugins developed for CP because they will be improved following CP growth and CP users’ needs.
but it’s NOT COMPULSORY to fork, if we can supply alternatives developed for CP. Forking is one of the resources we have available, not the only one.
And just a question:
if you switch to joomla from WP, do you expect WP plugins working with that?
CP is not WP, so we have to stop relying solely on WP resources and build our own IMHO.
sure, for now WP stuff can work in CP, but eventually it won’t any more. so we will develop for CP and in case FORK to make CP plugins out of WP ones.
it will come a time when forking a WP plugin and make it work in CP won’t be possible anymore, because WP diverged too much. That is why I say that forking is only a temporary resource to help speed up plugin/theme development for CP in the early v2 times.
@moderators I would consider closing this thread to new replies and react sooner the next time such damaging thread pops up.
There is nothing productive coming out of this sort of stuff, and it consumes the time of those who are productive, and other than unfunded assumptions, “would be’s” and actual damage to the project when people who are fresh read this thread (and will think this is a circus), literally nothing is gained other than anger.
Topic muted - I will not receive new notices here nor react to any, if any make it through.
A thread can be ignored if you don’t care but closing it is censoring. And as far as I know CP runs away from censorship. Still waiting to know what is wrong with discussing this as a plan of action and still waiting for better alternatives. You keep saying… “at some point we will see”. But that approach will end up in: “oh now it’s too late”. I am willing to act, but if there is no plan of action it’s all kind of random. A puzzle where pieces don’t match. Anyway, will do it in “the experimental” version.
while you are talking, I tested a plugin to integrate CP dir in core coded by @smileBeda
it works beautifully and is fast, it follows the core plugin philosophy and can be shipped as a plugin that one can deactivate and remove if they do not want it (for example on client sites that you install plugins and then remove the plugin menu entirely). and follows the roadmap that is already there.
It’s just an idea, but you see… we are slowly moving towards v2
now to your idea of a JSON file, it doesn’t follow the less bloat in core/core plugin philosophy that CP decided to follow before you even knew it existed. It is something that only someone with JSON knowledge can alter to their needs.
It’s another possible implementation, but having one option that follows what was decided for the roadmap in the past maybe is more in line with community preference IMHO.
it’s ultimately the community who will decide which option is better. Personally having tested the plugin I think it suits my needs as an user.
Where is that plugin to integrate the Plugin API into core? Sounds awesome!
@smileBeda is refining it with my feedback. I think you can ask him to test it too and see if you can give him some other feedback on it. I gave feedback from a user perspective testing it on a fresh demo install I spinned up for the occasion and I think it’s great. he told me that the api was easy to integrate.
but i am not a dev, I can understand a little of PHP but I am not at dev level to give advice on the code. So I think the more eyes on it the better.
Sounds great. Would be cool to help with that, if he is willing to make it public or give access.
He asked me for feedback, I think if you just send a private message he will welcome your feedback on the plugin. he said it will be published on the directory if it works well but that it will need to be reviewed by someone else because he can’t obviously review his own plugins. so some dev has to put the plugin through the process of approval to be published when ready I guess.
Conclusion (plan to prevent CP from becoming obsolete):
Priority 1. Integrate Plugin Directory into core.
Priority 2. Populate Plugin Directory with new plugins (be it forks from WP or both or whatever).
For 2, I just proposed to set some basic requirements for plugins that can be applied now that there will be less plugins. Because when there are many plugins, it will be more difficult ( non actionable / impossible ) to force some requirements because it will be too late. Feedback for this is: no. So let’s keep in the deprecated stuff and our friendly jQuery forever (even though there is / was a chance to fix this now).
I’m not sure what you are referring to, but this is already the case for the front end. There is a lot of admin core code that uses jQuery, so it is loaded where needed in the admin. But plugins and themes already have to load the scripts they need.
Really? Maybe I am doing something wrong but, for a fresh install of ClassicPress, with zero plugins on it, I see the following on the frontend:
It’s not only loading jQuery, but it’s an old version with a migrate in it (2 useless scripts, for those who don’t want to use it. Bloat, bad for pagespeed). And what I meant with setting basic requisites, could fix this… avoid having to force jQuery just for those plugins that maybe want to use it and didn’t register it. I don’t think it’s crazy, but… there it stays in the air
And just to clarify, I know that the admin area needs it and it’s another story (would be crazy to remove it from there now). I am specifically talking about the frontend.
And to clarify even more, I know that jQuery can be disabled on demand. But what I am saying is… don’t depend on it for the front end. Make it a requisite for new plugins (and I can help updating the current plugins with this change) to load the stuff they need. Be it jQuery, Alpine, Vue or… whatever.
The theme is in charge of the front end, not core.
There was some work done to backport the jQuery update changeset, but it was not completed yet.
This is a wrong conclusion, and is not happening.
It’s great to see I’m wrong here. I have been blind to the fact that the default theme is there, doing that jQuery load. Sorry and thanks!
It looks like everyone voiced their opinions on this topic, and it’s beginning to slowly move off topic. So I’m closing this topic.
