Make WordPress Core

Opened 10 years ago

Closed 8 years ago

Last modified 8 years ago

#20813 closed defect (bug) (fixed)

_get_plugin_data_markup_translate fails to load plugin translations

Reported by: arnee Owned by: dd32
Milestone: 3.7 Priority: normal
Severity: normal Version: 2.9
Component: I18N Keywords: has-patch dev-feedback
Focuses: Cc:


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.

Attachments (1)

basename-patch.patch (803 bytes) - added by arnee 10 years ago.

Download all attachments as: .zip

Change History (15)

#1 @arnee
10 years ago

  • Keywords has-patch dev-feedback needs-testing added
  • Summary changed from _get_plugin_data_markup_translate fails to load plugin translations with DomainPath to _get_plugin_data_markup_translate fails to load plugin translations

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

#2 @nacin
10 years ago

  • Milestone changed from Awaiting Review to 3.4
  • Version changed from 3.4 to 2.9

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.

#3 @nacin
10 years ago

  • Component changed from Plugins to I18N

#4 @arnee
10 years ago

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 )

#5 @nacin
10 years ago

  • Milestone changed from 3.4 to Future Release
  • Severity changed from major to normal

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.

#6 @arnee
10 years ago

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


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

Last edited 10 years ago by arnee (previous) (diff)

#7 @juliobox
10 years ago

  • Cc juliobosk@… added

#8 @Bueltge
9 years ago

  • Cc frank@… added

#9 @MattyRob
9 years ago

  • Cc mattyrobuk@… added

#10 @MattyRob
9 years ago

  • Keywords needs-testing removed

Possibly related: #14287

I am getting issues reported for my plugin that I think might be related to this bug:

And I don't think I'm alone:

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?

Last edited 9 years ago by SergeyBiryukov (previous) (diff)

#11 @shaieden
8 years ago

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.


#12 @SergeyBiryukov
8 years ago

  • Milestone changed from Future Release to 3.7

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

#13 @dd32
8 years ago

  • Owner set to dd32
  • Resolution set to fixed
  • Status changed from new to closed

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

#14 @nacin
8 years ago

#23460 was marked as a duplicate.

Note: See TracTickets for help on using tickets.