Make the deprecated parameter in load_plugin_textdomain() optional

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.
:man_shrugging:

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.