Page MenuHomePhabricator

Special:Contributors throws "MediaWiki internal error" when used in a Page Form template
Open, Needs TriagePublic


In my main namespace I use a Page Form template that contains {{Special:Contributors/{{FULLPAGENAME}}}}.

Since I updated my wikis to MediaWiki 1.27.4, Page Forms 4.2 and Contributors 2.0 I get the following error when saving/editing "pages of my main namespace" with Page Forms:

MediaWiki internal error

Original exception: [ef347a42dff9110d82bfe7e7] [no req] DBUnexpectedError from line 2661 of /mediawiki/includes/db/Database.php: Got COMMIT while atomic sections
WikiPage::doModify are still open
#0 /mediawiki/includes/db/loadbalancer/LoadBalancer.php(1055): DatabaseBase->commit(string, string)
#1 [internal function]: LoadBalancer->commitMasterChanges(string)
#2 /mediawiki/includes/db/loadbalancer/LBFactory.php(206): call_user_func_array(array, array)
#3 [internal function]: LBFactory->{closure}(LoadBalancer, string, array)
#4 /mediawiki/includes/db/loadbalancer/LBFactorySimple.php(154): call_user_func_array(Closure, array)
#5 /mediawiki/includes/db/loadbalancer/LBFactory.php(209): LBFactorySimple->forEachLB(Closure, array)
#6 /mediawiki/includes/db/loadbalancer/LBFactory.php(250): LBFactory->forEachLBCallMethod(string, array)
#7 /mediawiki/includes/MediaWiki.php(551): LBFactory->commitMasterChanges(string, array)
#8 /mediawiki/includes/MediaWiki.php(529): MediaWiki::preOutputCommit(RequestContext)
#9 /mediawiki/includes/MediaWiki.php(740): MediaWiki->doPreOutputCommit()
#10 /mediawiki/includes/MediaWiki.php(509): MediaWiki->main()
#11 /mediawiki/index.php(43): MediaWiki->run()
#12 {main}

Exception caught inside exception handler: [ef347a42dff9110d82bfe7e7] [no req] MWException from line 166 of /mediawiki/includes/FauxRequest.php: Request URL not set
#0 /mediawiki/includes/skins/SkinTemplate.php(1097): FauxRequest->getRequestURL()
#1 /mediawiki/includes/skins/SkinTemplate.php(473): SkinTemplate->buildContentNavigationUrls()
#2 /mediawiki/includes/skins/SkinTemplate.php(246): SkinTemplate->prepareQuickTemplate(OutputPage)
#3 /mediawiki/includes/OutputPage.php(2335): SkinTemplate->outputPage()
#4 /mediawiki/includes/exception/MWException.php(206): OutputPage->output()
#5 /mediawiki/includes/exception/MWException.php(246): MWException->reportHTML()
#6 /mediawiki/includes/exception/MWExceptionHandler.php(69): MWException->report()
#7 /mediawiki/includes/exception/MWExceptionHandler.php(180): MWExceptionHandler::report(DBUnexpectedError)
#8 /mediawiki/includes/MediaWiki.php(518): MWExceptionHandler::handleException(DBUnexpectedError)
#9 /mediawiki/index.php(43): MediaWiki->run()
#10 {main}

Interestingly the error only appears if the free text input of my page contains at least one return. As long as there is no return, I can save/edit the page without error.

If I "source edit" the page, the error is not thrown. It only happens in combination with "edit with form".

I tried both the Contributors version for REL_1.27 and the master one. Both throw the error.

Event Timeline

Stefahn created this task.Dec 2 2017, 9:58 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 2 2017, 9:58 PM

That is very specific! Are you sure that this was not happening before the upgrade? And if indeed it was the upgrade that caused it, do you remember what versions you were running before?

Bawolff added a comment.EditedDec 4 2017, 3:56 PM

Hmm, the FauxRequest thing is weird. At first guess, I'd guess the exception happens from within something that's calling the API internally. (That's not true as api.php does not call MediaWiki->run() )

Are you using any extensions that use the NewRevisionFromEditComplete hook? Other possibilities might be an extension that does fancy things with user permissions.

Could you try and disable all other extensions to make sure it really is just these two extensions?

@Yaron_Koren: Yes, I am sure that this didn't happen before. Versions I had before (still have the wiki as a backup) : MW 1.19.16, Contributors 1.0.1 beta, Semantic Forms 2.5.3.

@Bawolff: I checked and yes, I use SMW. I turned off SMW for testing purposes and the error disappeared (this is not a solution though since my wiki depends on SMW).

@all: I did some testing with older versions of Contributors. I found that the error does not occur with Contributors 1.1.0 from 2014-06-13 but the error occurs with Contributors 1.5.0 from 2014-10-07. Somewhere in between must be a commit that's causing the error...

Bawolff added a subscriber: Kghbln.Dec 4 2017, 4:58 PM

@Bawolff: I checked and yes, I use SMW. I turned off SMW for testing purposes and the error disappeared (this is not a solution though since my wiki depends on SMW).

Indeed, but it does give us new people to blame ;)

AFAIK, SMW does not use phabricator to track bugs, you may want to open a bug with whatever they use.

This just got more specific! It requires the presence of three extensions, plus a specific syntax in the template, and a newline in the free text.

@Stefahn - your narrowing down of the Contributors version looks very helpful. There weren't that many major changes to the code between those two dates - looking at the code history, these look like the two most likely ones causing the problem:

And my guess is that it's the latter, i.e. right on October 7. Would it be possible for you to do some further checks to see?

Stefahn added a subscriber: tosfos.Dec 5 2017, 2:45 PM

@Yaron_Koren: Your guess was right. Version 1.4.0 from 2014-10-01 works, and the next version 1.5.0 throws the error.

So the issue is indeed within Who is familiar with the code - can you help @tosfos ?

@Stefahn - I looked through the change again, and my guess is that the problem is somehow due to the parser function that was added in that change. If you're on a version of Contributors that has that error, could you try removing the line from either Contributors.php or extension.json - depending on what version you're using - that adds 'ContributorsHooks::setupParserFunction' to the 'ParserFirstCallInit' hook, and seeing if that makes the error go away?

@Yaron_Koren : Thanks for your guess. I commented out line 40 in Contributors.php (version 1.5.0), but the error still persists.
I also tried commenting out the whole function setupParserFunction in Contributors.hooks.php, but no luck either.

What would be your next guess?

Alright. Looking through the patch again, my next guess is that the problem is due to the removal and replacement of the parseParameters() function in the file - which is now the file /includes/SpecialContributors.php. Could you try changing the setup() function to its old state, and re-adding the function parseParameters() to that same file?

That didn't help but I found the culprit at another place. If I edit in the REL 1.27 branch like the following the error disappears:

This change was originally made from 1.4.0 to 1.5.0 and I now reverted it. Can somebody please verify that this might be the problem, generate a patch and submit it (I'm not familiar with the the Gerrit process) ?

I saw that the master version doesn't use the unset thing. So hopefully in newer versions than MW 1.27 this error doesn't appear at all. The proposed patch is for 1.27 only.

@Stefahn - great find! I did think that unset() call looked a little suspicious.

This call in fact still is in the master version - you can see it here:;8be7147e9e874f4b6ba1b88d8e052f0e0d1af836$36

( was renamed at some point to SpecialContributors.php.)

@tosfos - what do you think about this line getting commented out?

@Yaron_Koren: Thanks for the info.
I did the change (shown in the screenshot) to the master version of SpecialContributors.php. On my 1.27 install this made the error disappear.

Thus I suggest to make the change in all current branches of the extension.

@Bawolff: You patched the extension recently. Can you jump in if @tosfos doesn't reply?

Change 403551 had a related patch set uploaded (by Krinkle; owner: Yaron Koren):
[mediawiki/extensions/Contributors@master] Fix for 2270fb67891f - remove unset() call

Change 403551 merged by Yaron Koren:
[mediawiki/extensions/Contributors@master] Fix for 2270fb67891f - remove unset() call

Okay, I decided to "be bold" and checked in the change. (Plus, I'm the main maintainer of this extension, according to its page.) That doesn't fix any of the previous branches, though.

Thanks, at least master is fixed now :)