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

Hooks

Modifying core files is generally not a good idea; be it WordPress core, themes or plugins files. Thankfully, WordPress provides an advanced feature to interact with (or modify) its code, namely hooks. They allow you to “hook into” WordPress code – or more specifically to hook one function to another – with two types of hooks: Actions and Filters.

Even though you can sometimes accomplish the same goal with either one, they are different in functionality. Briefly, actions allow you to add data or change how WordPress operates. They provide a way to run a function at a specific point in the execution of either WordPress core, themes or plugins. On the other hand, filters give you the ability to change data during the execution of WordPress; they allow you to modify certain functions.

Adding actions or filters is a two-step process. First, you create a Callback function that is your own custom function. Second, you add it to a hook, which will perform the calling of the function. To do this last step, you need to use add_action() or add_filter(), respectively. Unless you are creating a plugin, you will add the whole code in the functions.php file (see Creating a child theme). Below is a theoretical example or, more accurately, a simplified syntax for adding an action.

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.

Comments vs. Reactions

Clearly, it is pleasing to receive comments like “Thank you for this post”, “Great post”, “A very helpful article” and the like. As an author! However, when I search the comment section of someone else’s article (for useful information), going through these (nice) reactions is more annoying than informative.

I wanted my comment section to be as useful and informative as possible for my readers. Accordingly, I emphasize in my Comment Policy my interest for articulate, well-informed comments. Specifically, I welcome any contribution that expands on the article’s premise – alternative viewpoints, insights into a particular topic, etc. In short, anything that can promote an active exchange of ideas and/or constructively adds to the conversation; hence the “Add value to this post” instead of the default “Leave a Reply”.

That being said, quick comments as those described earlier (e.g. Like, Thank you) are also valued, if only as feedback. Now, to spare my audience from going through those, and yet to allow them to share their reactions, I decided to implement a secondary commenting system, or, more accurately, a reaction plugin (coming soon).

For quick comments, please consider using the reaction buttons (Like, Agree, Disagree, and/or Thank You) instead.

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.

Cascading Style Sheets (CSS)

CSS is a style sheet language that describes how HTML elements are to be displayed on screen. Briefly, CSS rules consist of a selector and a declaration block. The former points to the HTML element you want to style and the latter contains the properties and values that will be assigned to the selector. Importantly, every CSS property needs to be followed by a colon “:”, and each CSS value needs to be followed by a semicolon “;”. Here is the CSS syntax:

selector {
	property: value;
}

There are several categories of selectors, among which the most basics are element, id and class. The element selectors, which are named for the corresponding HTML elements (e.g. p for <p>), can apply to (i.e. select) any HTML element. The id selectors, in contrast, use the id attribute of an HTML element (e.g. id=“comment”). They are referenced with a hash “#” character before the id of the element (e.g. #comment). Of note, the id of an element must be unique on a web page. Similarly, the class selectors target HTML elements with a specific class attribute (e.g. class=“comment-form-comment”) and are written with a period “.” followed by the class name (e.g. .comment-form-comment).

As you can imagine, understanding the basics of selectors is essential, if only to define which HTML elements in the templates are to be styled with CSS (e.g. the placeholder within the comment field of the comment form).

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)

Of note, the ones using a single-colon syntax are for backward compatibility (pseudo-class instead of pseudo-element).

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

What do you think?

Like ()
Agree ()
Disagree ()
Thank you ()