_get_plugin_data_markup_translate fails to load plugin translations

[arnee]

Example Plugin:

Plugin Name: XYZ
Text Domain: zzz
Domain Path: /lang

For showing the translated description, _get_plugin_data_markup_translate() will be called.

function _get_plugin_data_markup_translate( $plugin_file, $plugin_data, $markup = true, $translate = true ) {

  // Translate fields
  if ( $translate ) {
    if ( $textdomain = $plugin_data['TextDomain'] ) {
      if ( $plugin_data['DomainPath'] )
        load_plugin_textdomain( $textdomain, false, dirname( $plugin_file ) . $plugin_data['DomainPath'] );

This will call (replaced vars with values):

load_plugin_textdomain( 'zzz', false, "/full/path/to/plugin/dir/" . "lang" );

But load_plugin_textdomain only accepts the subdirectory "lang" as the third argument, leading to an incorrect path since WP_PLUGIN_DIR will be put in front.

The fix is to use basename(dirname()) to only get the plugin directory instead of the full path.

[arnee]

Actually, this problems also happens without a Domain Path. For what I've tested, loading the translations doesn't work in any case.

[nacin]

In 2.9, it was the second argument, which is a path relative to ABSPATH. I can't say it would have worked then, either.

I'm setting this to 3.4 as it would be nice to have this working, since WP_Theme (#20103) got it to work for themes.

[arnee]

Yes, the theme function has a different definition and less logic inside, so it is not a problem there...

function load_theme_textdomain( $domain, $path = false )

function load_plugin_textdomain( $domain, $abs_rel_path = false, $plugin_rel_path = false )

[nacin]

Core calls get_plugin_data() in a few different ways. When it calls it with $translate = true, this won't work — as an absolute $plugin_file is passed to _get_plugin_data_markup_translate(), and it fails.

But when core calls _get_plugin_data_markup_translate() in the plugins list table, it does it with a *relative* $plugin_file argument. So it works on plugins.php.

So, while there is definitely a bug here, it will need to account for both relative and absolute paths, or we need to have _get_plugin_data_markup_translate() always receive relative paths.

But, what's the indication of a bug? Core displays the translation just fine on plugins.php. Seems like it would only affect the bulk upgrader. Kicking this to future release as there is no immediate breakage.

[arnee]

Yes, you are right. I thought this bug was the reason for another problem I was debugging.
is_textdomain_loaded('mydomain') returns true of there was a

__('translate','mydomain')

call before. I initially thought this empty textdomain came from the _get_plugin_data_markup_translate bug, but that is not the case.

[MattyRob]

Possibly related: #14287

I am getting issues reported for my plugin that I think might be related to this bug:
​http://wordpress.org/support/topic/subscribe2-version-891-error?replies=13

And I don't think I'm alone:
​http://wordpress.org/support/topic/wrong-textdomain-path-on-iis?replies=1

I have tested the patch and it worked fine for me with no apparent problems and no errors in WP_DEBUG mode on the front side or any of the dozen or more admin side pages I loaded.

Is there anything else specifically that you would like tested or can this be committed?

[shaieden]

Hi there,

This tickets was set 15 months ago... And the issue still exists.
I am also with wp on iis and fixed this only with the above patch.

I think this should have already been solved in the last version of wp.
Seems it's been forgotten.

I also think this issue is critical. I was facing this with almost every second plugin that I have tried to install, including BuddyPress, Importer and many more. It just blocks the entire plugins page, and you cannot do anything.

Shai

[SergeyBiryukov]

According to comment:10, looks like this causes issues when using IIS. Moving for review.

[dd32]

In 25081:

Sanitize the plugin path in _get_plugin_data_markup_translate() to a WP_PLUGIN_DIR-relative path. The function is designed in mind for receiving relative paths, but may be used with a absolute path.
This change makes the function path-agnostic, and can accept either relative or absolute (converting to relative internally). Fixes #20813

[nacin]

#23460 was marked as a duplicate.