At least in the case of this extension, the code is wrong.

$app = JFactory::getApplication();

if ($app->isSite()) {
    $menu = $app->getMenu();
    $items = $menu->getItems('link', $link);

    // Other stuff
}

There is no need to instantiate a new application class to get the menu data. Doesn't answer the potential recursive dependency problem, but fixing the extension code avoids that.

Same problem to me.
At this time, I have disabled language filter plugin and notice error disappears. I am waiting the next update.

Need more info to reproduce.

https://downloads.joomla.org is a multi-language website which has the language filter plugin enabled and this problem cannot be triggered on this site (it is in essence core Joomla plus Akeeba Release System and an extra system plugin specific for our addons). Which means there is some specific configuration or combination of extensions creating the problem.

On its own, the error message is not going to provide enough detailed information to troubleshoot anything. Detailed information such as stack traces, the data in the variables on the dispatcher line that is failing, and which check in that line is creating the message is going to be needed.

How I have got this error?
I was working with joomla 3.8.5 and php 7.0.X. All was working perfectly without any trouble.
Yesterday to me, When the joomla 3.8.6 has been available in my joomla backend, I made the automatic update. But it didn't work. I downloaded the joomla update package for installation and the error appeared.
First, I was thinking it was a problem with php 7.0.X and I changed my php version to php 7.1.X (7.1.15), I made a new joomla automatic update and it did it (without any trouble), but the error was still there and impossible to get user page (easysocial) for example. I disabled language plugin filter and all works fine.

I my case disabling the "Language-Plugins" did not fix the problem.

can you test #19907

alikon I can confirm that #19907 solves the problem in my similar situation as described above.

happy that your issue is solved not happy because i still don't understand why this happens

did you use a multilingual site?
from what j version are you upgrading ?

I was trying to find a reason why all afternoon in my test setup.
I was upgrading from 3.8.5 and I am using a multilingual site.
Disabling the system languagefilter-plugin resolved the problem but left me with a non multilingual site.
So I think there has to be some connection with multiple languages setup.

So I think there has to be some connection with multiple languages setup.

It's going to be a specific combination of extensions if that is the case. As I pointed out earlier, our downloads site is a multi-language setup and is not experiencing this issue (the site is basically core Joomla plus Akeeba Release System plus a custom system plugin for the site). If it is indeed related to or caused by the language filter plugin, what configuration is the plugin set up to run with (perhaps there's a specific configuration that can trigger the issue but another configuration that won't)?

Just to add to this: I've experienced this issue on a site I look after and it does not use the multi-language plugin. I have however identified the custom plugin which was causing the issue.

I've got about half an hour spare so I'm going to see if I can narrow down the exact line of code...

Ok I've narrowed it down to a custom system plugin which had this code in a static function:
$Jsite = new JSite(); $menu = $Jsite->getMenu();

Changing to this solved it:
$app = JFactory::getApplication(); $menu = $app->getMenu();

That said, I have another site using the same plugin which hasn't broken.

It is very interesting, my observation
Go to 3.8.6 and apply this:

diff --git a/plugins/system/languagefilter/languagefilter.php b/plugins/system/languagefilter/languagefilter.php
index 9d5bf41b7d..2f9c01ff1f 100644
--- a/plugins/system/languagefilter/languagefilter.php
+++ b/plugins/system/languagefilter/languagefilter.php
@@ -174,7 +174,7 @@ class PlgSystemLanguageFilter extends JPlugin
         * @since   3.4
         */
        public function preprocessBuildRule(&$router, &$uri)
-       {
+       {$Jsite = new JSite(); $menu = $Jsite->getMenu();
                $lang = $uri->getVar('lang', $this->current_lang);
                $uri->setVar('lang', $lang);

It generate error on staging joomla.
After git stash; git checkout 3.8.5~1; git stash apply it works again.

gosh till now i'm investigating in a not multilanguage direction... confused

My feeling is it has nothing to do with WHERE the code is, it's just the simple fact of instantiating a new application that's doing it. Something tells me you could do (new JSite)->getMenu(); (new JSite)->getMenu(); in index.php and trigger it without running anything else too (as in something in at least the site application constructor is more than enough to trigger it).

The issue is generated by commit from #19687. I do not know why yet.

git checkout 3.8.6~12 - works
git checkout 3.8.6~11 - error

It's probably

Maybe instead of CMSApplication property ($this->metadataManager) it could be a Session property.

Wouldn't fly. The metadata manager's not part of the Session itself (nor should it be IMO) and then you really start getting into circular dependency potential.

For now you can just direct instantiate and run the MetadataManager when needed, for the app that's only in the checkSession method, but clearly we need to deal with the architectural dependency circle at some point (part of the problem is it all falls apart when you try to run

For now you can just direct instantiate and run the MetadataManager when needed,

It is OK,

but may be we do not need a $this->app in MetadataManager class. We can use $app->config in MetadataManager constructor like $this->metadataManager = new MetadataManager($this->config, \JFactory::getDbo());.

Or better we can put only array of options as in other places.

$opton['clientId'] = ...
$option['shared_session'] = ...
$this->metadataManager = new MetadataManager(\JFactory::getDbo(), $options);

Thought about that. Need the client ID when shared sessions aren't active to fill the appropriate column for the metadata. So it's either a DI'd app instance in the constructor, a DI'd app instance in the createRecordIfNonExisting method that actually has all the app dependencies, or a dependency to JFactory::getApplication() to be able to call $app->getClientId().

Or better we can put only array of options as in other places.

I'd rather not. Unkeyed options arrays aren't great for DI and we usually do zero validation on these arrays (you really need something like joomla-framework/database#101 in all the places we have options arrays so that there's some form of API to validate those arrays and create some self documenting code describing what those arrays should be). If you're really going to create an options array, I'd rather the constructor signature be (\JDatabaseDriver $db, int $appClientId, bool $sharedSessionsActive) and pass each value as separate arguments.

I'd rather the constructor signature be (\JDatabaseDriver $db, int $appClientId, bool $sharedSessionsActive) and pass each value as separate arguments.

Magnificent. I like it the most.

For now you can just direct instantiate and run the MetadataManager when needed,

After thinking, I think that it also has its advantages. And could be joined with above.

For 3.x, I'd just change the checkSession method and not have the class member var. At least this way if you're writing something to work with it you can still do new MetadataManager(JFactory::getApplication(), JFactory::getDbo()) and not have to think too much about things.

In 4.0, with all the other architecture work ongoing, we can re-visit the manager's structure and where it exists by default.

So we have a solution.

Yep, #19912

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/19902

closed as having Pull Request #19912