Last modified: 2010-12-14 09:36:55 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T28318, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 26318 - values in list not shown by EditWithForm
values in list not shown by EditWithForm
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
SemanticForms (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Yaron Koren
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-13 14:19 UTC by Paul Oranje
Modified: 2010-12-14 09:36 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Paul Oranje 2010-12-13 14:19:28 UTC
SF (r78190) does not show existing values of a field that contains multiples values separated by newlines. The template that the field belongs to, does show the values (with #arraymap) and when editing the wikitext with Edit (not with the form) then the existing values are present as well.

The fileld is defined as:
  {{{field
  |involved-experts
  |input type=textarea|autogrow
  |autocomplete on category=Expert
  |list
  |delimiter=\n
  |remote autocompletion
  }}}

In revision r77626 everything still works as expected.
BTW: Revisions r78129 and higher show different types of errors (bad display, wrong values in autocomplete pick list, etc); I've not investigated those errors, but only noticed them while searching for a revision that still worked with my wiki.
Comment 1 Yaron Koren 2010-12-13 15:03:34 UTC
Hi,

Yikes! Thanks for letting me know that. It looks like it was even worse than that - the current value of the field wasn't being set for any textarea that used autocomplete, regardless of the delimiter, and that's been the case for a while. I guess it just wasn't a popular feature... anyway, as far as I know, this is fixed now in SVN.
Comment 2 Paul Oranje 2010-12-14 09:36:28 UTC
As usual, that's quick!
HEAD of trunk now seems to work as intended.
Thanks.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links