I suspect it’s less about the needs of the directory and more about how:
(a) the updating mechanism works. Currently, as mentioned above, that’s dictated by the plugin that CodePotent created, and
(b) Beda’s plugin works that displays the directory in the CP admin.
I’ve nearly finished the repo itself. Before I make a public test version, I want to have a look at those plugins to see if I need to modify something. But I also know that their approaches aren’t consistent (because Beda has made that clear).
I think it would be good for the code in core for the admin plugin page to have both versions. We have already had to fix the messaging because it was saying “ClassicPress 5.2”. We should show the correct name with the correct version if we intend to show both repos in the admin.
I have now had a look at the code. Beda’s plugin just looks at an API, which is what I’d expect. (Hopefully, it can be easily modified to work with CP’s REST API. I have made all the necessary metadata available to the relevant endpoints, and also secured them from anything other than GET requests.) It has no interest in readme files.
The Updater plugin just came up with its own requirements. So I think we (i.e. CP) can specify what the readme should say, and then modify the Updater plugin as necessary.
The hope is that the CP API is very close to the WP API, so that core doesn’t have to change much to talk to both. In doing that, the CP interface can easily add the CP version which would be the difference.
The CP version doesn’t matter so much right now, since it auto-updates. It’s when we get to a major version change (semvar) that it will matter more.
The readme is only for the directory, not core. And the directory should make the Updater plugin obsolete.
Not sure I follow your first point. We don’t even need to modify core for the API. We can choose to, of course, but it’s not necessary. A plugin can do the job just as well. That was, after all, the point of core plugins.
The real issue is how easily this can be made to work well, not how similar it might be to what WP does.
I was referring to changing core CP to include both the WP repo and the CP repo, with as little change in the internals as possible. It should be a cosmetic change to default to the CP repo and have the WP repo as a menu item. I don’t see what this has to do with core plugins.
I seem to recall the decision about the readme having been made already, but if you want to change it, it is still a fact that CP still has the WP repo in it, which uses the readme as the source of the API data.
And the CP directory should make it so the Updater plugin is not needed, or why have an API at all?
I think the point is why do we want to do the same as WP? We are going to remove WP once the transition is complete. We don’t need to integrate our own things so that they mimic WP. We can do our own thing and then just remove WP when our ecosystem is stronger. As of now the only plugins you can install are things that haven’t been updated in ages, that have possible security flaws and aren’t au par with the big names in terms of features. Some theme is installable but at a certain point there won’t be installable themes. We are different. We aren’t WP anymore. We can’t continue to imply that using WP plugins will always be ok. At a certain point we have to say: you have to use CP stuff because we can’t guarantee WP works, so we remove WP. From now on only CP stuff can be installed directly. To install WP stuff you need to upload it at your own risk.
In case you haven’t noticed, there are very few actual programmers here. WP has lots of smart people and a wide base of sites that test all the variations of the software. It would be quite foolish to toss all that “just to be different”, when we can easily benefit from it.
You are exaggerating, a lot. This does not help anything.
Let’s say I am testing various plugins deemed compatible with cp, on fresh installs many of those render fatal errors for missing functions. and this is going to happen more and more. might not be an immediate thing. we might have one year, or more. but it is unsafe to continue encouraging people to install things at their own risk from wp repo, while also supporting the idea of non breaking changes that gives the false impression we will be compatible with every wp version and plugin and theme forever.
Basically on one hand we encourage people to use things that in some time might fail (and that “might” isn’t a possibility, they will fail at a certain point, and this will be a great dammage to the users) on the other hand we are not clearly stating that we are diverging and at a certain point we will rely on our ecosystem, and people hear “wp stuff will always work on cp because they will ensure it does” but we can’t promise that.
That is why I think we should stop encouraging people to use wp plugin and themes (while backporting what we need from wp @joyously because for now we can take advantage of their work and transfer it to cp).
at the same time I think that for a transition period we should offer cp and wp stuff at the same level, then slowly demote wp stuff to discourage people using it and giving a clear deadline to remove it entirely. then remove the wp repos from theme and plugin page.
This process is not something we have to do in days, might take two, three years. in that time we need to encourage plugin/theme devs to develop specific solutions for CP in order to strenghten the ecosystem.
it might happen that we are forced to remove wp stuff sooner than we think if they continue diverging from the old wp but this is something we will need to address when the issue arises.
It’s hard to do when we don’t have dedicated CP plugins and themes to direct people to. We don’t have 2FA plugin, we barely have a working SEO plugin, we don’t have page builder plugins, we don’t have caching plugins, etc. This is even worse for themes. We only have a few themes.
Users just need to be educated that there is a possibility plugins will not work or break in the future.
If you never encourage devs to develop for CP by just allowing people to use WP stuff devs will never come. Having a roadmap clearly defined (in five years we gonna remove WP stuff) people will start to push devs because where there’s a need there’s a market. Clearly to do that statement (in five years we remove WP) the CP dir and integration should work very well. It’s the first step. We have time to transition. But we need to make very clear to people that we will transition.
And we can encourage users to reach out to devs and ask for specific plugins and themes. When devs see profit they’ll jump in. It’s not something to be done in a rush. It’s a cultural shift to bring more people onboard. But as long as we aren’t clear and give the impression WP stuff is going to work forevvah people will not completely jump in and develop for CP.
Growing user base is the only thing that will encourage devs to develop for CP. That’s the only issue that comes up when I talk to plugin developers.
For users to use CP we need plugins so they can customize and extend their websites, including themes.
Without plugins/themes we can’t grow user base. Without user base we can’t attract plugin/theme developers. It’s a catch-22.
But, out only option to grow user base is to rely on WP plugins. It’s nice to say what we want to do, but we have to be realistic and smart, utilize resources we have to grow our user base. That’s key to everything, including leaving WP behind.
It’s not ideal, but that’s what we’re working with.
Without WP plugins/themes, this will be ClassicPress trying to ride it’s own path:
I am under the impression you are not reading @viktor.
What is the issue if we say:
Users we need your help! We have a working dir that you can access from dashboard. In five years we would like to have this dir full with CP plugins and themes to be able to start the process of removing WP stuff. We need you to push devs to develop for CP during these five years. The WP stuff is there to ensure you can run your sites and you have five years to bring at the attention of your preferred devs that you need their plugins working for CP and listed in the dir.
I say five years because to me it seems a reasonable time to make dir available, solve dependency issue and start on core plugins. During that time having the dir should be advertised. And users are a GREAT lever to do this. We also could say 10 years. Or 3. But we should give the input that we are serious about this transition.
Otherwise what is going to happen is WP plugins will have compatibility add-ons (because without a clear plan this will surely be one of the things to happen) and this to me defeats the whole purpose of having forked WP 4.9 just to create a dir to put in compatibility plugins for WP.
If we plan things and say there is a span of five years where we want users to ask devs to develop for CP I think users would be happy to help.
And devs seeing users asking for CP specific plugins and themes will have a good reason to jump in.
Then when five years strike you need a plan to remove WP. You can keep it in a less prominent section for two years, then remove it but allowing direct upload (that is already there for themes and plugins so you don’t need to invent the wheel). That way you never really abbandon WP things but you discourage it’s use and encourage people to ask for CP specific things to devs.
And people if prompted to push for CP specific things are going to get the message that WP stuff might not be secure for a CP site.
