Page MenuHomePhabricator

TemplateData: TemplateDataGenerator should roundtrip unexpected JSON values
Closed, ResolvedPublic

Description

This editor replaces multi-language InterfaceText ([[mw:Extension:TemplateData#InterfaceText]]) by "[object Object]"…


Version: master
Severity: normal

Details

Reference
bz60089

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 2:56 AM
bzimport set Reference to bz60089.

Making bug more generic. If it is too generic (e.g. requires more than one good commit to fix), feel free to undo and file a separate one for the general round-tripping issue.

Change 133944 had a related patch set uploaded by Jforrester:
Block object descriptions from edit

https://gerrit.wikimedia.org/r/133944

Change 133944 merged by jenkins-bot:
Block object descriptions from edit

https://gerrit.wikimedia.org/r/133944

Now fixed for descriptions, but not (I think?) in general.

(In reply to James Forrester from comment #4)

Now fixed for descriptions, but not (I think?) in general.

(In reply to Gerrit Notification Bot from comment #3)

Change 133944 merged by jenkins-bot:
Block object descriptions from edit

https://gerrit.wikimedia.org/r/133944

This commit originally ensured 'description' properties that contain objects are left untouched.

It was changed in later patch versions to ensure all properties containing non-string values (and non-arrays for 'aliases' properties) are left untouched.

This isn't a very scalable solution (we already have 4 different value types, ideally we'd map them strictly to the property name as validation instead of compressed in a catch-all if/else statement like this).

The only property it currently may not roundtrip properly are the boolean properties ('required' is forced into a boolean regardless of its value, 'deprecated' is untouched, usually..?). Though this is not as much of an issue since we already validate these when saving the page on the server-side. So these would only get messed up when the user edits them in the wikitext area, then proceeds to click "Manage template data". A valid use case (the editor should not rely on server-side validation after saving), but low priority.

OK, in that case I'm marking this bug closed (but we should follow-up with the wider tech debt, indeed).