'locale' filter applied before plugins loaded

http://wordpress.org/pipermail/cvs/2005-January/000965.html http://wordpress.org/pipermail/cvs/2005-January/000966.html

In the fix for this, load_plugin_textdomain() can be called from an earlier-loading plugin and trump any later-loading plugins' abilities to hook into locale. Reopening.

We may need to add the ability to specify plugin load order to fix this. Brainstorm:

Add a Priority: field to the plugin header. Value is from 1 - 10 with 1 being highest priority. Plugins without a Priorty field will get a priority of 10.

When a plugin is activated, order it according to priority in the active_plugins array. We'll need to store the priorities for each of the active plugins somehow. Maybe make the active plugins array two dimensional -- $active_plugins[priority] = array(plugins_for_this_priority). This would be really easy. We'd have to handle upgrading from the current single dimensional array, but that shouldn't be difficult.

Sounds like good idea to me. Let's see if I can brainstorm something else.

I suppose we're in a catch-22 with $locale, since plugins require load_plugin_textdomain() to be declared already so that they can call it, which in turn requires that $locale either already be set or get set dynamically -- thus get_locale(). But plugins also call load_plugin_textdomain() in series, making it impossible to even make sure all plugins have the same gettext module loaded, even if we just got rid of the if (isset($locale)) test in get_locale().

I suppose in order to alleviate this we'd have to find a way to delay the setting of $locale and execution of load_plugin_textdomain() until all plugins have loaded. The order would need to be as follows:

- Load all plugins - $locale set & filtered - load_plugin_textdomain() executed for each plugin for which it was called

Perhaps if we were to automatically call load_plugin_textdomain() when needed, as I've done with my localization functions in Multilingual:

if (isset($l10n[$domain]) load_plugin_textdomain($domain)) {

return $l10n[$domain]->translate($text);

That way it can be delayed until it's needed, and it would put the steps above in the necessary order. (Plus it wouldn't require plugin authors to remember to call load_plugin_textdomain().) This would also, however, mean that any localization happening in each of the plugins would need to be delayed until at least after load_plugin_textdomain() is called. Which is fine for anything that's executing on an action or filter, but anything not contained in a delayed-execution function would not be able to be localized. (I don't have any localization outside of functions in Multilingual... would it even be logical to have any? Hmm.)

So, we'd have to find a way to delay all localization functions too:

- Load all plugins - $locale set & filtered - load_plugin_textdomain() executed for each plugin for which it was called - Any (), _e() and ngettext() that were already called are now executed

I can't think of any way that would be possible, short of simply educating plugin authors that in order to play nicely with others, one must never localize text outside of a filter or action function. Or we could make it conventional never to execute any code 'bare', but rather the very first code to be executed should be hooked into init. Which would, come to think of it, just be a good idea anyhow.

However, all of this would be much more convoluted and require plugin authors to either adapt their plugins or read up on conventions, and it would be tough to get them to do that. So I think your idea would definitely be easiest. That said, some more rigid conventions could make the plugin system run more smoothly. Perhaps we should do both? </brainstorm>

edited on: 02-01-05 22:45

Shouldn't plugins be able to manipulate the active plugins array to "shuffle" themselves to the front if need be?