Allow comment_form() to add attributes to <form> tag

[psbook]

The standard method to allow Google Analytics to track comment submissions as a 'goal' is to add a piece of JavaScript code wrapped in an 'onsumbit' attribute:
​http://www.optimisationbeacon.com/analytics/track-blog-comments-in-google-analytics/
​http://code.google.com/apis/analytics/docs/tracking/eventTrackerGuide.html

We want something like the following:

<form action="http://www.example.com/wp-comments-post.php" method="post" id="commentform" onsubmit="_gaq.push(['_trackEvent', 'Comments', 'Submit', 'POST TITLE']);">

However the current arguments submitted to comment_form() do not provide for adding attributes to <form>
​http://codex.wordpress.org/Function_Reference/comment_form

I was forced to perform a workaround in which the onsubmit code was inserted by JavaScript on the fly at runtime.

So this is request to alter comment_form() such that arguments accepted provide for 'onsubmit' or other custom attributes to be appended on the <form> tag.

[jkudish]

The proposed/attached patch adds a 'form_attributes' argument to the $args for comment_form, it also adds 2 new filters, one for the attributes (which are passed as a key/value array) and one for the entire form element as it gets output.

[jkudish]

initial path had syntax errors, now fixed

[SergeyBiryukov]

Version number indicates when the bug was initially introduced/reported.

[chriscct7]

Needs a refresh because of the HTML class added in #23851

[swissspidy]

Why is onsubmit="" needed for this? Can't that be done in a separate JS file or inline jS?

[peterwilsoncc]

Replying to swissspidy:

Why is onsubmit="" needed for this? Can't that be done in a separate JS file or inline jS?

For the use case described, yes using seperate JS would be optimal.

For other attributes, class, aria, etc this would be handy. FWIW, the filtering techniques of allowing ​all attributes to be filtered used for menu items appeals to me.

[stevegrunwell]

Refresh for WordPress 4.4 with addition of unit tests

[stevegrunwell]

.diff version of the .patch file just submitted.

[stevegrunwell]

Just submitted a refresh for WordPress 4.4 and up. Rather than introducing a new filter (as was done earlier), I added support for the "attributes" key within the set of defaults passed to the comment_form_defaults filter. Original attributes (action, method, id, and class) are left unfiltered, so this new option is really for additional attributes that should be added to the <form> element.

[swissspidy]

I like the approach of the new patch. Some notes:

• The closure inside test_extra_comment_form_attributes needs to go into a new method. Closures aren't supported in PHP 5.2.
• The new attributes argument needs to be documented in the DocBlock for comment_form()
• attributes sounds misleading. What are these attributes for? Since there's class_form and id_form already, attributes_form is probably better

[stevegrunwell]

Rename "attributes" to "attributes_form" (matching the existing pattern) and add necessary DocBlock for this new argument. Tests have also been refactored to remove closures.

[stevegrunwell]

I agree on all counts, and TIL that even the test suite needs to support 5.2.

Thanks for the feedback!

[rachelbaker]

The comment form action attribute is already filterable via comment_form_defaults(). See #26841.

During our Comments bug scrub @boonebgorges ​suggested creating a new filter, to prevent filter stacking and letting the comment_form_defaults filter get *even more* out of hand. His example:

$addl_attributes = apply_filters( 'comment_form_additional_attributes', array() );

if ( $addl_attributes ) { 
    // do stuff.
}