Customisable submit button for comment form

[morpheu5]

Note: I'm setting this as a blocker because it is a blocker to me. Set it whatever you feel appropriate.

I badly needed to customise the submit button because I wanted to add a tabindex.

I could reimplement the whole form with my markup, but as I already worked my way through all the other fields, I did want to continue this way.

Sadly I discovered it's not possible. So, after discussing this in IRC, I decided to hack the core and propose the attached patch.

Basically now you can create a filter and output your markup, like this:

function awesome_comment_form_submit_button($button) {
	$button =
		'<input name="submit" type="submit" class="form-submit" tabindex="5" id="[args:id_submit]" value="[args:label_submit]" />' .
		get_comment_id_fields();
	return $button;
}
add_filter('comment_form_submit_button', 'awesome_comment_form_submit_button');

and filter magic happens. Please notice that

1. you have to include [args:id_submit] and [args:label_submit] if you want the comment_form() parameters to work.
2. you have to use the get_comment_id_fields() function.

It may be better but it works for me. If anybody feels like making it better, be my guest.

Proposed patch

function my_comment_form_defaults($i)
{
    $i['id_submit'] = 'submit" tabindex="5';
        
    return $i;
}
add_filter('comment_form_defaults', 'my_comment_form_defaults');

Would a workaround like that work for your case?

It would be good if the comment form was fully customizable in everything (that is, without any hard-coded HTML in it at all), and I’ve wished that myself a couple of times, but I wouldn’t say this is a blocker. :-)

Replying to demetris:

function my_comment_form_defaults($i)
{
    $i['id_submit'] = 'submit" tabindex="5';
        
    return $i;
}
add_filter('comment_form_defaults', 'my_comment_form_defaults');

Would a workaround like that work for your case?

That'd certainly be. However, I don't need to remind you how bad this practice would be. I'll never surrender myself to such immoral code :)

It would be good if the comment form was fully customizable in everything (that is, without any hard-coded HTML in it at all), and I’ve wished that myself a couple of times, but I wouldn’t say this is a blocker. :-)

Agreed :)

Hi there. Any plan to work on this? I need to know if I can rely on something like this or if I have to go for dirty workarounds.

The point is that I need to almost completely redesign the markup of the form. In fact I'd need to get rid of the <p> that surrounds the submit button and replace it with a <div>. This is because I have a theme developed for Drupal and I need to keep that in sync with the one for Wordpress, and there's no way Drupal's theme is going to be changed.

FTR, I just came up with an almost-acceptable workaround. I basically copied comment_form() into my theme's functions.php, renamed it awesome_comment_form() and used it instead of comment_form(). This way I could keep the original comment_form() function and apply the modifications to my own.

However I still hope someone's going to decide something about this patch :)

Anyone?

Future Release at this point, The attached patch uses a placeholder syntax which we don't use for a start.

The place holders we generally use are sprintf() style placeholders.

I'm not sure what you do mean by "placeholder syntax". If I had seen sprintf()s in the original code, I'd have used them.

by placeholder syntax, i meant the usage of "[args:id]" as a placeholder in the original string.

Generally, we tend to do it via "some String %1$s goes %2$s <- here"

Would love to see changes made in the next vs. where we can apply classes to the submit button. I ran into this problem today and really could have saved myself a ton of time if I were able to add classes as well as the id.

I wanted classes so that I could do something like class="btn primary success" using my boilerplate. This obviously doesn't work using id's.

Related: #19930, #20446

As @dd32 stated, the original patch comment-template.patch​ does not conform to the WP way of doing things.

I've attached 15015.diff​ as an alternative solution. It treats the submit button in the same way the comment input field (comment_field) is handled:

• A 'submit_button' entry is added to the comment form's $defaults array and contains the base markup for the button. This allows the entire 'input' tag to be filtered via the 'comment_form_defaults' filter.
• Additionally, also in the same vein as 'comment_field', the finalized (sprintf()'d) version of the submit button is passed through the new 'comment_form_submit_button' filter. This allows an additional way to customize the submit button markup prior to display.

This approach is more consistent with what the function already does/allows and permits arbitrary customization of the submit button markup.

@morpheu5 could get the 'tabindex' attribute he wants, and @anoited could add 'class' (which are also the requests in the related tickets I pointed out) -- both without needing to add specific support for those (or other) attributes.