Last modified: 2014-06-24 17:57:55 UTC
Invalid marker: UNIQ7dc1893d72170d41-ref-0000000B-QINU Backtrace: #0 /var/www/vhosts/wecowi.de/httpdocs/includes/parser/StripState.php(66): StripState->addItem('general', 'UNIQ7dc1893d72...', '<ref>NASA: [htt...') #1 /var/www/vhosts/wecowi.de/httpdocs/includes/parser/Parser.php(3906): StripState->addGeneral('UNIQ7dc1893d72...', '<ref>NASA: [htt...') #2 /var/www/vhosts/wecowi.de/httpdocs/includes/parser/Preprocessor_DOM.php(1151): Parser->extensionSubstitution(Array, Object(PPFrame_DOM)) #3 /var/www/vhosts/wecowi.de/httpdocs/includes/parser/Parser.php(4304): PPFrame_DOM->expand(Object(PPNode_DOM), 27) #4 /var/www/vhosts/wecowi.de/httpdocs/includes/parser/Parser.php(1188): Parser->formatHeadings('<div class="thu...', '[[Datei:Sutters...', true) #5 /var/www/vhosts/wecowi.de/httpdocs/includes/parser/Parser.php(385): Parser->internalParse('[[Datei:Sutters...') #6 [internal function]: Parser->parse('[[Datei:Sutters...', Object(Title), Object(ParserOptions), true, true, 134479) #7 /var/www/vhosts/wecowi.de/httpdocs/includes/StubObject.php(79): call_user_func_array(Array, Array) #8 /var/www/vhosts/wecowi.de/httpdocs/includes/StubObject.php(99): StubObject->_call('parse', Array) #9 [internal function]: StubObject->__call('parse', Array) #10 /var/www/vhosts/wecowi.de/httpdocs/includes/content/WikitextContent.php(290): StubObject->parse('[[Datei:Sutters...', Object(Title), Object(ParserOptions), true, true, 134479) #11 /var/www/vhosts/wecowi.de/httpdocs/includes/WikiPage.php(3363): WikitextContent->getParserOutput(Object(Title), 134479, Object(ParserOptions)) #12 /var/www/vhosts/wecowi.de/httpdocs/includes/PoolCounter.php(209): PoolWorkArticleView->doWork() #13 /var/www/vhosts/wecowi.de/httpdocs/includes/Article.php(710): PoolCounterWork->execute() #14 /var/www/vhosts/wecowi.de/httpdocs/includes/actions/ViewAction.php(37): Article->view() #15 /var/www/vhosts/wecowi.de/httpdocs/includes/Wiki.php(429): ViewAction->show() #16 /var/www/vhosts/wecowi.de/httpdocs/includes/Wiki.php(305): MediaWiki->performAction(Object(Article), Object(Title)) #17 /var/www/vhosts/wecowi.de/httpdocs/includes/Wiki.php(555): MediaWiki->performRequest() #18 /var/www/vhosts/wecowi.de/httpdocs/includes/Wiki.php(448): MediaWiki->main() #19 /var/www/vhosts/wecowi.de/httpdocs/index.php(59): MediaWiki->run() #20 {main} Seams to me, that this hast something todo with ref. On another page nowiki-ing ref helped to remove this error.
*** Bug 30738 has been marked as a duplicate of this bug. ***
>Seams to me, that this hast something todo with ref. On another page nowiki-ing >ref helped to remove this error. You are correct. The "ref" part of UNIQ7dc1893d72170d41-ref-0000000B-QINU means that the marker was inserted by the cite extension. I would guess [pure guess] cite extension is maybe conflicting with another extension. The cite does tricky things involving adding state to the parser. Perhaps another extension is also doing something tricky and they're interfering
Okay, choose one :D http://www.wecowi.de/wiki/Spezial:Version
What other extensions were used on that specific page? Do you have a minimal test case (the simplest snippet of page text that would cause the error).
Maybe this could have be Maps oder SemanticMaps Extension. The errors always come together with this Template I took from wikipedia an modified a little bit http://www.wecowi.de/wiki/Vorlage:Coordinate
(In reply to comment #5) > Maybe this could have be Maps oder SemanticMaps Extension. > > The errors always come together with this Template I took from wikipedia an > modified a little bit > http://www.wecowi.de/wiki/Vorlage:Coordinate That's using extensions not enabled on Wikipedia, so I doubt it came from there. However, it does use #explode. String functions somehow messing with markers doesn't sound totally unrealistic. OTOH I would expect it to be the type of extension that messes with the parser and somewhere along the line either makes a new parser instance where the markers get inserted in the wrong instance, or clears the state of the original instance thus removing the marker reference [but that again is pure guess].
The version with #explode I added to make the pages work again. The old version that makes the pages break is now under http://www.wecowi.de/wiki/Vorlage:Coordinate/old_save
Created attachment 11544 [details] headers and payload of a failing POST Added an attachment with the contents of a failing POST from my reproducing browser tab.
The content of attachment 11544 [details] has been deleted by Chad H. <innocentkiller@gmail.com> who provided the following reason: Contains private info (eg: session cookies) The token used to delete this attachment was generated at 2012-12-20 19:25:08 UTC.
This error does not only occur with the Template mentioned above. It seams to me that is occurs somehow randomly. Sometimes a small change, that does not touch the ref eliminates the error or brings it back. This should be fixed soon, IMHO that's a major bug. By the way I have the impression that this error also extremely slows down the server.
I still have that reproducing tab. Do let me know if/how I can help here.
A minimal test case might be helpful if anyone has one.
minimal test case: 1. click Edit on [[m:Grants:index]] 2. add <translate> at the top and </translate> at the bottom of the page. 3. Save and watch it explode.
I tried to build a minimal test, but it's hard to find why and when this error happens with cite. I somehow think that this often happens in connection with SemanticMediaWiki (on my wiki). But this doesn't seem to be the only case when it happens. After deactivating SemanticMediaWiki and all connected Extensions one example that threw an error worked again. I'll report this as a SemanticMediaWiki Bug.
(In reply to DaSch from comment #14) > I tried to build a minimal test, but it's hard to find why and when this > error happens with cite. I somehow think that this often happens in > connection with SemanticMediaWiki (on my wiki). But this doesn't seem to be > the only case when it happens. > After deactivating SemanticMediaWiki and all connected Extensions one > example that threw an error worked again. > I'll report this as a SemanticMediaWiki Bug. Ping on this bug – did you get anywhere with the SMW side of things, or in finding a minimal test case?
(In reply to Asaf Bartov from comment #13) > minimal test case: > > 1. click Edit on [[m:Grants:index]] > > 2. add <translate> at the top and </translate> at the bottom of the page. > > 3. Save and watch it explode. No explosion. https://meta.wikimedia.org/w/index.php?title=Grants%3APEG&diff=8994036&oldid=8817694 ------------------- Just for reference, this bug would probably be caused if any extension calls the parser recursively, which its not supposed to do. In the translate case, it was possibly caused by bug 56226.
(In reply to Bawolff (Brian Wolff) from comment #16) > Just for reference, this bug would probably be caused if any extension calls > the parser recursively, which its not supposed to do. In the translate case, > it was possibly caused by bug 56226. Yeah, both Translate and Cite are very badly-behaved in that regard.
(In reply to James Forrester from comment #17) > (In reply to Bawolff (Brian Wolff) from comment #16) > > Just for reference, this bug would probably be caused if any extension calls > > the parser recursively, which its not supposed to do. In the translate case, > > it was possibly caused by bug 56226. > > Yeah, both Translate and Cite are very badly-behaved in that regard. I'm not aware of Cite ever doing that. I think most of the cases for Translate have been fixed now.
