Page MenuHomePhabricator

[Regression] 'UNIQ' tokens outputted in front of every heading
Closed, DeclinedPublic


Screenshot of page output

Both after saving as well as in "preview" these tokens show up.

I first encountered this on Thursday and can still reproduce it now on the latest master today (Sunday).





Version: 1.20.x
Severity: blocker


Screen_Shot_2012-07-29_at_1.45.29_PM.png (512×466 px, 48 KB)



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:09 AM
bzimport set Reference to bz38801.
bzimport added a subscriber: Unknown Object (MLST).

Where are you attempting/seeing that?

It' fine in both 1.20wmf7 (enwiki) and 1.20wmf8 (mediawiki) and master (dev wiki)

master on localhost. Vector+WikiEditor extension installed. Created several new pages, edited existing pages and purged ones. All the same effect (see screenshot).

I've seen it on my localhost for almost a week now, pulled from remote several times (on master). Currently at 2ba1b409fef2f6574bae12014b566a9c2c10ff1b.

Chris, could you work out a reliable repro on Beta Labs?

No sign of this behavior on labs in my environment with vector, although pictures are being shown off to the right rather than inline with text and headers.

Uploaded photo via UploadWizard on commons.
Uploaded other photo vi Upload File on enwiki.

Used both photos in Sandbox with Krinkle's example wrapper.

Created attachment 10906
beta labs enwiki Sandbox showing photo display and layout

beta labs enwiki Sandbox showing photo display and layout


Screen_shot_2012-07-30_at_2.23.06_PM.png (609×1 px, 152 KB)

I just deployed latest master on the beta cluster and that fixed the bug, can't reproduce it anymore locally either.

git-bisect to older versions doesn't bring it back either. Appears to be some kind of cache thing maybe.

Could potentially still screw up production.

content hidden as private in Bugzilla

(In reply to comment #8)

Not a blocker for 1.20wmf9

(In reply to comment #7)

Could potentially still screw up production.

Since we can't reproduce it, it shouldn't block deployment. But lets keep it in mind when deploying to do carefully check on It may be a one-way bug in the parser cache that only happens for older pages.

Marking WORKSFORME for now.