[3.0] Theme split (wave 4, part 12) — give the poll option editor one implementation

[albertlast]

Description

Part of the #7933 split (wave 4, part 12). Posting area, second of the two
slices, independent of #9428.

Post.template.php and Poll.template.php each generated their own near
identical copy of addPollOption() into the page, both seeded from a context
value the other one sets differently:

var pollOptionId = ', Utils::$context['last_choice_id'], ';

Post never sets last_choice_id when the poll is new. So the new poll
form at ?action=post;board=N;poll emits

var pollOptionId = ;

which is a syntax error, and the browser discards the whole first <script>
block with it:

Uncaught SyntaxError: Unexpected token ';'

Two things break as a result. Add Option does nothing, because
addPollOption was never defined. And the message icon preview stops
updating, because icon_urls is declared in that same block and
script.js reads it to swap the image. smf_log_errors has been collecting
Undefined array key "last_choice_id" for the same page.

The add/edit poll form at ?action=editpoll is not affected — PollEdit does
set the value — which is presumably why this has gone unnoticed.

What changes

Both copies now come from Themes/default/scripts/post.js, loaded only where
there is a poll to edit. The option list carries the "Add Option" wording and
the numbered label as data attributes, so nothing is generated into the page any
more, and the button is written from script next to the list, which gets a
javascript: link out of the markup. pollOptions() moves here out of
script.js, which every page loads and only this form calls.

The new field copies its id and name from the last one with the trailing number
bumped, rather than building either from scratch. The two forms disagree about
what those look like — Poll::format() hands out ids that already begin with
options- and both templates prefix them again, giving
name="options[options-3]" — and following whatever the server just rendered
keeps the added option in the same shape as its neighbours without settling that
question here. It is worth its own look; on release-3.0 the edit poll form
adds options[5] next to options[options-4], so the two disagree today.

Testing

Both forms, on this branch: options add and number correctly and produce no
console errors, icon_urls is defined again, and the results-after-expiry radio
still follows the expiry field, including falling back to "after voting" when it
was selected and the expiry is cleared. A poll submitted from the posting form
with an option added by the button stores all three choices.

Issues References (Fixes|Related|Closes)

Related to #7933

[live627]

Shouldn't it be poll.js since it only concerns polls?

[albertlast]

Agreed, and it was worse than just the name — PollEdit loads it too, so one of the two callers is not the posting form at all. Renamed to poll.js, handle smf_post → smf_poll, and the file comment now says what it is rather than "the bits of the posting form that...".

post.js came straight from the theme branch, where the name looks ahead to a general posting script. Nothing there fills it out either — its copy holds the same two poll functions — so there is nothing lost by naming it for what it does now.

Re-checked both forms after the rename: options add and number correctly on the new poll form and the add/edit poll form, the results-after-expiry radio still follows the expiry field, icon_urls is still defined, and no console errors.