Sat, Aug 24
We are getting a "TypeError: api.parse is not a function" error: see here.
We removed this from extensions to find out that all software parts using it is now broken for REL1_31 (have not tested REL1_32). The alias is not being recognized at least in REL1_31. @Jdforrester-WMF @Krinkle ?
Mon, Aug 19
The stack trace should be gone since https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/502348/
Fri, Aug 16
The return documentation of Parser::getOptions() is violated. That's not Translate's fault I believe.
Thu, Aug 15
Mon, Aug 5
Thanks for the tip which regrettably leads to nowhere. I have now 3 MB logging but not byte of error logging for this specific issue.
It should take far less than that if you use a strategy similar to binary search. In its simplest form: Disable half of the extensions, check for the issue, if it's there, disable half of that half etc. If the issue goes away, it's in the other half, and go again etc. Should only take 6 or 7 steps at most.
None other than the error group, which handles all PHP notices.
See https://www.mediawiki.org/wiki/Manual:How_to_debug. Specifically, $wgDebugLogGroups['error'] will contain stack traces for errors, warnings and notices from PHP.
Can you "unsinstall" the extensions one by one until the error disappears? Then you probably have the extension which causes the error :)
Does it happen when there are no extensions installed?
@Legoktm FYI Since you are concerned with extension registration ...
Thu, Aug 1
Now yes, this should be fixed, thanks for the report!
Mind you, I just tried to replicate it in general and it looks like... the whole thing is now just totally broken in firefox?
In what way does it "mess up all files"? What is the impact?
Jul 25 2019
Cool. Thanks a ton. You rock!
Jul 24 2019
@cicalese Probably worth doing a 2.0.1 release to also bring translation updates, etc. since the last release in 12.2017?
Similar situation as T228595.
This is now fixed in the master branch of
Jul 21 2019
Jul 18 2019
Which component is the error coming from? A special page? (which one), an API request (which one), etc.
Jul 16 2019
because i already did so ;)
I am stuck here. Gerrit does not allow me to cherry pick the second follow up commit. :(
Out of despair I have now cherry-picked the first change. Probable after this was merged the follow up commit can also be cherry-picked to avoid conflicts. Thanks to all.
Jul 11 2019
Correct. So while it is possible to use php7 syntax, this particular file being a first class entrypoint into mediawiki, possibly should not if it can avoid to do so, out of user friendliness in the error reporting.
Jul 10 2019
I note that this introduced php 7 syntax into the update.php script.
Jul 9 2019
I can't replicate this on the beta cluster or locally.
Jul 8 2019
Jul 6 2019
This one is a real spammer for the error logging.
Jul 4 2019
Let's put it like this: "User created page with UploadWizard" is a non-information which does not need to be in there at all.
Jul 3 2019
Triaging this as low is a bit discouraging given that the wrong locale completely messes up all files on a wiki running MW 1.30 and later at least to my experience. Anyways thumbs up for a fix.
Jul 2 2019
Thanks a lot! This specific error no longer appears. I have removed the respective notes from the wiki.
Anything else left to do here?
Jul 1 2019
@Yaron_Koren You are welcome. I just checked out master but the issue still persists.
Just tested this. This is utterly cool. Thanks a lot!
Jun 30 2019
@Yaron_Koren FYI Not sure if you get to see this by default.
Jun 29 2019
Jun 27 2019
On the other hand we are talking about a mobile skin ... Still this approach may be cool too. I leave the decision to you.
Now coming with https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/HostStats/+/519399/. I just removed the initial settings for everyone to choose whatever they like from the start. Moreover a less breaking thus preferable approach.
Jun 19 2019
What a shame. This was the last extension allowing to edit an account in a sane way.
Thanks a ton for working on this! Much appreciated. I just updated REL1_33 and now things work great again for VisualEditor.
Jun 17 2019
I assume rebuildData.php will do this? What other steps should be handled?
Jun 15 2019
Just a note. I believe this task is still a blocker for the MW 1.33 release. Without fixing this it does not make any sense to use MediaWiki 1.33. I now have a test wiki without VisualEditor and MobileFrontend. For a test wiki this is ok but as soon as people upgrade to Mw 1.33 the reports will roll in. Lucky us, MobileFrontend is not bundled for whatever reason.
Jun 14 2019
Cool, great to read!
Jun 13 2019
@Legoktm Thanks a lot for your explanation and advice!!! I authored a new version since this is breaking.
@Samwilson Hmm, interesting that it does not work with your setup, have not checked the version of UserMerge though, however when using REL it works until MW 1.32 as this log shows. Have not tested with MW 1.33 yet.
No worries. The info is on Special:Version.
@StevenCrossin Please always also note the versions of PHP, MySQL, MW and UserMerge you are using. Otherwise is is pretty hard to spot the issue and why it occurs.
Jun 12 2019
@RazeSoldier Thanks. Did not see that.
Added projects as done in T141400
Thank you for the information that helped resolving the issue. Note that this does not just affect SMW as noted. In the end the change was first noticed there.
Well yeah. However setting up cronjobs to work on the miser mode pages is not complicated.
Jun 11 2019
@MarkAHershberger Thanks a ton!!! I could have come up with this earlier, I believe. :|
Jun 10 2019
Jun 8 2019
Do you have a link to this documentation handy?
@Anomie I believe you authored the respective changes for core. Thus pinging you here.