WordPress.org

Make WordPress Core

Opened 13 months ago

Last modified 13 months ago

#23870 new enhancement

Filter Glyph for Comment Required Fields

Reported by: cais Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.5
Component: Comments Keywords: has-patch needs-testing
Focuses: Cc:

Description

Currently the comment-template.php file uses an asterisk (*) as the default glyph for required fields used in the comment_form() function. This glyph is not easily manipulated without having to essentially over-write the entire comment_form() function.

I suggest the glyph be filtered. Therefore if one wants to change it, for example, to a hash (#) symbol then they can simply filter the output; or, if for any other reason one might want to enhance the glyph visibility or utility the filter would then allow for this while minimizing the impact on the default comment form.

Attachments (3)

Filter_Glyph_for_Comment_Required_Fields.patch (2.3 KB) - added by cais 13 months ago.
23870.patch (2.3 KB) - added by SergeyBiryukov 13 months ago.
23870.2.patch (2.3 KB) - added by SergeyBiryukov 13 months ago.

Download all attachments as: .zip

Change History (8)

comment:1 follow-up: SergeyBiryukov13 months ago

This glyph is not easily manipulated without having to essentially over-write the entire comment_form() function.

This seems to work for me:

function change_required_fields_glyph_23870( $defaults ) {
	$defaults['fields']['author']     = str_replace( '*', '#', $defaults['fields']['author'] );
	$defaults['fields']['email']      = str_replace( '*', '#', $defaults['fields']['email'] );
	$defaults['comment_notes_before'] = str_replace( '*', '#', $defaults['comment_notes_before'] );
	return $defaults;
}
add_filter( 'comment_form_defaults', 'change_required_fields_glyph_23870' );

comment:2 cais13 months ago

Yes, that seems to work just fine. Although I still think the introduction of a direct filter for the glyph would be more inline with how the function was written and using a str_replace kluge doesn't look as pretty as would a more obviously named filter.

Either way, this solution or adding the filter would work (thus the reason for type: enhancement). Thanks for the snippet!

comment:3 in reply to: ↑ 1 cais13 months ago

Replying to SergeyBiryukov:

This seems to work for me:

To reach a point closer to my OP I would change your snippet to the following:

function required_fields_glyph_23870() {
	$glyph = apply_filters( 'comment_required_glyph_23870', '*' );
	return $glyph;
}
function change_required_fields_glyph_23870( $defaults ) {
	$defaults['fields']['author']     = str_replace( '*', required_fields_glyph_23870(), $defaults['fields']['author'] );
	$defaults['fields']['email']      = str_replace( '*', required_fields_glyph_23870(), $defaults['fields']['email'] );
	$defaults['comment_notes_before'] = str_replace( '*', required_fields_glyph_23870(), $defaults['comment_notes_before'] );
	return $defaults;
}
add_filter( 'comment_form_defaults', 'change_required_fields_glyph_23870' );

Usable but still not as clean as having the filter in core. Perhaps this can be cleaned up but that would be continuing even further off the idea I was suggesting originally of adding one line (the filtered variable) and modifying three others.

SergeyBiryukov13 months ago

SergeyBiryukov13 months ago

comment:4 SergeyBiryukov13 months ago

  • Version changed from trunk to 3.5

I'd suggest 'comment_form_required_field_mark' as the filter name, seems more obvious: 23870.patch.

This could also probably be an additional comment_form() argument rather than a filter: 23870.2.patch.

comment:5 cais13 months ago

I prefer '*_glyph' versus '*_mark' as I relate glyph to symbol (read: asterisk, hash, etc.) but either term is fine as they would both be used to accomplish the same goal of implementing this enhancement. I can also envision this to be used for much more than simply changing the character displayed so the naming convention may not be vitally important as is.

As to an argument rather than a filter ... I would probably think to look for a filter first (as I actually did) versus digging into the function to find the specific argument to address, but again either method is fine as both work. The argument method may be more inline with the rest of the function code even if I actually would prefer the filter myself.

Note: See TracTickets for help on using tickets.