Fresh Mediawiki + Math install gives Restbase URL error
Open, Needs TriagePublic

Description

It appears I'm having an issue similar to this one wherein my Math extension (installed on a fresh, recent copy of Mediawiki) can't render any formulas and gives the error

[780b446abf8a946e1cdb7c79] /wiki/index.php?title=Special:MathStatus MWException from line 213 of /var/www/html/wiki/extensions/Math/MathRestbaseInterface.php: Math extension can not find Restbase URL. Please specify $wgMathFullRestbaseURL.

The issue linked, however, indicates that the problem goes away if you set the math extension to render PNGs but I'm having problems across the board. I've tried setting the system to render PNGs only, or even just plain source with no luck: the same error keeps appearing on the Special:MathStatus page. Note: I do not have Visual Editor installed.

Here's the backtrace from MathStatus:

Backtrace:

#0 /var/www/html/wiki/extensions/Math/MathRestbaseInterface.php(352): MathRestbaseInterface->getUrl(string)
#1 /var/www/html/wiki/extensions/Math/MathRestbaseInterface.php(110): MathRestbaseInterface->getCheckRequest()
#2 /var/www/html/wiki/extensions/Math/MathRestbaseInterface.php(103): MathRestbaseInterface->checkTeX()
#3 /var/www/html/wiki/extensions/Math/MathRestbaseInterface.php(395): MathRestbaseInterface->calculateHash()
#4 /var/www/html/wiki/extensions/Math/MathRestbaseInterface.php(95): MathRestbaseInterface->getContentRequest(string)
#5 /var/www/html/wiki/extensions/Math/MathRestbaseInterface.php(224): MathRestbaseInterface->getContent(string)
#6 /var/www/html/wiki/extensions/Math/MathRenderer.php(657): MathRestbaseInterface->getSvg()
#7 /var/www/html/wiki/extensions/Math/MathMathML.php(357): MathRenderer->getSvg()
#8 /var/www/html/wiki/extensions/Math/MathMathML.php(398): MathMathML->correctSvgStyle(NULL)
#9 /var/www/html/wiki/extensions/Math/MathMathML.php(466): MathMathML->getFallbackImage()
#10 /var/www/html/wiki/extensions/Math/SpecialMathStatus.php(70): MathMathML->getHtmlOutput()
#11 /var/www/html/wiki/extensions/Math/SpecialMathStatus.php(52): SpecialMathStatus->testSpecialCaseText()
#12 /var/www/html/wiki/extensions/Math/SpecialMathStatus.php(42): SpecialMathStatus->runMathMLTest(string)
#13 /var/www/html/wiki/includes/specialpage/SpecialPage.php(479): SpecialMathStatus->execute(NULL)
#14 /var/www/html/wiki/includes/specialpage/SpecialPageFactory.php(576): SpecialPage->run(NULL)
#15 /var/www/html/wiki/includes/MediaWiki.php(282): SpecialPageFactory::executePath(Title, RequestContext)
#16 /var/www/html/wiki/includes/MediaWiki.php(745): MediaWiki->performRequest()
#17 /var/www/html/wiki/includes/MediaWiki.php(519): MediaWiki->main()
#18 /var/www/html/wiki/index.php(43): MediaWiki->run()
#19 {main}
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 4 2016, 1:52 PM
Glosser.ca updated the task description. (Show Details)Nov 4 2016, 1:53 PM
Glosser.ca updated the task description. (Show Details)Nov 4 2016, 1:57 PM

What is your setting for $wgMathFullRestbaseURL?

I ran into this problem today without setting $wgMathFullRestBaseURL.

It took me a while to track it down.

The code for the special page seems to indicate that if MathML isn't valid, then this error wouldn't show up. So I set $wgMathValidModes to plain an latex.

This didn't fix the problem. Debugging showed that by the time the Special Page was called, $wgMathValidModes contained mathml. In fact, it contained all the settings with the two that I set repeated at the end.

After more debugging, it looks like this is caused by merge strategy. I don't see a way to fix this problem at the present aside from forcing the user to set $wgMathValidModes in their LocalSettings.php and removing the value in the extension.json (or, maybe just setting it to plain).

Patch incoming, but I think this is a problem with the extension.json schema.

saper added a subscriber: saper.Jan 26 2017, 6:49 PM

Looks like those merge strategies are just an ugly (hopefully temporary) hack...

This is one of the places where PHP and arrays really suck. The default array_merge will end up combining your array from LocalSettings.php with the defaults in extension.json...so what we typically do is:

$wgMathValidModes['png'] = true;

In extension.json we'd default everything set to true in an assoc array, and if people want to disable it in LocalSettings.php, they'd set it to false. We did a similar transition in VisualEditor where we introduced a new config setting in the assoc array form (so like $wgMathEnabledModes) deprecated the old one but still read any values from it, and then removed the old one after a while.

Change 334409 had a related patch set uploaded (by MarkAHershberger):
Allow end user to enable or disable extensions w/ ext. dependencies

https://gerrit.wikimedia.org/r/334409

Sorry, the alternative of removing everything from extension.json and leaving it empty also works, but I think we'd prefer to have extensions that ship with sane defaults.

In extension.json we'd default everything set to true in an assoc array, and if people want to disable it in LocalSettings.php, they'd set it to false.

This makes some sense. I'll amend my patch with your suggestion.

Change 334409 abandoned by MarkAHershberger:
Allow end user to enable or disable extensions w/ ext. dependencies

Reason:
wrong branch

https://gerrit.wikimedia.org/r/334409

Change 334646 had a related patch set uploaded (by MarkAHershberger):
Allow end user to enable or disable extensions w/ ext. dependencies

https://gerrit.wikimedia.org/r/334646

Change 334647 had a related patch set uploaded (by MarkAHershberger):
Allow end user to enable or disable extensions w/ ext. dependencies

https://gerrit.wikimedia.org/r/334647

Change 334646 abandoned by MarkAHershberger:
Allow end user to enable or disable extensions w/ ext. dependencies

Reason:
too soon

https://gerrit.wikimedia.org/r/334646

Change 334646 restored by MarkAHershberger:
Allow end user to enable or disable extensions w/ ext. dependencies

Reason:
wrong branch

https://gerrit.wikimedia.org/r/334646

Change 334647 abandoned by MarkAHershberger:
Allow end user to enable or disable extensions w/ ext. dependencies

Reason:
too soon (right branch this time)

https://gerrit.wikimedia.org/r/334647

@Physikerwelt if you would like this solved another way, can you provide a suggestion?

I'm just afraid that the proposed change will break rendering in production and that it won't be backwards compatible to toher solutions.

@MarkAHershberger I have simplified your approach, since your patch did not work on my test server. Can you have a look if that's a workable solution for you. It simply reverts the new config loading via extension.json and defines the defaults in the hooks php file.

@Physikerwelt Although I would prefer having the configuration in extension.json, Your way is back-wards compatible and works for you. I'll test it and see if it works for my situation.

@Physikerwelt Although I would prefer having the configuration in extension.json

me too

, Your way is back-wards compatible and works for you. I'll test it and see if it works for my situation.

and does it work?

Physikerwelt writes:

and does it work?

Yes.

Physikerwelt added a comment.EditedThu, Feb 22, 5:35 AM

It seems like a general solution will not be available soon, c.f. T186785. @MarkAHershberger is the problem still an issue?

What we typically do [to avoid this problem] is:

$wgMathValidModes['png'] = true;

In extension.json we'd default everything set to true in an assoc array, and if people want to disable it in LocalSettings.php, they'd set it to false. We did a similar transition in VisualEditor where we introduced a new config setting in the assoc array form [..]

Has this approach been tried? It seems like that would work for Math as well. In addition to using a new format for the config array, we can also keep (for one or two releases) the check in the registerExtension callback that look checks if $wgMathValidModes was set and is an array, and loop through to merge it in for back-compat.

@Krinkle that could certainly be implemented. However, we had to inform thousands of MW admins all over the world about the change in the config format. How should one explain that [ "A" => true, "B" => true ] is better than just [ "A", "B" ] ? Because we don't have a strategy to remove either A or B from the defaults?

[..] Because we don't have a strategy to remove either A or B from the defaults?

I'm not sure I understand. There is no immediate need to inform all MW admins. The system will remain backwards-compatible. The defaults will effectively remain the same. The only difference is that other extensions will be able to better interact with Math through extension.json by using the new format, which is currently not possible.

The proposal is that:

  • Remove wgMathValidModes (which uses list format) from default in extension.json.
  • Add a new default (different config name) to extension.json, which uses the associative boolean format.
  • In registerExtension check if wgMathValidModes exists (e.g. created by LocalSettings on existing installations), and move add its values to the new config attribute by key, with true as value.

Benefit:

  • Defaults are still in extension.json.
  • MW admins that want to, can now easily disable or enable individual modes without needing to know all other modes, or without needing to use array_search/array_splice to make it work.
  • Other extensions can interact with Math through their extension.json by adding or removing modes - this was previously not possible due to how the values are merged.
  • The old format will still work, and will not require repeating defaults in two places in the Math code.