Opened 12 months ago
Last modified 10 days ago
#20813 new defect (bug)
_get_plugin_data_markup_translate fails to load plugin translations
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Future Release |
| Component: | I18N | Version: | 2.9 |
| Severity: | normal | Keywords: | has-patch dev-feedback |
| Cc: | juliobosk@…, frank@…, mattyrobuk@… |
Description
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)
Change History (11)
- 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
- 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.
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 )
- 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.
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.
comment:10
MattyRob — 2 weeks 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:
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?

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