load_plugin_textdomain fails if plugin is loaded from mu-plugins

[ideag]

load_plugin_textdomain is realative to WP_PLUGIN_DIR, so it fails to load localization files if plugin keeps them in its directory.

The function should check if is called from mu-plugins and use WP_MUPLUGIN_DIR in that case.

I can fix this in my own plugin by adding '../mu-lugins/' like this:

  load_plugin_textdomain( 'tiny_tribuna', false, '../mu-plugins/'.dirname( plugin_basename( __FILE__ ) ) . '/languages/');

but this is not a good option for other plugins.

[ocean90]

You should use load_muplugin_textdomain() then.

[ideag]

Problem is, a lot of plugins only use load_plugin_textdomain() :| That means I would have to modify them after every upgrade. Oh well, I guess I can contact the creators of those plugins,

[SergeyBiryukov]

Here's a workaround I wrote for one of my plugins in case someone decided to put it in mu-plugins:

if ( false !== strpos( __FILE__, basename( WPMU_PLUGIN_DIR ) ) )
	load_muplugin_textdomain( '...' );
else
	load_plugin_textdomain( '...', false, dirname( plugin_basename( __FILE__ ) ) );

[nacin]

We should probably merge these functions to look in both directories — plugins then mu-plugins.

[ideag]

Replying to nacin:

We should probably merge these functions to look in both directories — plugins then mu-plugins.

something like this?

function load_plugin_textdomain( $domain, $abs_rel_path = false, $plugin_rel_path = false ) {
          $locale = apply_filters( 'plugin_locale', get_locale(), $domain );
	
	        if ( false !== $plugin_rel_path ) {
	                $path = WP_PLUGIN_DIR . '/' . trim( $plugin_rel_path, '/' );
	        } else if ( false !== $abs_rel_path ) {
	                _deprecated_argument( __FUNCTION__, '2.7' );
	                $path = ABSPATH . trim( $abs_rel_path, '/' );
	        } else {
	                $path = WP_PLUGIN_DIR;
	        }

                if (!is_readable($path)) {
                        $path = WPMU_PLUGIN_DIR . '/' . trim( $plugin_rel_path, '/' );
                }
	
	        $mofile = $path . '/'. $domain . '-' . $locale . '.mo';
	        return load_textdomain( $domain, $mofile );
}

[johnbillion]

23794.patch​ adds the mu-plugin fallback from ideag and updates the inline docs and deprecated argument so it's in line with other deprecated arguments.

[TroyDesign]

I solved using code below:

add_filter( 'load_textdomain_mofile', 'tdc_mu_load_textdomain_mofile', 10, 2 );
function tdc_mu_load_textdomain_mofile($mofile, $domain) {
	$mumofile = WPMU_PLUGIN_DIR.preg_replace('%^'.WP_PLUGIN_DIR.'%','',$mofile);
	if (file_exists($mumofile)) return $mumofile;
	else return $mofile;
}

[danielbachhuber]

This is also a problem for plugins installed in themes.

[swissspidy]

We could tackle this together with #34114 (Remove the requirement to call load_plugin_textdomain() or load_theme_textdomain()), though it might also make this enhancement obsolete. Anyway, it's not a big task.

[swissspidy]

23794.diff​ deprecates load_muplugin_textdomain() as per Nacin's comment and makes load_plugin_textdomain() try the mu-plugins directory as well.

@ocean90 Since we worked on #34114, what do you think about this change here?

[flixos90]

I'm not sure if we should deprecate load_muplugin_textdomain(). I'm curious how many plugin authors do something like the check in https://core.trac.wordpress.org/ticket/23794#comment:4. Also, shouldn't it be the plugin author's responsibility to support his/her plugin as an mu-plugin as well?

Anyway, if we don't change this, I think we should improve the codex on this - make new plugin authors aware that there is the concept of mu-plugins and how they can support it.

[voldemortensen]

Punting from 4.6. Please move back if a decision is reached an patch produced.

[swissspidy]

Suggesting wontfix since we have just-in-time translation loading