What are the details of this BadMethodCallException?

On 18 December 2016 at 23:46, Daniel Barrett danb@cimpress.com wrote:

Forgot to mention:

• MediaWiki 1.28.0 is the official release,
• I did upgrade VisualEditor to the "1.28" release downloaded via

ExtensionManager.

• The BadMethodCallException occurs on every page load, not just when

trying to run VisualEditor.

DanB ________________________________ From: Daniel Barrett Sent: Sunday, December 18, 2016 6:31:16 PM To: Wikimedia developers Subject: VisualEditor in 1.28 - fails after upgrade from 1.27

After updating my wiki from 1.27.1 to 1.28.0, VisualEditor has stopped working. I click the Edit tab, and the page content fades slightly in color as if VisualEditor were about to load. But then the editor tools don't appear, and Chrome displays a dialog box:

 example.com responded:  "http"  [OK] [Cancel]

There are no PHP errors in the Apache error log, and no errors in the parsoid log file (looks like a normal parsoid access). However, Chrome developer tools show a JavaScript error: BadMethodCallException. If I remove VisualEditor from LocalSettings.php, the error vanishes.

The only extension I am running is VisualEditor; otherwise it's a vanilla MediaWiki that requires users to be logged into read (a private wiki). The same LocalSettings.php files works perfectly in MW 1.27.1.

Has anything significantly changed in VisualEditor that I need to configure it differently?

LocalSettings.php has:

# visual editor $wgDefaultUserOptions['visualeditor-enable'] = 1; $wgDefaultUserOptions['visualeditor-enable-experimental'] = 1;

$wgVirtualRestConfig['modules']['parsoid'] = array( 'url' => 'http://localhost:8142', 'prefix' => 'example.com' );

$wgSessionsInObjectCache = true; /* Using memcached */ $wgVirtualRestConfig['modules']['parsoid']['forwardCookies'] = true;

The parsoid settings file has:

parsoidConfig.setMwApi({ prefix: 'example.com', uri: ' http://dev.example.com/w/api.php' }); parsoidConfig.useSelser = true;

Thank you for any insights! DanB

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Mon, 2016-12-19 at 02:05 +0000, Daniel Barrett wrote:

/* [37fc66f00dced89747fd4433] 2016-12-18 23:40:16: Fatal exception of type "BadMethodCallException" */

See https://www.mediawiki.org/wiki/Manual:How_to_debug#PHP_errors%C2%A0for how to enable $wgShowExceptionDetails .

Cheers, andre

Here you go:

BadMethodCallException from line 845 of <...>/w/includes/session/SessionManager.php: Sessions are disabled for this entry point

load.php?debug=false&lang=en&modules=startup&only=scripts&skin=vector:4 [43d736c07dd76d73cf26db20] /w/load.php?debug=false&lang=en&modules=startup&only=scripts&skin=vector BadMethodCallException from line 845 of <...>/w/includes/session/SessionManager.php: Sessions are disabled for this entry point

Other people are reporting this same problem on Extension_Talk:VisualEditor.

https://www.mediawiki.org/wiki/Extension_talk:VisualEditor

That thread points to this description on https://www.mediawiki.org/wiki/Manual:SessionManager_and_AuthManager/Updatin... :

"The majority of these errors are caused by attempted use of $wgLanghttps://www.mediawiki.org/wiki/Manual:$wgLang (or, equivalently, RequestContext::getMain()->getLanguage()), since Message objects default to using that. If you're in something ResourceLoader-specific, you'll want to use the language on the ResourceLoaderContext instead of letting Message default to the session user's language."

DanB

________________________________ From: Wikitech-l wikitech-l-bounces@lists.wikimedia.org on behalf of Alex Monk amonk@wikimedia.org Sent: Monday, December 19, 2016 5:12:13 AM To: Wikimedia developers Subject: Re: [Wikitech-l] VisualEditor in 1.28 - fails after upgrade from 1.27

Thanks Andre. Yeah, I'll need more than that to help.

On 19 Dec 2016 10:10 am, "Andre Klapper" aklapper@wikimedia.org wrote:

On Mon, 2016-12-19 at 02:05 +0000, Daniel Barrett wrote:

...

/* [37fc66f00dced89747fd4433] 2016-12-18 23:40:16: Fatal exception of type "BadMethodCallException" */

See https://www.mediawiki.org/wiki/Manual:How_to_debug#PHP_errorshttps://www.mediawiki.org/wiki/Manual:How_to_debug#PHP_errors for how to enable $wgShowExceptionDetails .

Cheers, andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/http://blogs.gnome.org/aklapper/

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l

I feel like that sessions error was something we fixed months ago but can't find details right now. Certainly not the first time I've seen it...

On 19 Dec 2016 3:31 pm, "Brad Jorsch (Anomie)" bjorsch@wikimedia.org wrote:

On Mon, Dec 19, 2016 at 8:20 AM, Daniel Barrett danb@cimpress.com wrote:

...

Here you go:

BadMethodCallException from line 845 of <...>/w/includes/session/

SessionManager.php:

...

Sessions are disabled for this entry point

load.php?debug=false&lang=en&modules=startup&only=scripts&skin=vector:4 [43d736c07dd76d73cf26db20] /w/load.php?debug=false&lang= en&modules=startup&only=scripts&skin=vector BadMethodCallException

from

...

line 845 of <...>/w/includes/session/SessionManager.php: Sessions are disabled for this entry point

Ok, that's a start. Can you get the rest of the stack trace for the exception so we can figure out how that's getting called?

-- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

OK, I have traced the issue, and I'm embarrassed to say, it's in a custom extension.

(I removed the extension yesterday and the error kept happening, so I figured the extension

was harmless... but I'll bet I was fooled by browser caching.)

Apologies if my incorrect information wasted anyone's time.

The real issue is that a custom callback for the hook "SpecialPages_initList" is invoking RequestContext::getMain()->getUser()->isLoggedIn().

Apparently that doesn't work.

I'll take a guess that SpecialPages_initList runs too early for this check to succeed?

My goal is to remove some special pages for anonymous users but permit logged-in users to see them.

Is there a better way to check for a logged-in user at this hook point? Or a better way to remove

special pages for anonymous users?

Thank you very much for any advice,

DanB

________________________________ From: Daniel Barrett Sent: Monday, December 19, 2016 8:21 PM To: Wikimedia developers Subject: Re: [Wikitech-l] VisualEditor in 1.28 - fails after upgrade from 1.27

Ok, that's a start. Can you get the rest of the stack trace for the exception so we can figure out how that's getting called?

Sure. How do I get a full stack dump when the error appears only in the Chrome developer console?

BadMethodCallException from line 845 of <...>/w/includes/session/SessionManager.php: Sessions are disabled for this entry point

I've already enabled $wgShowExceptionDetails (which caused slightly more detail to appear, but no stack dump) and set every other debugging flag in sight on https://www.mediawiki.org/wiki/Manual:How_to_debug#PHP_errors in LocalSettings.php and in index.php. The only output I get is the above line in the Chrome developer console. The error does not appear in the associated Apache error log file.

DanB

________________________________ From: Wikitech-l wikitech-l-bounces@lists.wikimedia.org on behalf of Alex Monk amonk@wikimedia.org Sent: Monday, December 19, 2016 9:38 AM To: Wikimedia developers Subject: Re: [Wikitech-l] VisualEditor in 1.28 - fails after upgrade from 1.27

I feel like that sessions error was something we fixed months ago but can't find details right now. Certainly not the first time I've seen it...

On 19 Dec 2016 3:31 pm, "Brad Jorsch (Anomie)" bjorsch@wikimedia.org wrote:

On Mon, Dec 19, 2016 at 8:20 AM, Daniel Barrett danb@cimpress.com wrote:

...

Here you go:

BadMethodCallException from line 845 of <...>/w/includes/session/

SessionManager.php:

...

Sessions are disabled for this entry point

load.php?debug=false&lang=en&modules=startup&only=scripts&skin=vector:4 [43d736c07dd76d73cf26db20] /w/load.php?debug=false&lang= en&modules=startup&only=scripts&skin=vector BadMethodCallException

from

...

line 845 of <...>/w/includes/session/SessionManager.php: Sessions are disabled for this entry point

On Tue, Dec 20, 2016 at 2:00 AM, Bartosz Dziewoński matma.rex@gmail.com wrote:

On 2016-12-20 06:22, Daniel Barrett wrote:

...

The real issue is that a custom callback for the hook "SpecialPages_initList" is invoking RequestContext::getMain()->get User()->isLoggedIn().

Apparently that doesn't work.

I'll take a guess that SpecialPages_initList runs too early for this check to succeed?

My goal is to remove some special pages for anonymous users but permit logged-in users to see them. Is there a better way to check for a logged-in user at this hook point? Or a better way to remove special pages for anonymous users?

Yes, the list of special pages can't depend on anything related to the current user.

Instead, you should check whether the user is logged in when displaying the special page. You can just call `$this->requireLogin();` at the beginning of the special page's execute() function – this will check whether the user is logged in, and if not, display an error message and abort execution. You can optionally pass a custom error message. See e.g. /includes/specials/SpecialWatchlist.php in MediaWiki for an example.

And to hide a special page on Special:SpecialPages from users who can't use it, have the page's userCanExecute() return false when appropriate and have isRestricted() return true. If the check is based on having one user right, this can be easily done by passing the user right as the $restriction parameter to SpecialPage::__construct().

On Mon, Dec 19, 2016 at 8:21 PM, Daniel Barrett danb@cimpress.com wrote:

...

Ok, that's a start. Can you get the rest of the stack trace for the exception so we can figure out how that's getting called?

Sure. How do I get a full stack dump when the error appears only in the Chrome developer console?

BadMethodCallException from line 845 of <...>/w/includes/session/ SessionManager.php: Sessions are disabled for this entry point

I've already enabled $wgShowExceptionDetails (which caused slightly more detail to appear, but no stack dump) and set every other debugging flag in sight on https://www.mediawiki.org/wiki/Manual:How_to_debug#PHP_errors in LocalSettings.php and in index.php. The only output I get is the above line in the Chrome developer console. The error does not appear in the associated Apache error log file.

If you haven't already done so, set up logging as described at https://www.mediawiki.org/wiki/Manual:How_to_debug#Logging.

Then you can look up that code (the "[43d736c07dd76d73cf26db20]") in the error log file.