Customizing the WordPress comment form

Previously on the CogitActive Saga:
The basic comment form, which appearance depends on the WordPress theme, includes the following fields: Comment, Name, Email and Website.

As emphasized in the previous post, comments in WordPress are not only an essential component of blogging, but also a great way to involve your readers and provide them with a feedback opportunity. Suitably, WordPress provides a built-in comment system, which includes a comment form. Using the Twenty Seventeen theme, the default form – notwithstanding a sleek and modern design – will look quite basic.

This form may not come with all the bells and whistles offered by some comment plugins¹; still, it is perfectly adequate to engage with your readership. Moreover, its simplicity makes it easy for people to comment. With few hoops to jump through, visitors are indeed more inclined to leave a comment. Not interested in additional functionalities (at the time) – with the exception of a reaction module (coming soon) – I decided to use the native comment form; yet, I wanted to tweak it a little bit.

In particular, I wanted to remove the Website field, which apparently attracts many spammers. WordPress indeed hyperlinks the commenter’s name with the URL provided in this field (when displaying the comments). This actually represents an incentive for spammers to build links to their websites. While removing this field will not stop spam, doing so allegedly reduces their number. Moreover, this can prevent ending up with broken links on your site (when people give up on their website).

The biggest reason for spam comments is the desire to get backlinks by using the website url field in the WordPress comment form.Syed Balkhi

More importantly, I wanted the comments to be as useful and informative as possible to my audience. In keeping with this idea, I wanted to change the wording of “Leave a Reply” to something more tailored to this intent. Likewise, it was important to provide a brief synopsis of my Comment Policy, if only to clarify that comments were expected to offer constructive (either positive or negative) criticism. For the sake of transparency, it was also imperative to inform commenters that I would moderate their comments (and, if possible, to provide a link to my Comment Policy).

Of course, using a plugin to achieve this task was not an option². Fortunately, you don’t have to be a web developer to tinker with WordPress code. Nevertheless, as explained in the so-called article, to do so it is best to use a child theme. That’s lucky, I have already created one! Time to get my hand dirty: how to customize the WordPress comment form?

Removing the ‘url’ comment field

As with everything, the best place to find accurate information is at the source³. Briefly, the comment-form() function is used by your theme to output the comment form. It has two parameters $args and $post_id, but let me put these technicalities aside for the moment. What is important to know, however, is that the default comment fields are filterable via the comment_form_default_fields hook.

Most strings and form fields may be controlled through the $args array passed into the function, while you may also choose to use the ‘comment_form_default_fields’ filter to modify the array of default fields if you’d just like to add a new one or remove a single field.WordPress

function Name_Of_Callback_Function() {
	YOUR CALLBACK FUNCTION HERE
}
add_action (‘Name_Of_The_Action_Hook’, ‘Name_Of_Callback_Function’);

Before to give you the code to remove the ‘url’ comment field (to be added to your functions.php file), let me tell you that finding it was no easy task (at the time I wanted to implement it). Neither the codex article³ nor the one⁴ about the aforementioned hook were providing such a code. To make a long story short, many articles on the subject matter recommend wrong methods. Putting asides the classical “using a plugin” approach, some articles suggest to use CSS (i.e. .comment-form-url {display:none;}) to ‘remove’ this field. This will not remove it, but just hide it! Similarly, others suggest to modify the comment-form() function directly within the template of your theme (or child theme). Didn’t they know about hooks?

Eventually, I found an article by Abbas Suterwala⁵ with the code shown below. After confirming its validity with other sources, I decided to implement it. Luckily, it is the same as the one now provided in WordPress⁴. Of note, I also found alternative versions for the Callback function, in which the ‘url’ variable was set to null⁶, instead of being unset as shown below.

function remove_comment_urlfield ($fields) {
	unset($fields['url']); 
	return $fields;
}
add_filter('comment_form_defaults_fields','remove_comment_urlfield');

Just add the code before the closing ?> in your functions.php file (see Creating a child theme).

Modifying the form even further

As already explained, my goal was 1) to change the wording of “Leave a Reply” and 2) to provide a brief synopsis of – and a link to – my Comment Policy. While the first task was relatively straightforward, the second one proves a little bit more challenging. Actually, there are several ways to do so:

• Add the text before or after the comment field
• Add the text within the comment field (as a placeholder)
• Add the text in a popup window (using WordPress Thickbox).

Admittedly, there are some concerns with the placeholder attribute (see Don’t Use The Placeholder Attribute). However, given my intended use – supplementary information only – I ended up choosing this option over the other two. In particular, while adding text before or after the comment field might have been easier to implement and better for accessibility, the resulting form would have been too bulky. Besides, there is already some text before the comment field and I wanted to keep it like that.

Your email address will not be published. Required fields are marked *

Customizing the ‘title_reply’ argument

As already stated, the comment-form() function has two parameters $args and $post_id and – again quoting WordPress – most strings and form fields may be controlled through the $args array passed into the function³. Among the strings listed in the default $args array, the one of interest is ‘title_reply’ – the translatable ‘reply’ button label which defaults to “Leave a Reply”.

'title_reply'          => __( 'Leave a Reply' ),

Finding a code to replace this “Leave a reply” text with my own was simple (even if not provided in the codex at the time). Again, I am referring to methods using filters! After double-checking with other – more recent – sources, I decided to implement this code (first found here⁷):

function comment_form ($arg) {
	$arg['title_reply'] = __('Add value to this post:');
	return $arg;
}
add_filter('comment_form_defaults','comment_form');

Adding a placeholder to the ‘comment_field’ argument

In keeping with the same logic, I looked for a way to add a placeholder to the ‘comment_field’ string, which – back then – defaulted to:

'<p class="comment-form-comment"><label for="comment">' . _x( 'Comment', 'noun' ) . '</label><textarea id="comment" name="comment" cols="45" rows="8" aria-required="true"></textarea></p>'

As you can see, this code has a <textarea> element, which in HTML defines a multi-line text input control. More importantly, this element supports the placeholder attribute (new in HTML5) and the task at hand would consist in adding this attribute within the opening <textarea> tag as described in the aforementioned WP site post.

A downside of this approach (i.e. using a placeholder to provide a brief synopsis of my Comment Policy) is that the placeholder attribute accepts only text. In other words, I would not be able to add a link to my Comment Policy from there.

Killing two birds with one stone

Interestingly, both functions (see above) hooked into the same filter (i.e. comment_form_defaults) and targeted the same parameters (i.e. $args). Therefore, I merged them into a single code:

function comment_form ($arg) {
	$arg['title_reply'] = __('Add value to this post');
	$arg['comment_field'] = '<p class="comment-form-comment"><label for="comment">' . _x( 'Comment', 'noun' ) . '</label><textarea id="comment" name="comment" placeholder="Comments are expected to offer constructive (either positive or negative) criticism in order to be as useful as possible to all readers. For quick comments, please consider using the reaction buttons (Like, Agree, Disagree and/or Thank You) instead. 
	
All comments are moderated according to our Terms of Use." cols="45" rows="8" aria-required="true"></textarea></p>';
	return $arg;
}
add_filter('comment_form_defaults','comment_form');

A final touch

While most browsers use a light gray color for placeholder content (i.e. a lighter color than the input content), the Twenty Seventeen theme displays them with the same dark charcoal color as the rest of the content (i.e. #333333). Laudable though this approach might be (for accessibility concerns), it makes the placeholder appears like entered input and people may interpret it as such.

Some people argue that the default light gray color has poor color contrast against most backgrounds. This means that it is hard to see/read for many people. For this reason, the World Wide Web Consortium (W3C) recommends using a contrast ratio of at least 4.5:1 to meet the minimum contrast requirement of WCAG. Accordingly, I decided to use the grey color #767676, which has just enough contrast (i.e. 4.54:1 on a white background) to meet this requirement; still, communicating that the so-colored text is a placeholder.

To accomplish this, I needed to override my theme’s style rules. As explained in Creating a child theme, these CSS rules are listed in the stylesheet of the theme, namely style.css. In my case, the file in question was the one specially created for my child theme (i.e. not the one of Twenty Seventeen). Importantly, before to add my custom CSS code to this file, I had to figure out how to modify the color specifically of 1) the placeholder 2) within the comment field of 3) my comment form.

selector {
	property: value;
}

In general, to figure out which selector to use, the simplest approach is to right click the specific element (that you want to target) in the web page and choose the Inspect element option – a powerful (and free) development tool. In the dock that appears at either the bottom or the right of your window (depending on your browser), you will see the source code (i.e. HTML) of the page, as well as the styling (i.e. CSS) of the selected element. What is important, here, is to identify the CSS attribute of this very element (i.e. the id and/or class statements). You can find this information in the pathway panel (among other places).

Using this approach, I confirmed that my element was associated with the comment-form-comment class and with the comment id; these two information being already available in the 'comment_field' string (see code above). I could therefore use either .comment-form-comment or #comment as my selector. Actually, the information provided by the tool were p.comment-form-comment and textarea#comment, respectively. Using the former selector, I could specifically target <p> elements with class=“comment-form-comment”. Similarly, if I were to use the latter, I would modify only the <textarea> with id=“comment”” (remember, the id of an element must be unique on a web page). Great! However, none of these four potential selectors allowed me to change the color of my placeholder text!

In fact, to select a part of an element (e.g. the placeholder in the <textarea> element), you need to use a pseudo-elements selector. Fortunately, there is a ::placeholder pseudo-element that represents the placeholder text in a <textarea> element (as well as in a <input> element, for that matter). Importantly, the pseudo-element is noted with a double colon “::”. Great!? Expectantly, I tried this selector, but to no avail.

Eventually, I discovered in this article that styling a placeholder is a little bit more complicated because various browsers handle them differently. This means that to target most browsers, you need to use several variants. Going through the style.css file of Twenty Seventeen, I found the following variants used by my theme for “Placeholder text color” (in the 6. Forms section):

• ::-webkit-input-placeholder (for Chrome, Edge and Safari)
• :-moz-placeholder (for Firefox 4 to 18)
• ::-moz-placeholder (for Firefox 19+)
• :-ms-input-placeholder (for Internet Explorer)

Guess what! While these selectors were working, as expected, they were changing the color of every placeholders (e.g. “Search…” in the Search widget); that is not only the placeholder text in my comment form. Indeed, the correct approach is to combine the pseudo-elements with the aforementioned selectors:

.comment-form-comment ::-webkit-input-placeholder {
	color: #767676;
}
.comment-form-comment :-moz-placeholder {
	color: #767676;
}  
.comment-form-comment ::-moz-placeholder {
	color: #767676;
}
.comment-form-comment :-ms-input-placeholder {
	color: #767676;
}

I add the above code to my style.css (see Creating a child theme) and voilà!

To be continued…

¹ Of which there are two kinds: those that allow you to modify the default comment form and the ones that completely overhaul the WordPress comment system. While I would rather choose coding option than using the former kind – hence this post – I am not opposed to the latter. In fact, I might have to re-consider this option in the future. ^
² Clearly, I am reluctant to use (too many) plugins. First, they can conflict with each other, but also affect your site’s performance. Second, they are a security risk that can’t be ignored. Last, I have learned the hard way that plugins may not be available forever (especially the free ones). Anyway, it is better to avoid using them whenever possible. ^
³ Specifically, at the time, it was this Function Reference/comment form article (in the codex), but a more recent version is now available. ^
⁴ Since, you can find the code at the bottom of the page about the comment_form_default_fields filter; in this recently added User Contributed Notes (by Mohamed Abkari). ^
⁵ Abbas Suterwala (2012) Customizing Comments in WordPress – Functionality and Appearance. Envato Tuts+. ^
⁶ I dig a little about the difference between both approaches. The ‘unset’ method does exactly what its name says (in this particular code, destroy the argument ‘url’ in the $fields array), whereas the ‘null’ method rewrites the variable’s data (to null). While there is some debate about their respective performance (in terms of memory usage and speed processing), the former is apparently recommended to minimize script impact on your system. Another aspect concerning ‘unset’: you don’t need to check that a variable is set before to unset it. Mentioning no names! ^
⁷ Isabel Castillo (2019) How to Change “Leave a Reply” Text on Worpress [sic] Reply Form. ^