• 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

dasch wrote:

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

dasch wrote:

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

dasch wrote:

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
headers and payload of a failing POST

Added an attachment with the contents of a failing POST from my reproducing browser tab.

attachment full_request_with_payload.txt ignored as obsolete

The content of attachment 11544 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.

dasch wrote:

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.

dasch wrote:

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.

Minimal testcase in T44637#477943 could not be reproduced in T44637#477991 and it is unclear if and which other extensions come into play here:

In T44637#477978, @Jdforrester-WMF wrote:

did you get anywhere with the SMW side of things, or in finding a minimal test case?

Hence lowering task priority and setting task status to stalled as no testcase has been identified. Plus:

In T44637#478013, @Bawolff wrote:

I'm not aware of Cite ever doing that.