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.

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 T150011#2973708, @Legoktm wrote:

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.

In T150011#3077520, @MarkAHershberger wrote:

@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.

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

In T150011#2973708, @Legoktm wrote:

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?

In T150011#3992497, @Physikerwelt wrote:

[..] 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.

Change 334646 abandoned by Physikerwelt:
Allow users to enable or disable rendering modes

Reason:
Gerrit cleanup. Please resubmit, if this patch is still relevant.

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

I occasionally get this issue on my wiki as well. The "fix" I use is to add a space at the end of the latex and save the page, which usually makes it re-render properly.