@mbabker Do you know why the languagefilter plugin is loaded this early and if it would be OK to load all system plugins instead?

I remember something about this but cant find the reference - I am sure that @infograf768 will know

Alzheimer here, but for sure we had issues in the past when some other system plugins were loaded first. I remember we were always advising to move the langfilter plugin on top in the manager until this patch was done.

The change was done in Feb 2011 for 1.7.3 with this comment:

# [#24750] If a system plugin tries to load its language file, Joomla! falls back to setting the default site language to English.

See: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=24750&start=0

OK, so now we know why the languagefilter plugin is loaded early. But could we load all the plugins at the same time. The problem is that the languagefilter plugin loads the menu's and then plugins that want to intercept the menu database calls can not do so as they are cached by the lanuguage filter plugin. Another solution could be to force the languagefilter plugin to not cache the database call to the menu's.

@mbabker what solution do you propose?

Architecturally hardcoded references to a single plugin is a major code smell and indicates a lot of logic needs to be rethought.

The problem is that the languagefilter plugin loads the menu's and then plugins that want to intercept the menu database calls can not do so as they are cached by the lanuguage filter plugin.

Please explain this one further. The plugin's constructor doesn't have any interactions with the menu system nor does anything in the chain of JPluginHelper::importPlugin(). The onAfterInitialise event is probably what you're having conflicts with because it makes an explicit call to $app->getRouter() and instantiating a JRouterSite object causes a JMenu object to be loaded which does cause the menu system to get pulled in. So for your issue specifically you're getting back into that issue that was "patched" regarding the load order of system plugins.

Thank you so much for chiming in @mbabker your insight is greatly appreciated.

Yes you are correct. Our issue is with Neno the translation extension we develop. We supply our own database system plugin that intercepts all database calls and re-routes them into the correct table for the current language but we are unable to do this for menu's as they are called BEFORE our plugin, even when sorted highest.

We are happy to develop the patch for Joomla to solve this issue. But I am unsure what would be the correct method. The patch I have attached to this pull request WOULD solve our issue, but I am not sure if it would cause any new ones?

If you could guide us in the right direction I would be very pleased.

I don't know the patch's side effects. I don't touch the multilingual features of Joomla. If the line in question though forces the languagefilter plugin to always have first priority, regardless of the ordering set in the plugin manager, that to me smells like a bug too (the ordering should always be respected even if you manually import every plugin in a group versus import the entire group).

As is, the application has a hardcoded dependency to the plugin's constructor. Specifically, what you really need is these lines moved into the application class and I'd say wrapped in a JPluginHelper::isEnabled() check. The first one is easy as it's just a boolean, but the second needs the plugin parameters, so it's actually introducing more hardcoding to the plugin if you move those lines to the application class but it should in theory remove the need to import the system plugins in full at this point. When something calls JPluginHelper::import() is when I think the ordering issue comes into play, and that only happens during JPluginHelper::importPlugin(). So this logically should work:

if (JPluginHelper::isEnabled('system', 'languagefilter') {
    $this->setLanguageFilter(true);

    // Get the plugin's params

    $this->setDetectBrowser($pluginParams->get('detect_browser', '1') == '1')
}

See #10344 for alternate solution.

Closing this PR as we have a merged solution, see #10344