BELIEVER.
You believe in the project and the things it stands for (stability, reliability, democracy, etc.), and that’s all that really matters.
3 Likes
What are the current thoughts on this problem?
That is a very cool idea. I think, we could focus on that together. I have already backported some functionality to make CF8 (CF7 fork) work. Example here.
Some changes should be backported directly to core though. Question is, how we should decide which changes and adds go where.
I am happy to help whereever I can.
If CP keeps backporting everything from WP just to make stuff work, CP will be nothing else but a delayed version of WP.
Why is this so bad, and what else can be done other than keep being a WP copy?:
You have been making many valid points, but you also continue to perpetuate flawed reasoning. CP doesn’t have to add new stuff. The fact that it doesn’t use blocks already makes it much lighter, faster, and more stable than WP.
So please stop portraying the issue as if a fork is the only possible option. It isn’t. What’s important is that the ecosystem of plugins that work on CP is sufficient for the uses to which CP users want to put it. That doesn’t require a fork at all.
Do I consider a more modular CP as strongly desirable, with the development of core plugins? Absolutely. But it’s not either/or.
5 Likes
WordPress plugins will be diverging from the current codebase more and more and more.
I still haven’t seen any other solution for this issue, other than forking plugins for ClassicPress.
I agree I am “pushing” my view in other aspects, but also started the experimental version just to play and I am not interfering on that side anymore.
But about plugins, again and again, it is the only solution. Other solutions are: tweak the core to keep adding fuss from WordPress and even that won’t fix the whole thing with plugins… and what else?
I am waiting for more alternatives since a few months, no valid alternatives have been proposed, other than the utopic “something has to be done to make plugins work”.
Forking plugins is different from forking CP.
2 Likes
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?
1 Like
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:
- Have a CP specific set of plugins (which implies that some WordPress plugins will inevitably have to be forked)
But you missed the fundamental point that I made, which is:
- IF we are going to go this route (the route of a CP independent plugin directory), we can as well come up with a list of minimal breaking changes so that we don’t have to fill up the NEW directory with blocking code that will force CP to stick in the old times.
And for that point, I’m really intending to say very very very simple things, nothing crazy. Things like:
- Remove the deprecated argument from the load_plugin_textdomain() function. When you clean your fridge do you take out the accumulated ice and dirt or do you just take food out and put it back in?
- Maybe NOT assume that jQuery will be loaded, force the plugin to make that available if it needs it. If we just assume that jQuery will be loaded, instead of making the dev take care of that (two lines of code), then we will never be able to remove jQuery from CP frontend because: “oohh we can’t because some plugins rely on it”. And that’s very sad.
- And some other MINOR things that will help CP to be a bit better. And again: will not make any substantial extra effort for the developer, as far as making the developer hate creating for CP.
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.
1 Like
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
1 Like
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.
1 Like
@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.
1 Like
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.
1 Like
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.
2 Likes
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.
1 Like