The only impact of this is that all plugins that use load_plugin_textdomain() will have to be updated from:
load_plugin_textdomain(a, false, b) to load_plugin_textdomain(a, b).
false is always being passed just as a placeholder for the deprecated parameter.
If we keep allowing new plugins into the new directory with this, at a certain point it won’t be an easy task to fix them all. And this deprecated parameter will stay there forever. Now, it can be done, and I am very open to submit a Pull Request to every single plugin in the directory, to make this update. Authors will only have to merge a one line change in code.
I will also submit a PR to the core with the necessary changes, which by the way I already did for the experimental version and works fine.
To the people who preach “just do it and don’t say it”. I won’t. I want to ask first and get approval or at least a few votes for this. It’s a very minimal change but I won’t waste time if it will stay ignored.
This is NOT a duplicate of my other proposal, where I was asking to set some requirements for plugins. This is just one very specific change, that’s why I created a petition for it.
Before saying no, please understand, I will be doing all the necessary work for this. I just want it to happen. If it doesn’t happen now it never will.
Would it not be interesting to know if it breaks something or not and do it if it doesn’t?
I can say right now it doesn’t break anything. It’s just removing one unused param from a function call.
If we wait for v2 (which maybe will happen in a year or four) then as said there will be more plugins in the directory and maybe then it will be too late. Now it can be done and I am willing to. Don’t understand why a word should get into the way if it doesn’t break anything.
We have to follow semver, it’s not about what will break. Removing an existing feature is a breaking change, hence must be a major version.
But I think the right question to ask, can we bump CP to 2.0 with this breaking change?
We’ve been waiting on CP 2.0 as of it’s going to fix everything. But we need to let go of that notion and continue to do the work that’s necessary, and if that means new major versions so be it.
Maybe this could be tied in with @anon66243189 directory integration. So we could have an actual 2.0 version with a new major feature.
Your petition answers your question. It doesn’t have to be a big feature, like Customizer. It exists, you said it yourself this requires a change in plugins that use it. That’s a breaking change.
I’m all for implementing it. Just need to bump CP to 2.0.
That’s just my opinion. Others may have a different opinion.
We use semver for a reason, predictability and reliability. It’s not the right time to abandon it.
Not really. The first breaking change is a move to v2. More breaking changes can still live within v2 because that’s the difference bewteen v1 and v2 (breaking changes).
And again, this is not a breaking change “just because i like it”. It is a breaking change because this specific thing lives in plugins and we decided to have a new directory. Now… it’s easy to edit all the plugins. Next year, maybe it won’t. Other breaking changes (stuff in core) can wait, because they don’t depend on having to update ALL plugins. But this is a very obvious and ultra simple improvement.
By breaking changes, I mean braking from WordPress and ClassicPress v1. Not breaking v2 with v2. If we go forwards with this v2 now, we can make a list of breaking changes and do the upgrade with all of them. It doesn’t have to be many. Just a couple of simple things.
Also… I think it’s the perfect time. Because if we plan to have CP v1 LTS and CP v2+ with the new directory, we will have to maintain TWO plugin directories… that’s, double each plugin.
New plugin directory should be for v2+. It’s what makes more sense. Or we will be locking compatibility to v1 by creating all plugins for v1…
But this should be discussed in another topic. This is about removing the deprecated paramenter.
It depends on what that couple of things are. If it’s a few nice things it’s fine. At least I will get some motivation on this whole project. Elseways I really feel this is stuck… come on, a new plugin directory using deprecated parameters. It’s crazy from any perspective. Then one day someone will decide to update and there will be 300 plugins and the excuse will be that it’s too late. It will happen.
Maybe more people think like me maybe not. But still, my claim about filling the Plugin Directory with “outdated” plugins which will lock up compatibility, I think that’s quite fair.
I would be happy just with removing the deprecated param, it’s the most blocking and easy to fix case. One line change per plugin.
What if you make a new function instead? The existing function integrates with language packs coming from WP repo. For performance, CP plugins wouldn’t want to be doing that. The CP directory wouldn’t have any translation teams per plugin, so there’s an entire system that is non-existent for CP. Each plugin would have its own bundled language files, like pre WP 4.7. It’s a bit less than the “equal to WP 4.9” label, but that’s the direction that was chosen.
That function could be added to core and only consider bundled language packs and it won’t break anything.
Only thing, I would encourage (not force but at least talk about it) plugin devs to use this new function so that it won’t be a pain to remove the old function.
I am even open to PR all plugins with the new function (once the new function gets added to core and a few versions are rolled out, so nothing breaks for users using those plugins).
Well, you can deprecate the old function, but meanwhile make it call the new one which is just the chopped down version of the old one.
You don’t have to break things all at once, but ease them in.
