Page MenuHomePhabricator

Change some TemplateData fields to allow multiple lines
Open, Needs TriagePublic

Description

While discussing T263533: TemplateData editor allow text input fields to expand/autosize we realized that it probably would make sense to allow adding new lines for certain fields in the TemplateData editor.

Points taken from T263533#6814478

  • Name and aliases: Technically, parameter names (and aliases, which are just alternative parameter names) are actually allowed to contain newline characters. But this is really, really strange. I can't remember ever seeing this in a real-life template.
  • Label: While it's certainly possible to allow labels to contain line breaks, it feels odd for a label.
  • Description: Here supporting line breaks would possibly make sense. However, as of now line breaks are never rendered as such, but the description is always collased to a single line with spaces.
  • Autovalue: Line breaks work just fine. I actually suggest to officially mark this field with multiline: true, even if this should rarely be needed.
  • Default: It's probably rare. But when you think of the default as a value that could as well be entered by the user, it should accept newlines the moment the type of the field allows newlines (e.g. "string"). However, this heavily depends on how the default is rendered later. At the moment, it's a single collapsed line. This is actually a bug, as this field is currently the only one that's marked as being multiline – but it's never rendered as multiline.
  • Example: Probably similar to above.

Event Timeline

@awight's answer in the thread taken from T263533#6819061

However, I suggest to split the discussion which field should allow line breaks off to a separate task. For the purpose of this task let's stick to the current behavior and not allow line breaks in these fields.

+1, let's disallow line breaks for name, aliases, and label as suggested. I would allow for the other fields mentioned, good idea to start with disallowing and selectively allow in follow-up work.

It might take multiple levels of protection to catch newlines, for example blocking the enter key as mentioned, explicit validation, and stripping newlines whenever sanitizing user-generated input such as parsing from article content. In the Template Data dialog, it would be possible to also validate against newlines and show an error as for any other invalid value.

+1 to render vertical whitespace. Let's get this for free by supporting wikitext+html property values for the , with its known whitespace handling.

I can verify that it's already broken syntax, that it seems to be impossible to create a template invocation with a newline in the template name so there's a solid reason to disallow. I haven't checked the other fields, but seems safe to assume the same.

Sample text:

{{foo
bar}}
{{foobar}} # for comparison
  • Parser doesn't recognize this a template when viewing the page,

image.png (68×149 px, 3 KB)

  • Source editor shows a problem,

image.png (117×137 px, 2 KB)

  • Visual Editor doesn't show as a template either,

image.png (69×143 px, 3 KB)

Don't add validation to the TemplateData parser yet, it has a really nasty way of preventing the editor from saving a page (anathema to how saving is supposed to work), but without displaying any visible errors. See T258790.