WordPress 3.0 Theme Tip: The Comment Form
WordPress 3.0 has something very handy that I want theme authors to start implementing as soon as possible.
To show exactly why it’s so useful, I modified my own theme to start using it.
Demonstration
So, here’s a big hunk of code I pulled out of my current theme’s comments.php. This hunk of code has only one purpose: To display the form area where people can leave a comment:
<?php if ('open' == $post->comment_status) : ?>
<div id="respond">
<h3><?php comment_form_title( 'Leave a Reply', 'Leave a Reply to %s' ); ?></h3>
<div class="cancel-comment-reply">
<small><?php cancel_comment_reply_link(); ?></small>
</div>
<?php if ( get_option('comment_registration') && !$user_ID ) : ?>
<p>You must be <a href="<?php echo get_option('siteurl'); ?>/wp-login.php?redirect_to=<?php echo urlencode(get_permalink()); ?>">logged in</a> to post a comment.</p>
<?php else : ?>
<form action="<?php echo get_option('siteurl'); ?>/wp-comments-post.php" method="post" id="commentform">
<?php if ( $user_ID ) : ?>
<p>Logged in as <a href="<?php echo get_option('siteurl'); ?>/wp-admin/profile.php"><?php echo $user_identity; ?></a>. <a href="<?php echo wp_logout_url(get_permalink()); ?>" title="Log out of this account">Log out »</a></p>
<?php else : ?>
<p><input type="text" name="author" id="author" value="<?php echo $comment_author; ?>" size="22" tabindex="1" />
<label for="author"><small>Name <?php if ($req) echo "(required)"; ?></small></label></p>
<p><input type="text" name="email" id="email" value="<?php echo $comment_author_email; ?>" size="22" tabindex="2" />
<label for="email"><small>Mail (will not be published) <?php if ($req) echo "(required)"; ?></small></label></p>
<p><input type="text" name="url" id="url" value="<?php echo $comment_author_url; ?>" size="22" tabindex="3" />
<label for="url"><small>Website</small></label></p>
<?php endif; ?>
<!--<p><small><strong>XHTML:</strong> You can use these tags: <code><?php echo allowed_tags(); ?></code></small></p>-->
<p><textarea name="comment" id="comment" cols="100%" rows="10" tabindex="4"></textarea></p>
<p><input name="submit" type="submit" id="submit" tabindex="5" value="Submit Comment" />
<?php comment_id_fields(); ?>
</p>
<?php do_action('comment_form', $post->ID); ?>
</form>
<?php endif; // If registration required and not logged in ?>
</div>
<?php endif; // if you delete this the sky will fall on your head ?>
Nasty, eh? It’s a mess of if/else statements. It handles cases where the user is logged in or not, where the comments are open or closed, whether registration is required, etc. It’s confusing, difficult to modify, poor for CSS referencing…
Here’s what I replaced all that code with:
<?php comment_form(); ?>
Now then, that’s much better, isn’t it?
The comment_form function is new to 3.0. Basically, it standardizes the comments form. It makes it wonderful for us plugin authors, since now we can easily modify the comments form with various hooks and things. I’ve already modified Simple Facebook Connect and Simple Twitter Connect to support this new approach; if you’re using a theme with this, then the user won’t have to modify it to have their buttons appear on the comments form.
Customizing
Since theme authors love to customize things, the comments form is also extremely customizable. Doing it, however, can be slightly confusing.
Inside the comments_form function, we find some useful hooks to let us change things around.
The first hook is comment_form_default_fields. This lets us modify the three main fields: author, email, and website. It’s a filter, so we can change things as they pass through it. The fields are stored in an array which contains the html that is output. So it looks sorta like this:
array( 'author' => '<p class="comment-form-author">...', 'email' => '<p class="comment-form-email">...', 'url' => '<p class="comment-form-url">...' );
I truncated it for simplicity. But what this means is that code like this can modify the fields:
function my_fields($fields) {
$fields['new'] = '<p>Some new input field here</p>';
return $fields;
}
add_filter('comment_form_default_fields','my_fields');
That sort of thing lets us add a new input field, or modify the existing ones, etc…
But fields aren’t the only thing we can change. There’s a comment_form_defaults filter too. It gets a lot of the surrounding text of the comments form. The defaults look sorta like this:
$defaults = array( 'fields' => apply_filters( 'comment_form_default_fields', $fields ), 'comment_field' => '<p class="comment-form-comment">...', 'must_log_in' => '<p class="must-log-in">...', 'logged_in_as' => '<p class="logged-in-as">...', 'comment_notes_before' => '<p class="comment-notes">...', 'comment_notes_after' => '<dl class="form-allowed-tags">...', 'id_form' => 'commentform', 'id_submit' => 'submit', 'title_reply' => __( 'Leave a Reply' ), 'title_reply_to' => __( 'Leave a Reply to %s' ), 'cancel_reply_link' => __( 'Cancel reply' ), 'label_submit' => __( 'Post Comment' ), );
All the various pieces of html that are displayed as part of the comment form section are defined here. So those can be modified as you see fit. However, unlike the fields, adding new bits here won’t help us at all. The fields get looped through for displaying them, these are just settings that get used at various times.
But filters are not the only way to modify these. The comment_form function actually can take an array of arguments as the first parameter, and those arguments will modify the form. So if we wanted a simple change, like to change the wording of “Leave a Reply”, then we could do this:
<?php comment_form(array('title_reply'=>'Leave a Reply, Stupid')); ?>
This gives us a simple and easy way to make changes without all the trouble of filters. Nevertheless, those filters can be very useful for more complex operations.
But wait, there’s more!
As the comments form is being created, there’s a ton of action hooks being called, at every stage. So if you want to insert something into the form itself, there’s easy ways to do it.
A quick list of the action hooks. Most of them are self-explanatory.
- comment_form_before
- comment_form_must_log_in_after
- comment_form_top
- comment_form_logged_in_after
- comment_notes_before
- comment_form_before_fields
- comment_form_field_{$name} (a filter on each and every field, where {$name} is the key name of the field in the array)
- comment_form_after_fields
- comment_form_field_comment (a filter on the “comment_field” default setting, which contains the textarea for the comment)
- comment_form (action hook after the textarea, for backward compatibility mainly)
- comment_form_after
- comment_form_comments_closed
CSS and other extras
Let’s not forget styling. All parts of the comments form have nice classes and id’s and such. Take a look at the resulting HTML source and you’ll find all the styling capabilities you like. Also, everything is properly semantic, using label tags and aria-required and so forth. All the text is run through the translation system for core translations.
So theme authors should start modifying their themes to use this instead of the existing big-ugly-comment-form code. Your users will thank you for it. Plugin authors will thank you for it. And really, it’s about time we made WordPress themes more about design and less about the nuts and bolts of the programming, no?
Nice!!
Aww, and the comments.php template used to be my favorite piece of spaghetti, which was the perfect excuse to pretend it didn’t exist. Now I’m going to have to start utilizing it, and that just adds work.
Way to go Otto. You increased my workload.
[…] wait, we always need a versatile custom styling aren’t we? go check out the article for detail Share this […]
[…] WordPress 3.0 theme tip the comment form […]
[…] Ecco un esauriente articolo sull’argomento: WordPress 3.0 Theme Tip: The Comment Form […]
[…] questo argomento ha parlato già @ottodestruct nel suo articolo WordPress 3.0 Theme Tip: The Comment Form, di cui vi consiglio la lettura se avete mai creato un tema per […]
[…] Not too long ago, WordPress made it easier for designers to include the comment-form template-tag in their themes by abstracting all of that crazy code elsewhere in the core. Now in version 3.0, the comment form is abstracted even further – to the point of being called with a single template tag. It’s still customizable, just way more abstract than before. Read more, again at Otto’s place. […]
Great post Otto. I appreciate you bringing this forward.
Not another major change! This is doing my head in!
Good news, I think. A great looking comments section encourages readers to comment, I believe.
And of course I don’t code, so this doesn’t really add too much work for me.
With this new code, is it possible to have different comment forms for different categories? How would one go about implementing this?
You could use the in_category() function along with any of these bits to make the form behave differently for different categories.
[…] comment_form() can be changed for any theme using filters and custom styles. For More Details on this, read this post by OttoPress. […]
A rather annoying point about this new function is that it completely rules out the use of an image submit button. Background images don’t always cut it, and so either this whole function would need to be scrapped and the old method used, or a nasty php replace hack could be done. Allowing for an image submit button as a parameter/filter would be idea.
No, there is a way. You could use CSS to hide the .form-submit class with display:none. That would eliminate the existing submit button. Then you could use the comment_form action to insert your own submit button in its place.
The problem with using image submit buttons is that they sometimes don’t work in various low-end mobile browsers. But, those browsers generally don’t respect CSS all that well either, so the normal submit button would still show up for them in that case.
I lose my submit button image. Is possible to recover this?
Wordpress 3.0.1, multisite.
Thanks.
Actually, it isn’t…
There are two specific points where the defaults mess up – albeit in the same manner. The logged in / must login data & the allowed_tags are being generated within plain paragraph tags. Yet both are within the form. The upshot is that these (presumably significant) pieces of info will be missed when JAWS goes into Forms mode as it hits the form tag. From that point onwards, until the closing form tag, JAWS will only render content within forms controls (labels etc). So to hear this data, a user would need to make 2 passes over the form – the second one in “forced” Virtual Cursor mode.
The fixes are relatively simple. The allowed_tags simply need to be placed within a label that’s linked to the textarea using
comment_notes_after. The logged-in data isn’t quite so easy. It really needs to be generated before the form tag.[…] It’s next to the submit button again, instead of being above the form. Apparently some new comment form features didn’t quite work with my theme, but it was easy enough to […]
Hi
How can I target the containing ? I’m converting the WP3 template to HTML5 so want to change the to a but can’t find a way of getting to that .
Thanks.
Can’t post html here. Leave off the html brackets.
Sorry. I want to the replace the containing div with an ID of “respond” (or “response”—I’m away from my machine at the moment and can’t remember the exact value). I want to change the div to a section tag.
Thanks.
Yes, I see.
Generally, I highly recommend against modifying the HTML. The question becomes “why do you want to use tag X instead of tag Y?” Usually the answer is because the person wants to make it display differently. The problem with that is that you can control all that via stylesheets.
Now, in your case, you’re wanting to use an HTML 5 section for it. However, I don’t think that really fits the semantic parameters of the HTML 5 section tag. You could interpret it that way, I guess, but frankly I’d leave it as a div. If you really want to wrap that in a section, you can use the comment_form_before and comment_form_after actions to add your surrounding section to it. But you can’t replace it. The respond div is hardcoded specifically because other code refers to it (the javascript that moves the comment form around on the page needs it to be there).
Hi Otto. Thanks for the info, I’ll work around it using your suggestion.
[…] week I had to replace the theme’s comment form (fortunately with something simpler) because it didn’t interact quite right with WordPress […]
[…] WordPress 3.0 Theme Tip: The Comment Form » Otto on WordPress A quick explanation and guide to the implementation of the new comment form function introduced with WordPress 3.0 (tags: 3.0 comments wordpress development) Leave a Reply Click here to cancel reply. […]
[…] WordPress 3.0 Theme Tip: The Comment Form […]
[…] want to further customize the comment_form template tag, I highly recommend OttoPress.com’s tutorial on the new form tag or check out the codex for more […]
With the old system it wasn’t difficult to make small changes to the comments area if you knew a little of what you were doing, with this new system it seems I have to write a plugin in order to it.
No, not really. For small changes, you can just modify the call to comment_form() as I describe above. If you really need to use a filter or action hook, you can add those right before the call to the comment_form function in the theme’s comments.php file.
[…] WordPress 3.0 Theme Tip: The Comment Form […]
I wonder if this new development in the comment form will actually automate enabling comment threading. I just wish so!
No. This has nothing to do with threading, really.
Great Script! Loved it!
Where can i edit comment_form() ? I want to add some fields, but can find where i can do this..
I have the same question. I’m used to editing php files a lot, but diving into functions is something I do only a little tiny bit. I don’t know where things are. 🙁 Please be MORE specific with how to modify the function. A lot of us are used to that big mess cause it’s all right nearby our HTML and CSS, but we have no idea where to find the function itself.
Found it:
/wp-includes/comment-template.php
I’ve been using wordpress for a long time, coding pure php, writing apps, using all sorts of systems. I would rather look at that big ‘mess’ of code any day than learn more functions and have to read more documentation on how to override a theme function.
That’s the point though. You shouldn’t have to override it, except perhaps in very small ways. Things works better when they’re standardized. Plugins can work better with your theme without having to have the users manually modify everything. And compatibility is the real name of the game. Why make your theme hard to use for your end users?
Maybe you can give some short instruction? I need 1 new field – user age. What i need to do – i want get this field and later show with comment. Plz. help.
Hi, Thanks for the concise explanation. I can’t figure out how to add another field, though. Or more specifically: how do I store the field value somewhere and then recall it. Is it stored in the commentsmeta table? If so, how?? I’m also confused by this syntax: esc_attr( $commenter[‘comment_author_email’] )
Could you point me to a more detailed article?
[…] ได้แบบง่ายโคตรๆ จากบทความนี้ครับ “WordPress 3.0 Tip: The Comment Form” จาก ottopress.com […]
Thank you very much for this detailed explanation! Very handy, indeed.
[…] cannot hard-code CAPTCHA fields into the comment form. Fortunately, WordPress has several built-in, comment form-related hooks. For our purposes, the comment_form_after_fields action hook works perfectly. This hook will allow […]
[…] goodbye to long, complicated codes and hi to a new, simple and easy-to-implement comment function.WordPress 3.0 Theme Tip: The Comment FormTemplate Tags/comment form (WordPress Codex)Display Comment Form With Ease In WordPress 3.06. […]
It looks like you are doing what I’ve been trying to acheive. How do you get the comments to post to Facebook?
I have code written to post the comment, but am not sure how/where to execute the code.
I’ve tried looking for a hook/filter for doing an action immediately after the submit button is clicked, before the form data is sent to the comments-post.php.
I’ve also looked for a hook/filter which can hook into the comments-post.php file before the redirect takes place.
Thanks.
In point of fact, I use hidden javascript code on the page to popup a share link to the user. Let them post their own comments.
To actually fill in the name/email/url fields from FB commenters, I use the pre_comment_on_post hook. There I can use the FB PHP library and get the user’s info. Then I simply put the info into the $_POST[] array directly, overriding whatever was there before.
I also use the comment_post hook to add meta data to the comment in the form of the user’s Facebook ID number. This is later used to help retrieve the URL of their FB avatar. If I was going to use streamPublish to send the comment directly to Facebook, that’s where I’d do it. The comment_post action hook gets the comment_ID of the just published comment, and you can retrieve the comment info using that if you need it.
Wow. Thanks for the reply. I don’t see any documentation on the wordpress.org site about the pre_comment_on_post. Will this hook allow me to access the $_POST variables sent to the wp-comments-post.php?
What I’m trying to do is to send the needed facebook variables in hidden fields from the form.
And then execute the following code to post to the facebook page.
$access_tkn, 'message' => $message);
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $fburl);
curl_setopt($ch, CURLOPT_HEADER, false);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, $fbargs);
$data = curl_exec($ch);
curl_close($ch);?>
Stop looking for documentation for everything. The code is the only documentation you need. WordPress is free, you can just look at it directly, you know. 😉
The pre_comment_on_post action is in the wp-comments-post.php, right before the POST variables get trimmed and stripped of tags and such. So while you can use that for your action, it would be better to wait until the comment is actually cleaned and saved. Still, it’s useful if you need to get hidden post values and hang onto them for a while.
But if you need data from the comment itself, use the comment_post action. You’ll find it in wp-includes/comment.php. The action hook passes your function the comment ID, so all you have to do is to call get_comment($comment_ID) to get the comment object. Then you can do whatever you want with the comment data, including sending it to wherever.
=) You are correct, but I don’t always understand everything taking place in some of the wordpress core files. {Still much to learn}
When would I call the comment_post action? And would I still have access to the facebook token?
PS: I checked the box to post to my facebook profile on the last comment and it did not post to my facebook profile.
On this site, no, it doesn’t publish directly to your profile. Instead it causes a share popup to happen after you return to this page (assuming you’re not blocking cookies or something).
And you would use the comment_post action like you would any other action. In a plugin, for example.
Read this: http://codex.wordpress.org/Plugin_API#Actions
Documentation of this function is poorly written on the wordpress.org
I understand that the function comment_form() can help, but right now its almost not usable for a little bit more advanced comment forms.
Anyway thanks for the article 🙂
Dusan
Actually, it’s a heck of a lot easier to use comment_form() for advanced forms than you think. And the lack of documentation is exactly why I wrote this article. 🙂
I seriously suggest you switch to it and start using it. It makes your life a lot easier in the long run.
Well, I have been playing with comment_form() for a two days and still can’t get results what I want 😀
I can add/remove fields, change text etc, but actually i need to add some divs, clickable smilies etc and for some reason that makes me a problem 🙂
Give me a specific example and I’ll tell you how to do it. 🙂
Grr, I hate you 😀
Before I had a little bit more complicated form, but right now I’m think to use this http://img685.imageshack.us/img685/7338/exampleg.png
As i started to make my own form, without using comment_form(), I have lost all the code :D, but I ll write it again if it can help you.
Ok I not understand because I not show the code, I repeat for the last time. Sorry.
Your article is rock, but a questions:
if I want to change the html tags of the submit section?
i.e.: change from
…to…ps: you can see here http://pastebin.com/9Ps7DMsL too
You shouldn’t need to change the HTML of the “submit section”. Especially not from a P to a DIV, as that makes little sense.
Just use styling CSS to style that particular P to be the way you want. You gain no advantage by changing it to a DIV.
I not agree, use P is semantically flawed. A form and its elements are not a series of paragraphs. And is bad mix markup with presentation.
Makes much more sense use DIV instead P.
Otto
From the ever-increasing amount of comments you’re receiving here, it is becoming apparent that, although you keep repeating that the code is easier to work with, people are finding it harder. Just because it’s neater and, for you, perhaps a more elegant solution, it clearly isn’t the case for others. Your “Stop looking for documentation for everything. The code is the only documentation you need.” clearly shows you don’t understand your audience. WordPress needs to be an alternative to things like Drupal, which is far too complicated unless you’re a code fiend. There needs to be clear documentation and it needs to be in one place—on the wordpress.org site.
Finally, the lack of flexibility you’ve introduced is frankly unacceptable. If developers want to change tags, they should be able to, whether you agree with their choices or not. It’s *their* site and if they want to mess with the code, they should be able to. Sure, you can point them in the correct direction, but if they want to change things around, they should be able to.
If developers want to hard code their HTML form in the comments file as they have in the past, there’s absolutely nothing stopping them from doing it. This function is not *required* by any means.
However, historically, themes don’t do this. At least, not very often. And realistically, they don’t need to. Something like 90% of the changes I’ve seen to simple basic functionality in themes has two main defining characteristics: a) They could have done it easily with pure CSS, if they’d thought about it and b) by changing the code, they broke something in a subtle but important way.
Standardization is good. Semantic HTML is better. And changing semantic HTML tags in order to affect a change to the look of the page (what we call “presentation”) is almost always a bad thing to do.
>Standardization is good. Semantic HTML is better. And changing semantic HTML tags in order to affect a
>change to the look of the page (what we call “presentation”) is almost always a bad thing to do.
>
And I agree but use P for FORM elements is semantically flawed. And if I want change P with DIV I can’t.
I not want change a semantically HTML tags for a presentational markup but form elements are not a series of paragraphs. And in WordPress the comment form uses P instead a most semantically correct tag like DIV.
I disagree that using P there is semantically incorrect. And regardless, changing those out with DIVs would have no impact of any sort whatsoever.
Note: I do agree that using a List with a fieldset would be better. But DIVs? Nah.
Otto,
I’m with Francis on this topic (comment immediately above) for several reasons –
First is that this removes sustainability of heavily customised legacy themes, particularly in high comment-traffic sites where the comment form is itself heavily customised, let alone the rest of the templates and functions. As time rolls on, WP and plugins will become so entirely dependent on custom action and filter hooks, that those otherwise perfectly functional custom themes will simply break when WP core and plugins are upgraded.
What this entire system does is to force upon the entire WP webmaster base an unrequested need to upgrade on a scale not seen since driving licenses became compulsory. This is not an incremental revision, this is like the switch from homo erectus having fur, to homo futurus having full environmental controlling clothing. My belief is that this will serious stall and damage the adoption graph for WordPress.
Like many of the other posters before me, I also do not believe this is easier than recoding direct into theme files, remember themes themselves are only one large template from which a site can be developed by starting with the theme that has the closest match to the desired end appearance and functionality.
Child themes may be great, but they too are a very real pain to develop, particularly when coupled with this new hooks and filter functionality, and all the other changes (just how long was that list of deprecated template tags?) – the learning curve is just too steep, and too undocumented by WP.org, and the subsequent workload far too heavy for webmasters like me with large domain name portfolios – I take pride in being the developer-implementer for all my sites, but with this I am going to have to contract in outsiders just to bring everything to a state where sites will not start breaking before Christmas.
Thanks for nothing WordPress, these changes are unwarranted and too all-encompassing.
Remember the age old adage – don’t fix what ain’t broken. WordPress have thrown out what worked and are very much “doing an eBay” with this disruptive innovation.
Lots of stuff there, so I’ll take it one by one.
This doesn’t break legacy anything. If you want to write your own form, then do it. It’ll work. This just adds an option (and a damn good one I might add) that is actually easier to use and more compatible with plugins and the like.
If you want your theme’s users to continue to have to screw around with your theme manually, then by all means, create your own solution. However, as a plugin developer, I’d prefer to not have to continually have to educate your theme’s users on how to modify their theme because your theme uses weird-ass custom code.
You don’t believe that this is easier than manually coding your theme. And for you or me, you’re probably correct. But you’re not the one having to manually recode your theme. Users who get a theme from elsewhere, who don’t understand HTML in the slightest, are the ones that are stuck have to change some theme code that they don’t understand, merely in order to get plugins to work.
I have two big plugin suites, Simple Facebook Connect and Simple Twitter Connect. Both of them allow people to comment on WP sites by using Facebook or Twitter credentials. But in order for those plugins to work, users have to manually add three simple lines of code to their comments form.
I’ve had to answer how to do that well over 500 times now, to users who simply don’t get it. Quite frankly, I’m sick of it. Standardize already. If you use the comments_form() function in a theme, then your theme’s users don’t have this problem. Both SFC and STC can then hook right into that function and add the button code themselves. No fuss, no muss.
You say the learning curve is too steep. But then are you a theme developer? Do you develop themes for other people to use? If not, then this post isn’t directed at you. If you develop custom sites, then you’re developing custom themes. Probably one use themes. So what do you care anyway? You don’t have to use any of this.
But if you develop themes for other people, then you’d be wise to develop your themes in a way that guarantees maximum compatibility with everything else out there. We have simple standards like including wp_head() and wp_footer(), to provide places for plugins and other bits to hook in and modify the output of the site in order to do various things. This is just another case of that sort of thing, and in this case, it’s one that will simplify your life immensely, if you’re a theme author. Instead of coding a huge complicated form, you can do what you want with one line of code and have the thing instantly working. If you want to modify it, then there’s plenty of hooks and filters and other ways to do so.
And if that’s not good enough, then feel free to code your own form. I can’t stop you. But I can’t recommend your work to other people in that case either.
Themes have been broken, for a long time. This is one more step towards fixing them.
Suppose I add a new custom field to my comment, say a boolean “Agree”. How could I query the comments of a particular post in order to get statistics on how many visitors agree with my blog post?
Adding, say, a checkbox involves two (or three) steps.
1. Add the checkbox. You can do this using the comment_form action without too much difficulty.
2. Save the data. Using the comment_post action, you can see the incoming data from the comment just after it gets saved. In a function hooked to that, you’d want to get the checkbox value via the $_POST array, then save it to the comment metadata using update_comment_meta.
3. Finally, to get a count, you’d query the comment table for how many comments have the meta vs. those that don’t. You’d need a custom query for this, but it’d be easy enough to do.
I’m not sure if it is a silly question or not but… is there anyway I can re-define the default array on functions.php? I’ve been able to customize the fields html with a simple add_filter on funcions.php, easy peasy.
But if I want to change the title_reply attribute (or anything else than the fields html), I’ll have to declare a array on the same file comment_form() is being called? No “cleaner” way?
Use the comment_form_defaults filter. It gets that whole array of defaults.
Otto – thanks for the write up. A lot of it went right over my head, as I’m just starting to look for ways to hack my site, but this tells me that what I want to do is possible. As soon as I have a bit of free time, I’m all over this.
[…] a safe and future-proof way, now: either using the plethora of available hooks, or with a callback. See Otto's great post on comment_form(). WP TurnKey – Turn-Key WordPress installation and maintenance services WordPress user since 2005 […]
Great post! But I’m still a little lost… I want to add a field called ‘Location,’ I added something like this, but it didn’t seem to work…
$fields = array('location' => ' ' . __( 'Location' ) . '' . '',
);
How do I add a new field and then display that field with my comment? I think a simple example of this would be really helpful for a lot of us still trying to figure this out. Thanks!
sorry, I can’t seem to paste my code in here, it cuts some of it out… but a real simple example of adding a custom comment field and then returning its value would be awesome.
Please do not see this as a criticism; I’m an admirer after all.
But, could you please make it clear in the article above what file each cited piece of code can be found/should go into. Perhaps this is what causes developers keep asking you the same questions again and again. It’s taken me quite a while to find out that the bit
$defaults = ...resides in comments.php, whereas
function my_fields($fields) {...}goes into functions.php.
Err… In fact, no, you can put any of that code into comments.php or into functions.php, depending on how you do it. Programming isn’t a matter of copy and pasting, you have to understand how the code works in order to know where to put it.
I tend to like to put things that modify the comments form at the top of the comments.php file of the theme, actually, because then it runs only when the comments form is actually going to be displayed.
Hi Otto,
I’ve tried to follow the instructions but being a PHP Beginner i seem to fall short of my goal.
I simply want to change the name of the ‘Email’ form title and get rid of the verification and delete the ‘URL’ line.
I’ve read other articles about adding $arg or something but the whole, hooks and filters concept is new to me and i can’t get my head around it. I’ve tried modifying the form info in comment-template.php but nothing happens.
Anyone able to help me with this fix?
I have the same problem, I used to be able to edit the old comments.php without problems but this makes no sense to me at all :/
I need to add a paragraph of html above the comment form on one of my sites. I can’t figure it out. I tried putting the array php above comment_form in comments.php, and adding my paragraph to comment_notes_after. But as far as I can tell, inserting the array code there does nothing (I’ve tested several things that should have had immediate results, like removing the list of HTML tags commenters can use). I’m guessing I need to put the array code elsewhere, but have no idea where. Where should the array code go?
And just for the record, I second some of the grousing about this improved solution. Is IS better in many ways, I can see that, and I want to learn it – because some of my best plugins are breaking now unless I use comment_form. I just wish there was a really basic tutorial for those of us who understand HTML, CSS and rudimentary php, but not so much on functions and arrays. I can stick other people’s function codes into my functions.php to avoid having 28 plugins for all the functions I like, but that’s the limit of my skills.
Thanks in advance for any help.
Argh, never mind! I was doing it correctly, but comment_notes_before doesn’t show to logged in users. Which is fine with me – I just didn’t realize. And just in case anyone else is looking for the easy way to add this text, just insert this rather than the comment_form call Otto explained at the start.
'Blah blah your text with any html, etc.' )); ?>This is great Otto, implementing it on a site now. Totally created a child theme just so I could replace the crap comment form with this one, add some conditional implementation based on custom post types, etc. Kudos to you!
I’ve alsotried to follow the instructions but being a PHP Beginner i seem to fall short of my goal.
I simply want to change the name of the ‘Email’ form title and get rid of the verification and delete the I’ve tried to follow the instructions but being a PHP Beginner i seem to fall short of my goal.
I simply want to change the name of the ‘Email’ form title and get rid of the verification and delete the Bruiloft DJ line.
I’ve read other articles about adding $arg or something but the whole, hooks and filters concept is new to me and i can’t get my head around it. I’ve tried modifying the form info in comment-template.php but nothing happens.
line.
I’ve read other articles about adding $arg or something but the whole, hooks and filters concept is new to me and i can’t get my head around it. I’ve tried modifying the form info in comment-template.php but nothing happens.
Okay, I’m going to give you a simple example.
You want to change the “email” line, for example. Instead of “Email”, let’s say you want to change it to “Email, sucker!”. 🙂
function my_fields($fields) { $fields['email'] = str_replace('Email','Email, sucker!', $fields['email']); return $fields; } add_filter('comment_form_default_fields','my_fields');You can add that code into a theme’s functions.php file, or into a plugin of your own creation, or at the top of the comments.php file (which makes the most sense, actually). Whatever. Doesn’t really much matter where it is.