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”.