[3.0] Give every poll choice the same id, whichever code built it - #9434
Open
albertlast wants to merge 1 commit into
Open
[3.0] Give every poll choice the same id, whichever code built it#9434albertlast wants to merge 1 commit into
albertlast wants to merge 1 commit into
Conversation
Poll::format() handed out ids that already began with "options-", and the two editing templates prefixed them again, so the fields came out as id="options-options-3" name="options[options-3]". Post.php builds Utils::$context['choices'] itself when the posting form comes back from a preview or an error, and it has always used the plain number. So the same form named its fields options[options-0] on the way in and options[0] on the way back, and the option the JS appends never matched either. Nothing broke, because both save paths run array_values() over the submitted options and renumber them by position. It just made the markup impossible to read. Poll::format() now gives the number and leaves the prefix to whoever renders it, which is what Post.php already assumed. Display.template.php and the two SSI poll functions label the vote buttons, whose ids come from format() as well, so they say options- themselves now. Signed-off-by: Mathias Alberts <mathiaspapealbert@hotmail.com> Signed-off-by: albertlast <mathiaspapealbert@hotmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Poll::format()handed out choice ids that already began withoptions-, and bothPost.template.phpandPoll.template.phpprefixed them again. The editing formstherefore came out as:
There is a second builder. When the posting form comes back from a preview or a
validation error,
Post.phpfillsUtils::$context['choices']itself, and it has alwaysused the plain number. So the same form named its fields
options[options-0]on firstload and
options[0]after a preview, and the option the "Add option" script appendsmatched neither.
On
?action=post;board=1;pollbefore:options-options-0options-0options[options-0]options[0]Nothing actually broke:
Poll::create()andPollEdit2both runarray_values()over$_POST['options']and renumber the choices by position, so the keys are thrown away.It only made the markup unreadable and the two shapes impossible to reconcile.
Poll::format()now returns the number and leaves the prefix to whoever renders it,which is what
Post.phpalready assumed. The three places that label a vote buttongain the prefix, since those ids come from
format()too —Display.template.phpandthe two poll functions in
ServerSideIncludes.php.Checked on all four pages that render poll fields, before and after: the new-poll form,
the same form redisplayed after a preview,
?action=editpollon an existing poll, andthe voting form on the topic. Every
for=now resolves to an element, and the twoposting-form paths agree.
Issues References (Fixes|Related|Closes)
n/a