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.

[morpheu5]

Proposed patch

[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?

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. :-)

[morpheu5]

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 :)

[morpheu5]

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.

[morpheu5]

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 :)

[morpheu5]

Anyone?

[dd32]

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.

[morpheu5]

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.

[dd32]

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"

[anointed]

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.

[coffee2code]

Related: #19930, #20446

[coffee2code]

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.

[Greenweb]

Any movement on this ?
Replying to coffee2code:

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.

[SergeyBiryukov]

#20446 was marked as a duplicate.

[jml6m]

Would love to have this functionality added, I'm making all of my Submit button changes client side with jQuery at the moment.

[SergeyBiryukov]

#26142 was marked as a duplicate.

[dwainm]

Replying to SergeyBiryukov:

#26142 was marked as a duplicate.

Sorry about the duplicate. Do you know if this is being considered?

[nofearinc]

Related to new hooks for #26395, can we add this one as I have also had issues with that and I have to solve them ​with JS for some of them?

The patch from coffee2code looks good to me, and uses sprintf and values that could be overridden in the defaults.

[SergeyBiryukov]

Related: #22792

[ivionday]

+1 for coffee2code's solution.

[Lindley White]

+1 for coffee2code's patch.

[coffee2code]

Refreshed the 15015.diff patch. See associated comment for details.

[coffee2code]

Since it's been awhile, I refreshed my previous patch​ to apply cleanly against trunk (as of r31484).

Changes made (since that patch) to accommodate updates in core in the intervening years (that caused the previous patch not to apply cleanly any longer):

• Add 'class' attribute to submit button
• Treat 'name' attribute as a configurable $arg value

Improvements made to what I originally proposed:

• Add docblock for the filter
• Add $args as argument in call for new filter. Helpful for context and if user wants to generate entirely custom markup so they have the requisite data rather than having to resort to string parsing or assumptions.
• Since the sprintf() now has so many arguments, I made things multi-line for easier reading of the code.

Attached as 15015.2.diff​.

[DrewAPicture]

formatting

[DrewAPicture]

15015.3.diff​:

• s/@since 4.2/@since 4.2.0
• Moved the building of $args_submit_button out of the filter call

[boonebgorges]

Patch looks good, but I have a question about the markup. The submit button is wrapped in <p class="form-submit">. It seems odd to include this markup as part of an argument called 'submit_button'. Putting it there also means moving the comment_id_fields() call to outside the <p> element - a change that looks harmless, but could cause problems if someone is expecting those fields in a certain place in the DOM. What do you think of removing the <p> tag from 'submit_button' and hardcoding it, like it is currently? Or maybe introducing two new arguments: 'submit_button', and 'submit_field', which would be something like <p class="form-submit">%1$s %2$s</p> (1: button, 2: id fields)? Am I being paranoid? :)

[coffee2code]

Update of 15015.3.diff that doesn't include <p> in filterable string and doesn't move comment_id_fields()

[coffee2code]

@boonebgorges: I have no strong opposition to your suggestion beyond this round of justification for 15015.3.diff​:

The implementation proposed was largely for consistency. There are 5 other filterable comment_form_fields that include the containing <p>: comment_field, must_log_in, logged_in_as, comment_notes_before, comment_notes_after (reference). And the move of comment_id_fields() seemed reasonable since it only output hidden fields.

Generally I would not be in favor of filtering container markup, but that's how it has been handled here. Since this is all output on the front-end, that approach does lead to maximal customization. With that in mind, the latter of your suggestions (something akin to <p class="form-submit">%1$s %2$s</p>) is preferable to the former. Primarily for back-compat reasons, I support that latter suggestion.

I scanned the Plugin Directory and there are a couple (less than a half dozen though) that make use of the comment_id_fields filter to output visible markup on comment forms. While I didn't delve into whether these would actually be affected by the move of the filter out of the containing <p>, it seems reasonable not to risk it.

Attached is 15015.4.diff​ that tweaks the .3 patch to target just filtering the submit input.

[boonebgorges]

The implementation proposed was largely for consistency. There are 5 other filterable comment_form_fields that include the containing <p>: comment_field, must_log_in, logged_in_as, comment_notes_before, comment_notes_after (reference). And the move of comment_id_fields() seemed reasonable since it only output hidden fields.

Yeah, I figured as much, and I thought the same thing. Splitting it into two params largely solves this, I think. Let's go with that.

[boonebgorges]

In 31699:

Improved customizability for the Submit button in comment_form().

The new 'submit_button' and 'submit_field' parameters for comment_form()
allow developers to modify the markup of the submit button and its wrapper.
These params are accompanied by targeted 'comment_form_submit_button' and
'comment_form_submit_field' filters on the concatenated markup.

Props coffee2code, morpheu5, DrewAPicture, boonebgorges.
Fixes #15015.

[tellyworth]

Just FYI we've come across a handful of themes that were affected by this. They were filtering comment_form_defaults and building a fresh $args array from scratch, so the new submit elements were not included in the return. That left them with no Submit Comment button.

It's trivial to fix in the themes, just noting it here for reference.

[SergeyBiryukov]

Follow-up: #32312