Very clever!
We could create a new function called load_local_textdomain which will replace:
- load_plugin_textdomain()
- load_theme_textdomain()
In the future.
Both functions would work the same way, passing:
$domain$path
So it doesnāt matter if we are in plugin or theme, by providing the $path it will know where to find what has to be loaded, and we condense two functions into one.
Do you see any issue with this approach?
Creating one function for both themes and plugins is not ideal, because we want to keep the locale filter. And it depends on the call being for a plugin or a theme. Also, it would force to provide an absolute path instead of a relative one, and relative is cleaner. So, it makes sense to keep two functions.
But before creating two new functions (load_local_plugin_textdomain and load_local_theme_textdomain) I had this idea. As a pre-answer tho those who prefer actions to words, I wanted to create a PR for this (Iāve got it working locally) but then again, why waste time if I can first ask here if itās going to be accepted?
So, the idea is to keep load_plugin_textdomain and make it possible to call it with either 2 or 3 parameters.
How?
By doing it like this:
Code:
function load_plugin_textdomain( $domain, $second = false, $third = false ) {
// Decide if we are using the outdated 3 params call or just 2 params
if($third){
// Third parameter was defined, this is an outdated call
$plugin_rel_path = $third;
}else{
// Third parameter was not defined, this is a modern call
$plugin_rel_path = $second;
}
...
}
This will sacrifice one thing.
What will it sacrifice?
Devs just calling load_plugin_textdomain() with 1 parameter and assuming it will load the language files from the plugin root directory.
I have looked around plugins and did not find any single plugin doing this. They all use the three parameters call because thatās how itās written in the online examples for internationalization.
Also, just throwing your languages files into the plugins root directory is not the cleanest thing, so why support it?. A subfolder is the way to go, for plugins that bundle translations (which will be all, for CP). I would even force it to be called ālanguagesā but yeah, thatās another discussion.
We can implement this without breaking changes. The worst thing that will happen is that translations wonāt load for plugins that do the call with one single parameter. Butā¦ can you show me a common plugin that does this?
If we implement this, I will update all plugins in the directory, to use 2 params. And then in the next version we can add a deprecation notice for plugins using the 3 params call, and eventually, just update the function to load_plugin_textdomain( $domain, $plugin_rel_path = false ).
If the community is okay with this I will submit a PR.
If no, Iām open to hear solid reasons and examples of plugins using only one param for the call.
Also note that load_theme_textdomain() is doing it right, even if they are calling the path parameter differently (I would update the name so they are both the same).
Sorry got it wrong.
However Iām not sure you can update all plugins in the directory. You can push a code to their repos, sometimes. Others arenāt even on gitā¦
And all plugins coming from wp wouldnāt want to have their wp code throwing notices in cp, or add code thatāll basically duplicate their already working code.
So Iām not sure this is the best way to go currently, specially since all plugins already use this āfalseā second parameter?
1 Like
Even changing names of parameters in the function declaration breaks semver.
It can be tricky but itās easy to understand if we consider named args in php 8.
1 Like
No need to change names. Just did it for clarity. Named args wonāt be backward compatible either. Still 2 args and no one will want to force PHP 8 before 2035.
I would submit PRs to all of them. Itās a quick change. Authors who care about their plugins may accept and abandoned plugins can be forked. Same for WP plugins. Forked doesnāt mean maintained, but at least this can get done. And abandoned ones arenāt maintained either.
Each plugin made for WordPress working with cp would fail.
They canāt do this to a code thatās going to be in the wp repo as well, because wp core is going to expect the third arg. And if itās missing all wp core plugins would load translations fine in cp, not anymore in wp.
All my plugins for starters wouldnāt accept this pr.
Beaver builder as well not.
A forked plugin without maintenance wonāt make it to our directory.
It is a breaking change to change the api.
2 Likes
One more try. What about doing this change and then allow new plugins that are specific to CP, use 2 params?
What change?
This change:
function load_plugin_textdomain( $domain, $deprecated = false, $plugin_rel_path = false ) {
// Detect if we are using the outdated 3 params call or just 2 params
if(!$plugin_rel_path){
// Third parameter was not defined, this is a 2 params call
$plugin_rel_path = $deprecated;
}
...
}
Note that there is not need to worry about this anymore.
This way, people who are starting to develop new plugins for CP, can use a 2 params call (i.e. they are not forced to insert an extra parameter just for the sake of supporting old code).
No need to update ALL plugins. But at least we can encourage (not force) this for new plugins and maybe update some of the currently existing plugins.
Only potential issue with this:
If this is a concern, please also provide examples of plugins that are doing this.
The thing is that IF someone uses it (the deprecated), as the code shows, it allows to load a path from ABSPATH, while the newer third argument will WP_PLUGIN_DIR it.
These are two completely different locations.
One allows you to place your mo ANYWHERE in your WP root, the other, only in the Plugin DIR.
The change you propose would effectively knock that out and make it so that the rel_path (if not used) becomes the ABSPATH which MIGHT be used.
IMO this is a change that does break API, and, we can NOT know about 50K plugins (lets assume 30% of those still work with CP, and perhaps even only 1% uses it wrong, that is still 150 plugins which might be affected by this change.
I am more liking your last proposal, however, I cannot comfortably say āyes, this is no issue, it will not affect any pluginā because we canāt know.
I am also not sure this will attract massive amounts of developers just because they do not need to pass one word in a code.
So, balancing it out, for me the risk, work and so on doing the change seem like (are already) bigger than the benefits.
We will neither gain anyone jumping boat because of this change, neither speed up the code.
Thus IMO in a version CP 1.x.x this should stay as is, as it does not ADD, but REMOVE/CHANGE the existing API.
4 Likes
This is not necessary for plugins that bundle their translations in the plugin zip. The user would have to move the translations out of the plugin folder manually. Any user doing this, very probably also knows how to fix the situation, or just not move the translations out of the plugin folder. Thereās no point in doing so.
Also, removing that āfeatureā (load from ABSPATH) is a slight performance improvement. Very hyper slight, but an improvement. It also would make the load_plugin_textdomain match the load_theme_textdomain params, which is more professional.
Also, if this does not get done now, it never will. The complications for doing so will only increase over time.
Itās not a change that will attract a million devs. Itās just about the details, about transmitting the idea: āhey, we want to IMPROVE the code base, we are not 100% happy with it and we want to make it betterā. Making deprecated params hang there, just for the sake of a 1% (is it really a 1% or is it way less?) chance of stuff not working as expectedā¦ is a bit too conservative.
If the same reasoning is applied for everything it will be very very very difficult to improve anything other than taking backports from WordPress. And remember, WordPress itself will break its own back-compat with 4.9 (i.e. with ClassicPress) in the long term. Soā¦ are we waiting for that to happen before taking action?
If the same reasoning is applied for everything it will be very very very difficult to improve anything other than taking backports from WordPress
Itās simply not true.
There are about as many things as lines of code in the cp cms to improve or add without breaking stuff
Like adopt a plugin.
Add new features which donāt (potentially or less) break things.
Add support for external download in the plugin headers.
As said. All I can say is I canāt confidently say āthis aināt going to be an issueā
And reading the effort, itās more effort than it brings advantage.
Maybe Iām wrong, thatās what I think and where I see room for (tons of, some simple others not) stuff to be done that really shows itās alive.
That said, weāre going in circles in each and every single thread.
It seems thereās not a big understanding about how bad cp actually is without looking at deprecated code but simply by looking at missing features and limping-behind security
Thatās my main concern, along with getting plugins and themes.
And I believe we should invest every second and n such things, and leave the āstuff already thereā as it is, unless we enhance it as in add/update to last stand.
Does that make sense?
Iām not sure what others think about itā¦ itās just what I see when I use, look at and explore cp ecosystem.
2 Likes
It makes total sense, it really does. The thing is I want ClassicPress to keep on, so I really feel a bit bad about those circles you mean.
Next month I will start developing a business website for someone and I want to use ClassicPress. Itās that or switching to CraftCMS. Definitely not āWixā Press.
Maybe Iām obsessed with changes and itās because of my personal needs. All the sites I manage use custom plugins for very specific tasks, no builders no ācontact formā and so on. And itās why from that point of view there is a lot of room for change. And, I dislike seeing that room for change and not being able to do anything.
My idea with this petition was to keep playing with an experimental version of core, see how much I can do with it but also cooperate with ClassicPress by solely focusing on Plugins and Themes, where there is way more āfreedomā. As long as it works, I can collaborate with the community without asking for permission. But still somehow be on the boat. Appreciate it and eventually help with something I care about.
Iām with @anon66243189 here. This seems to me to be a lot of effort for little gain and potentially lots of problems. That effort is better used elsewhere.
For example, Iāve just submitted my first plugin. When thatās all done successfully, I will follow that with others I have in the works. This seems to me to be a better use of everyoneās time.
5 Likes
@moderators - I vote to close this petition as wonāt do. I agree it makes more sense to focus on expanding the Plugin Directory now (btw, just sent a plugin for review, to allow cloning posts).
And this, even if itās modernizingā¦ will be blocking progress more than helping.
3 Likes
This topic was automatically closed after 47 hours. New replies are no longer allowed.