WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 8 months ago

#20490 closed enhancement (wontfix)

Move submit_button to wp-includes for frontend inclusion & use with comment-template.php

Reported by: wpsmith Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Comments Keywords:
Focuses: Cc:

Description

It would be nice to be able to use submit_button() on the frontend as well (cf. #15064). It appears that #16066 "fixed" #16061, which it did, but moving the submit_button functions would enable to revert back to the use of submit_button(). Moreover, I recommend changing the comment-template.php in wp-includes (16066#file2) to use a filter with the submit_button to enable attributes like onClick. As it stands right now, if a user wants to track comments in their analytics they have to hide the original and add a function hooked into comment_form and redo all the args.

Attachments (1)

comment-template-formsubmit.patch (1.2 KB) - added by wpsmith 3 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 follow-up: @scribu3 years ago

Oh, please no. Let's keep that thing locked inside wp-admin.

comment:2 in reply to: ↑ 1 @wpsmith3 years ago

Replying to scribu:

Oh, please no. Let's keep that thing locked inside wp-admin.

Curious, is there a reason?

comment:3 @scribu3 years ago

Yes, the reason is that it makes for very unreadable code. For example, when I see this:

submit_button( $args['label_submit'], 'button', 'submit', false, array( 'id' => $args['id_submit'] ) )

I have no idea what that false parameter is for, without looking up the defition for submit_button().

Plus, it's not that much shorter than writing the HTML by hand, which is clear as day:

<input name="submit" type="submit" id="<?php echo esc_attr( $args['id_submit'] ); ?>" value="<?php echo esc_attr( $args['label_submit'] ); ?>" />

Similar: http://core.trac.wordpress.org/ticket/20110#comment:8

comment:4 @wpsmith3 years ago

Granted that it is not as intuitive as the markup; however, it does mean that it's not readable. submit_button() is what WP has installed to use on the admin side and used in the admin. Those who use it or want to use it will know (or know how to look it up easily/quickly).

Personally, I would like that false to become more than just a boolean where I can enter my own wrap pattern, e.g. '<p class="my-submit">%s</p>'. And it probably belongs as the last argument IMHO, but nonetheless, it is what it is.

My argument is not really for shortness as it is for consistency and the ability to filter. While I think about it, it may be better not to filter in the comment-template (if submit_button is used on the frontend) but to filter get_submit_button(). So something like this:

return apply_filters( 'get_submit_button', $button, $text, $type, $name, $wrap, $other_attributes );

However, if we don't move in favor of using submit_button() on the frontend, I would like to filter the comments HTML. Maybe something like (though I am not convinced at its efficiency):

<input name="submit" type="submit" id="<?php echo esc_attr( $args['id_submit'] ); ?>" value="<?php echo esc_attr( $args['label_submit'] ); ?>"<?php echo apply_filters( 'comment_form_submit', '', $args ); ?> />

comment:5 @scribu3 years ago

submit_button() was never meant for the front-end; the idea was to encapsulate some common markup, with one parameter for the name and another for the text. But, as it was applied throughout the admin, it was discovered that the markup wasn't actually the same everywhere, so more and more arguments were piled on.

Adding another filter inside comment-template.php is a different matter.

comment:6 @bananastalktome3 years ago

  • Cc bananastalktome@… added

Related: #20492

comment:7 @chriscct78 months ago

For context @johnbillion took a run at improving the output in #20492, and decided against it in the end.

comment:8 @johnbillion8 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

submit_button() is a poor function. We shouldn't encourage its use outside of the admin area.

Note: See TracTickets for help on using tickets.