I encountered this error after importing an xml file to my wiki, when trying to access the imported pages. Granted, it wasn't an exported xml file, I had generated it to quickly populate a number of pages. Sample XML was
<mediawiki xmlns="http://www.mediawiki.org/xml/export-0.11/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mediawiki.org/xml/export-0.11/ http://www.mediawiki.org/xml/export-0.11.xsd" version="0.11" xml:lang="en">
<page><title>cds_links_parameter</title><revision><text>{{Accuro table|table_name=cds_links_parameter}} [[Category:Accuro table from import]] <!-- remove once edited --></text></revision></page>
<page><title>message_notes</title><revision><text>{{Accuro table|table_name=message_notes}} [[Category:Accuro table from import]] <!-- remove once edited --></text></revision></page>
...
<mediawiki>
Pages didn't show up in recent changes and when I try to go to one of the imported pages via search I get this error.
Interestingly, I did not get the error when importing a smaller number of pages with the same xml.
Another possibly related thing... I tried to "help the import along" by running the runJobs.php manually a few times...
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 22 2024
Apr 25 2023
I just checked this form and it no longer gives the error, so you are right, fixed. Thanks!
Dec 8 2022
According to https://www.mediawiki.org/wiki/Release_notes/1.38 preventClickJacking should be replaced with setPreventClickjacking
This appears to happen when used together with extension TabberNeue; when I put autoedit on a page by itself I don't get this error.
GlobalFunctions.php line 769 calls MWDebug::deprecated() ParserOutput.php line 2004 calls wfDeprecated() PF_AutoEdit.php line 27 calls ParserOutput->preventClickjacking() Parser.php line 3442 calls PFAutoEdit::run() Parser.php line 3125 calls Parser->callParserFunction() PPFrame_Hash.php line 276 calls Parser->braceSubstitution() Parser.php line 1606 calls PPFrame_Hash->expand() Parser.php line 881 calls Parser->internalParse() Tabber.php line 91 calls Parser->recursiveTagParse() Tabber.php line 62 calls MediaWiki\Extension\TabberNeue\Tabber::buildTab() Tabber.php line 33 calls MediaWiki\Extension\TabberNeue\Tabber::render() Parser.php line 4022 calls MediaWiki\Extension\TabberNeue\Tabber::parserHook() PPFrame_Hash.php line 354 calls Parser->extensionSubstitution() PPTemplateFrame_Hash.php line 97 calls PPFrame_Hash->expand() Parser.php line 3313 calls PPTemplateFrame_Hash->cachedExpand() PPFrame_Hash.php line 276 calls Parser->braceSubstitution() Parser.php line 2954 calls PPFrame_Hash->expand() Parser.php line 1609 calls Parser->replaceVariables() Parser.php line 723 calls Parser->internalParse() WikitextContentHandler.php line 301 calls Parser->parse() ContentHandler.php line 1721 calls WikitextContentHandler->fillParserOutput() ContentRenderer.php line 47 calls ContentHandler->getParserOutput() RenderedRevision.php line 266 calls MediaWiki\Content\Renderer\ContentRenderer->getParserOutput() RenderedRevision.php line 237 calls MediaWiki\Revision\RenderedRevision->getSlotParserOutputUncached() RevisionRenderer.php line 221 calls MediaWiki\Revision\RenderedRevision->getSlotParserOutput() RevisionRenderer.php line 158 calls MediaWiki\Revision\RevisionRenderer->combineSlotOutput() - line - calls MediaWiki\Revision\RevisionRenderer->MediaWiki\Revision\{closure}() RenderedRevision.php line 199 calls call_user_func() PoolWorkArticleView.php line 91 calls MediaWiki\Revision\RenderedRevision->getRevisionParserOutput() PoolWorkArticleViewCurrent.php line 97 calls PoolWorkArticleView->renderRevision() PoolCounterWork.php line 162 calls PoolWorkArticleViewCurrent->doWork() ParserOutputAccess.php line 299 calls PoolCounterWork->execute() Article.php line 714 calls MediaWiki\Page\ParserOutputAccess->getParserOutput() Article.php line 528 calls Article->generateContentOutput() ViewAction.php line 78 calls Article->view() MediaWiki.php line 542 calls ViewAction->show() MediaWiki.php line 322 calls MediaWiki->performAction() MediaWiki.php line 904 calls MediaWiki->performRequest() MediaWiki.php line 562 calls MediaWiki->main() index.php line 50 calls MediaWiki->run() index.php line 46 calls wfIndexMain()
Jul 25 2022
@Yaron_Koren - I back then removed the details about which wiki this was about and I don't remember, and I can't replicate this now either. It's probably fair to close this issue.
Feb 14 2022
Thanks, @Aklapper!
mediawiki:Log must be a built-in thing since I didn't add it to either wiki. I thought something like that might be going on, but didn't even know how I would search for that.
So :Log allows me to overrule this for the link part, but how would I overrule this for the displayed text?
Interestingly the sidebar also doesn't accept commenting out with
<!-- xxx -->
Jan 19 2022
It solved my problem, and will solve some other bad inputs, but haven't necessarily thought about all bad input possiblilities, and I don't know how to set up tests to validate.
Dec 24 2021
I just tried this on a different wiki I have that isn't alpha, and get essentially the same error. orphans.php works fine, actually doesn't find anything on that wiki, but if I run it with --fix it crashes.
MediaWiki 1.37.1
PHP 7.4.25 (cgi-fcgi)
MySQL 8.0.25-0ubuntu0.20.04.1
Dec 23 2021
Dec 19 2021
Dec 18 2021
Added to Gerrit as https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Cargo/+/748231
Dec 17 2021
Dec 16 2021
I added some console.logs to ext.cargo.dagre.js and to dagre-d3.js,. There is a failure in dagre-d3.js because it chokes on a bad value it gets from one of my _parentTables entries, ie the wrong _localField= x
Dec 12 2021
I have reviewed and fixed the template that broke it, and it really was doing something odd: storing a value in Cargo that it retrieves via SMW ask. Legacy content and quick and dirty fix by the look of it, with emphasis on dirty. So, not good user practice for sure, but it could have failed more gracefully with a better error message, and possibly with continuing on with the rest of the records after the failed one?
I have had the problem you describe before, and if a query breaks where I can see it I know to use double-quotes in a scenario like this. However, this is a query in a template that runs on 100s of pages, and I had not seen the one on which it breaks. The thing I am flagging is that it breaks a maintenance script. I get it that the script can't process this page, but it might have been better if it managed to fail out of this page and continue with others?
It also would be nice if there was a way to see if anything currently breaks Cargo on a given wiki, although that might be a big-ish ask. I suppose it would have to try to run everything on every page and report back if there are errors. Something like SMWs "Constraint Error List" and "Processing Error List".
Dec 11 2021
I have this:
Dec 10 2021
Here is what data-table-schemas actually contains, in case that helps:
Nov 24 2021
Jul 21 2021
You are absolutely right. I finally got back to this, and for me it appears to be Semantic Mediawiki that's causing these. The errors stopped for me when I disabled Semantic Mediawiki. I have raised a ticket with them: https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/5030
Jun 28 2021
For solution for anyone else who runs into this: running the following sql query to add the mw interwiki back in solved the direct problem for me:
Jun 23 2021
Will this ticket reach the people who would make such decisions about how these links are set up inside interface pages? Or do I need to do something else to flag this?
I have a MediaWiki namespace, but no MW one.
This adds about 500MB of noise to the logs of my moderately busy wikis in a 2 week period. It persists under 1.36.1, had hoped that would fix it.
Jun 10 2021
Others are mentioning similar errors, e.g.
https://www.mediawiki.org/wiki/Topic:W9v17dxvvlrkcotf
https://www.mediawiki.org/wiki/Topic:Waeqw3a9x1s74h2d
Jun 24 2020
I have given up on a fix for this and instead set up a cron job that deletes the offending lines with a "Delete FROM recentchanges where not (rc_title > ""). This fixes recent changes for me on that wiki.
Feb 4 2020
You are correct: "SELECT * FROM recentchanges where not (rc_title > "")" gives me 312 records. The first 25 all have
rc_source = mw.log
rc_log_type = cargo
rc_log_create = recreatetable
Jan 30 2020
Any idea what might be causing this? It only happens on this one out of my 5 wikis.
Dec 22 2019
I checked "Use non-JavaScript interface" in preferences and then I was able to get the stack trace:
$wgShowExceptionDetails is set to true. I have also taken all of those settings out of that convenience loop I copy pasted above with my debug settings in my localsettings.php, just to be sure. Still the same. I can get the debug info with the eventual exception displayed on the screen, but not the stack trace.
Is there any second place I should be able to pick up or send the stack trace?
Dec 21 2019
Ah here we go:
With $wgShowExceptionDetails = true I still only get the "Internal error" on page. Something else flashes briefly when I first open the page but then gets hidden. Here is what I do in Localsettings to turn on debugging:
I can't make sense of the error, but: we use
Ah. We run an old wiki. Thanks, will fix that.
Sorry, I just searched phabricator for this now, and it looks like there have been some changes. Reading those now to see if this ticket will still be required.
Sep 20 2019
@Aklapper : I have attempted to revert https://phabricator.wikimedia.org/T225473 from "No PF" to backlog the same way; hope I got it right.
Attempting to move this back to backlog from "No PF" as per https://phabricator.wikimedia.org/T225475 since this ticket had been moved to No PF at the same time.
Sep 17 2019
@Aklapper - oi, you are right of course, my bad. At least that mystery is solved.
I still don't understand why this was categorized as not a PF issue, though.
Sep 10 2019
Hey Ahmad, I am a bit puzzled by two things... why did you move this to Not PF, it is an error that happens when using forms functionality? And, how did you manage to do it with a timestamp that predates me posting this bug?
Hey Ahmad, I am a bit puzzled by two things... why did you move this to Not PF without explanations? And, how did you manage to do it with a timestamp that predates me posting this bug?
Jun 12 2019
Jun 11 2019
May 14 2019
May 10 2019
Apr 29 2019
Apr 28 2019
Apr 16 2019
Thanks for the quick turn-around Yaron. I did a git update (now 4.5 (23baaf7) 2019-04-15T20:31:43) and am not getting those errors in my log any longer. How does this work on here now, do I set this to resolved or fixed or do you?
Apr 15 2019
Feb 24 2019
@ashley: You are right, my update process was wrong and retained old extensions for those that come with mediawiki. Once I replaced Gadget with the newest version this worked.
@Aklapper: I think it is related to Monobook because it works in Vector. I usually have vector disabled on this wiki, but enabled it just to test. Config change to vector, works. Gadget Hotcat enabled, works. Config change to Monobook, crashes. Disable gadget in Localsettings, works again. Disable hotcat in Gadget settings, and then enable monobook again, works.
Feb 23 2019
Dec 23 2018
https://wikiapiary.com/wiki/CCMDB_Wiki still says it's marked inactive.
https://wikiapiary.com/wiki/University_of_Manitoba_Internal_Medicine_Wiki was partly updated (EG usage general is updated, but usage semantic is not...)
Dec 13 2018
Oct 29 2018
"Last audited on 2017/08/23 09:30:11 PM" is still old, though.
Hi, not sure if someone changed something, but the Critical Care and Medicine Database Wiki has now updated data. The UmIntMed one still doesn't.
Oct 25 2018
Sep 27 2018
I copied down a clean version of ReplaceText and now it works. Not sure what else I have to do to close this ticket.
Sep 26 2018
Of course that was with all sorts of debugging enabled, I will disable that again now.
Sep 13 2018
RE: Rebuildall.php, we use SMW with out mediawiki, and between SMW and MW we used to have some stuff not update automatically. The problems and tweaks to its solution have been around our instances for years, so I am afraid I can't remember why specifically we run rebuildall. The problems we were encountering were things like making sure that SMW driven content gets updated, wanted tables and wanted categories and stuff get update, and similar things. I have done a better job logging our changes in more recent years, but I think adding rebuildall pre-dates that.
https://www.mediawiki.org/wiki/Topic:Tu9jxpne4mvgsl36
might have been it.
Sorry about the delay. below are the permissions from the localsettings.php. There are a lot of them, some are likely not necesary. We used to run this instance as a login-to-view/edit wiki, and then changed it to a public one some time ago, but I never reviewed which of these could just go. CCMDBlegit is the group you need to be part of to edit. It's a leftover from when we also needed to make holders of former accounts unable to view content.
Aug 21 2018
Are you talking about a section of the local settings?
- Original message --------From: kaldari <no-reply@phabricator.wikimedia.org> Date: 2018-08-21 13:52 (GMT-06:00) To: ttenbergen@gmail.com Subject: [Maniphest] [Commented On] T199744: Recent changes wrongly show as "b" for bot after update
kaldari added a comment.
Agree with Izno: what I need from watchlist/RC is a list of things that have changed and an easy way to review them. If I want fine-grained information I can look a the history of the page. For my use case, that would work. Are there actually use cases that need the detail in that part of the user interface?
Jul 23 2018
I would find RCs without the day groupings very helpful as well. As described in [[Topic on Talk:Edit Review Improvements/New filters for edit review]], I use RC in several private wikis, and I need to review all edits made. I try to do this weekly but life happens. If a page is getting a lot of reviews it clutters up the RC listing. Worse, it is easy to miss the fact that I am not looking at the latest version/diff, and start editing an intermediate version. I ''know'' that I need to not do that, and how to work around it, but it is really easy to miss when you are on a go. And, that's me, it's even harder to get our less technical users to understand this. So, yes, for us at least an option to say "show only latest diff" that would compare it to the last time a logged-in user viewed the page would be great!
Jul 18 2018
Jul 17 2018
Jul 16 2018
Jun 28 2018
May 4 2017
Can't access this from home either, so not a proxy issue. We are using Mediawiki 1.28.1 - is AutoBrowser compatible with that? Anyone else having this problem?
May 3 2017
Apr 12 2017
Actually, mediawiki is still at 1.28