WordPress.org

Make WordPress Core

Opened 9 years ago

Closed 5 years ago

Last modified 19 months ago

#15015 closed enhancement (fixed)

Customisable submit button for comment form

Reported by: morpheu5 Owned by: boonebgorges
Milestone: 4.2 Priority: normal
Severity: normal Version: 3.0.1
Component: Comments Keywords: dev-feedback has-patch
Focuses: template Cc:
PR Number:

Description

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.

Attachments (5)

comment-template.patch (1.5 KB) - added by morpheu5 9 years ago.
Proposed patch
15015.diff (1.3 KB) - added by coffee2code 7 years ago.
15015.2.diff (1.9 KB) - added by coffee2code 5 years ago.
Refreshed the 15015.diff patch. See associated comment for details.
15015.3.diff (1.9 KB) - added by DrewAPicture 5 years ago.
formatting
15015.4.diff (1.8 KB) - added by coffee2code 5 years ago.
Update of 15015.3.diff that doesn't include <p> in filterable string and doesn't move comment_id_fields()

Download all attachments as: .zip

Change History (39)

@morpheu5
9 years ago

Proposed patch

#1 @sivel
9 years ago

  • Severity changed from blocker to trivial

#2 @morpheu5
9 years ago

  • Cc andrea.franceschini@… added

#3 follow-up: @demetris
9 years ago

  • Cc dkikizas@… added
  • Severity changed from trivial to normal
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. :-)

#4 in reply to: ↑ 3 @morpheu5
9 years ago

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

#5 @morpheu5
9 years ago

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.

#6 @morpheu5
9 years ago

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

#7 @morpheu5
9 years ago

Anyone?

#8 @dd32
9 years ago

  • Keywords needs-patch dev-feedback added; submit button markup custom removed
  • Milestone changed from Awaiting Review to Future Release

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.

#9 @morpheu5
9 years ago

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.

#10 @dd32
9 years ago

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"

#11 @anointed
8 years ago

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
7 years ago

#13 follow-up: @coffee2code
7 years ago

  • Keywords has-patch added; needs-patch removed

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.

#14 @carstenbach
7 years ago

  • Cc carstenbach added

#15 @mercime
7 years ago

  • Cc mercijavier@… added

#16 in reply to: ↑ 13 ; follow-up: @Greenweb
6 years ago

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.

#17 @SergeyBiryukov
6 years ago

#20446 was marked as a duplicate.

#18 @jml6m
6 years ago

  • Cc jml6m added

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

Last edited 6 years ago by jml6m (previous) (diff)

#19 follow-up: @SergeyBiryukov
6 years ago

#26142 was marked as a duplicate.

#20 in reply to: ↑ 19 @dwainm
6 years ago

Replying to SergeyBiryukov:

#26142 was marked as a duplicate.

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

#21 @nofearinc
6 years ago

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.

Last edited 6 years ago by SergeyBiryukov (previous) (diff)

#25 @SergeyBiryukov
5 years ago

  • Milestone changed from Future Release to 4.2

@coffee2code
5 years ago

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

#26 @coffee2code
5 years ago

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.

Last edited 5 years ago by coffee2code (previous) (diff)

@DrewAPicture
5 years ago

formatting

#27 @DrewAPicture
5 years ago

  • Focuses template added
  • Keywords commit added

15015.3.diff:

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

This ticket was mentioned in Slack in #core by drew. View the logs.


5 years ago

#29 @boonebgorges
5 years ago

  • Keywords commit removed

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
5 years ago

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

#30 @coffee2code
5 years ago

@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.

#31 @boonebgorges
5 years ago

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.

#32 @boonebgorges
5 years ago

  • Owner set to boonebgorges
  • Resolution set to fixed
  • Status changed from new to closed

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.

#33 @tellyworth
4 years ago

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.

Note: See TracTickets for help on using tickets.