WordPress.org

Make WordPress Core

Opened 18 months ago

Closed 18 months ago

Last modified 18 months ago

#49807 closed defect (bug) (worksforme)

load_plugin_textdomain() expects a path relative to plugins/, making i18n for mu-plugins difficult

Reported by: theMikeD Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: I18N Keywords:
Focuses: Cc:

Description

Looking though the code for load_plugin_textdomain() (https://core.trac.wordpress.org/browser/tags/5.4/src/wp-includes/l10n.php#L797) I can see that it is expecting to receive a path relative to the plugins folder, as defined by WP_PLUGIN_DIR.

All fine as long as the plugin is located within the folder defined by WP_PLUGIN_DIR...but mu-plugins are not; they are typically in a folder parallel to WP_PLUGIN_DIR but they can be anywhere via the WPMU_PLUGIN_DIR define.

This makes it very difficult to add a text domain to a mu-plugin, since the only way I have so far found is to pass a relative folder, such as ../mu-plugins/plugin-folder/languages, which is problematic because it's making assumptions about the setup.

Together with the apparently missing easy way to determine if a plugin is loaded normally or as part of the must-use loader, it's impossible to write load_plugin_textdomain() in a generic way that accounts for mu-plugins.

The solution would seem to be to un-deprecate the second argument, but I'm not aware of the discussion around why it was removed.

I hope someone can point out something easy I have overlooked!

Change History (2)

#1 @ocean90
18 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed

Hello @theMikeD, for mu-plugins you can use load_muplugin_textdomain().

#2 @theMikeD
18 months ago

Ah ha...the aforementioned easy solution! Amazing that all my googling didn't reveal this nugget. Thanks!

Note: See TracTickets for help on using tickets.