__group__,ticket,summary,owner,_component,_version,priority,severity,milestone,type,_status,workflow,_created,modified,_description,_reporter
Tickets Needing Feedback,12363,Comment permalink wrong when only listing one comment type,wonderboymusic,Comments,3.0,normal,normal,,defect (bug),assigned,dev-feedback,2010-02-24T14:31:51Z,2019-06-04T19:21:46Z,"If you pass the `type` parameter to `wp_list_comments()` (for example, to show comments only and no pings), then comment permalinks can easily use the wrong page number as they expect there to be pings included. This is apparent after leaving a comment and WordPress attempts to redirect back to your new comment.
At first I was thinking you could tell WordPress that you're filtering to a type and it could compensate when determining the page number, but then I realized perhaps it'd just be better for `wp_list_comments()` to check if there were 0 comments returned for the query and if so, see if there are any of that type of comment available. If so, then we know we're on too high of a page number and can instead display the highest existing page. Then again this introduces SEO issues.
Ideas on what to do are welcome.",Viper007Bond
Tickets with Patches,13363,Edit Comments: Pending > Approving shouldn't make them disappear from screen,wonderboymusic,Comments,3.0,normal,normal,Future Release,enhancement,assigned,has-patch,2010-05-11T23:35:45Z,2023-11-16T17:40:18Z,"Edit Comments: Pending > when clicking Approve the comments shouldn't just disappear from the screen.
They should collapse and have an undo status like when you trash or spam a comment.
ENV: WordPress trunk r14573 (3.0-beta2-14565)
",lloydbudd
Unpatched Bugs,13473,comment_status should be set to default_comment_status when commentstatusdiv is removed,westi,Comments,,normal,normal,,defect (bug),reopened,,2010-05-20T23:36:24Z,2019-06-04T19:21:51Z,"When the Comment Status box is removed from the Add/Edit Post screens, posts should be created with the comment_status set to the value of the default_comment_status option.
-----
I had hidden the Comment Status box via:
remove_meta_box('commentstatusdiv','post','normal');
and made sure that default_comment_status was set to open:
update_option('default_comment_status', 'open');
After adding a new post it displayed ""Comments Off"" when I was assuming that it should have honored the value of default_comment_status.",jimmcq
Tickets Needing Feedback,22889,Reconsider no-JS ?replytocom= links,SergeyBiryukov*,Comments,,normal,normal,Future Release,enhancement,accepted,dev-feedback,2012-12-12T15:13:20Z,2023-03-03T07:03:13Z,"We have a no-JS fallback for comment replies. Normally JS moves the comment form around. For people with JavaScript disabled, they follow the `?replytocom={123}` link. This results in a lot of extra crawling by search engines (potentially an additional crawl per reply-able comment!) in exchange for enabling an awkwardly executed, likely underused, and non-essential feature for non-JS users.
I'd like to consider making comment reply JS-only.",markjaquith
Tickets with Patches,30979,Check for context menu before closing commentReply,SergeyBiryukov*,Comments,,normal,normal,Future Release,enhancement,accepted,has-patch,2015-01-11T14:40:41Z,2021-08-27T13:34:20Z,"Login to WP-Admin, go to the comments section and ""Quick edit"" or ""Reply"" to a comment.
Bring up the context menu either with a right-click or the menu key, press ESC and the context menu and the comment box will close.
[[Image(https://i.imgur.com/xnhrZDr.png)]]
I understand that this is the expected behaviour but this can be frustrating at times.
If you bring up the context menu while typing a long reply but decide not to autocorrect and press ESC to close the context menu everything you've typed so far is gone :(
The ""Compose email"" section of both Gmail and Outlook.com close themselves when ESC is pressed but don't if the context menu is open. So I thought WordPress should also have the same behaviour.
The patch checks for a right click or menu key press before doing `commentReply.revert()`.",jesin
Unpatched Enhancements,56261,Normalize comment function parameters with mixed case names,SergeyBiryukov*,Comments,,normal,normal,Future Release,enhancement,accepted,,2022-07-20T16:30:32Z,2023-02-08T14:39:53Z,"Background: #56244
As of WordPress 2.9, core normalizes the `user_ID` parameter to `user_id` when passing data to comment functions, see [12267], [12300], and [28915].
We should consider normalizing other parameters in the same way as it was done for `user_ID` → `user_id`:
* `comment_ID` → `comment_id`
* `comment_post_ID` → `comment_post_id`
* `comment_author_IP` → `comment_author_ip`
Then any combination of these parameters would work regardless of the case.
This would allow extenders to name variables in accordance with the WordPress coding standards:
* `$comment_id`
* `$comment_post_id`
* `$comment_author_ip`
and use them subsequently in a `compact()` call without having to worry about a case mismatch.
This would also allow us to revert some of `compact()` rearrangements made in [53719] and [53723]:
{{{
$compacted = array(
'comment_post_ID' => $comment_post_id,
'comment_author_IP' => $comment_author_ip,
);
$compacted += compact(
'comment_author',
'comment_author_email',
'comment_author_url',
...
'user_id'
);
}}}
which could then be:
{{{
$compacted = compact(
'comment_post_id',
'comment_author',
'comment_author_email',
'comment_author_url',
'comment_author_ip',
...
'user_id'
);
}}}
The list of functions this may affect:
* `wp_insert_comment()`
* `wp_new_comment()`
* `wp_update_comment()`
* `wp_filter_comment()`
* `wp_handle_comment_submission()`",SergeyBiryukov
Tickets Needing Feedback,17771,URL-encoded comment_author_url gets broken by MySQL varchar 200 length limit,SergeyBiryukov,Comments,3.2,normal,normal,Future Release,defect (bug),reviewing,dev-feedback,2011-06-12T03:46:44Z,2017-03-18T17:38:56Z,"!WordPress sometimes pings back with long permalinks that exceed comment_author_url column length limit of 200, which results in generating unusable broken links to the post.
It easily reaches to the limit, especially if the permalink contains url-encoded multibyte title as postname. (e.g. 23 characters of UTF-8 Japanese become a 207 characters long url-encoded string. Incomplete url-encoded string may trigger 400 Bad Request too.)
'''Solution:'''
In pingback(), use shortlink instead of regular permalink if the URL is longer than 200 characters.
It seems to work ok with wp.me shortlinks.",tenpura
Tickets Needing Feedback,34475,get_comment_link incorrect page number in returned url.,SergeyBiryukov,Comments,4.3.1,normal,normal,Future Release,defect (bug),reviewing,needs-unit-tests,2015-10-28T16:36:42Z,2019-10-03T22:15:05Z,Since 4.3 core update the get_comment_link function returns incorrect page numbers for paginated comments. Have tried using default twentyfifteen theme with no plugins enabled and issue still persists.,Property118
Tickets Needing Feedback,33735,Reduce Duplication and Improve Comment Notification Email Functions,SergeyBiryukov,Comments,,low,normal,Future Release,enhancement,reviewing,needs-unit-tests,2015-09-04T22:55:04Z,2021-01-27T19:20:55Z,"Had touched on this in #33587.
wp_notify_postauthor and wp_notify_moderator have some duplicative code that could be eliminated and simplified.
The functions for notification also lack a filter similar to the one for displaying the comment text.
Proposing the function to show the comment in text form in the notification be separated out into its own function with a filter, and the default text be improved somewhat.
",dshanske
Tickets Needing Feedback,10653,Update comment_author when display_name changes,SergeyBiryukov,Comments,5.1,normal,normal,Future Release,enhancement,reviewing,dev-feedback,2009-08-19T19:43:29Z,2021-04-05T12:31:54Z,One thing that has bothered me recently is the fact that your previous comments doesn't get updated when your display_name is being updated. Which could cause some confusion. I wrote a function (see attached file for further reference) that takes care of this but I would love to see a similiar feature in the WordPress core.,mptre
Tickets with Patches,45498,Wrong order of arguments in call_user_func() for Walker_Comment::start_el(),SergeyBiryukov,Comments,,normal,normal,Future Release,defect (bug),reviewing,needs-unit-tests,2018-12-06T16:52:14Z,2019-01-16T05:46:01Z,"Arguments order for rendering all types of comments is `$comment, $depth, $args` except for the custom callback:
`call_user_func( $args['callback'], $comment, $args, $depth );`
This causes every custom callback to throw an error when you use `$args` and `$depth` as you'd expect.
For example, `comment_reply_link()` inside callback can not be used like it's suppose to be used, like so:
{{{#!php
'div-comment',
'depth' => $depth,
'max_depth' => $args['max_depth'],
'before' => '
',
'after' => '
'
) ) );
}}}
You need to replace `$depth` and `$args`, like so:
{{{#!php
'div-comment',
'depth' => $args,
'max_depth' => $depth['max_depth'],
'before' => '',
'after' => '
'
) ) );
}}}
",milana_cap
Unpatched Enhancements,41731,Make it Easier to Locate Restored Comments,SergeyBiryukov,Comments,4.8.1,normal,normal,Future Release,enhancement,assigned,,2017-08-25T19:30:34Z,2019-06-21T17:56:20Z,"When a comment is in the trash, WordPress does not allow you to edit its details without restoring it first. After restoring the comment, it disappears from the Trash and the user is then required to locate it either by memorizing the post it's on or searching for it in the backend. It doesn't show up on the approved comments page because of its original published date.
I suggest that if a single comment is restored, it takes users to the post it's on. Even better would be taking the user straight to where the comment is in the Discussions meta box. However, since users can hide this meta box via the screen options, I'm unsure how to account for that.
Perhaps redirecting users to the post where the comment is displayed is enough?",jeffr0
Candidates for Closure,43298,Add filter to hide comment types from showing up in the default query,schlessera,Comments,,normal,normal,Awaiting Review,enhancement,assigned,dev-feedback,2018-02-12T15:05:23Z,2019-01-16T06:50:09Z,"Comment types are not something WordPress supports by default. However, there is some data and API support for it. The `wp_comments` table contains a `comment_type` column which can be used for this purpose. The big downside is that by default these will be shown in all comment overview. Both on the frontend and the backend.
There are plugins that already do this. The examples that triggered this ticket are [https://github.com/woocommerce/woocommerce/blob/d2e9b366121166c7cb26936bd2c251f3dd7ebd5d/includes/class-wc-comments.php#L110 WooCommerce] and [https://github.com/WordPress/gutenberg/pull/4685/files#diff-df5e27f1866a42a0c24ae7c0b17b1bc6R496 this PR on Gutenberg]. These plugins use the `where` clause in the pieces of the query to make this possible.
I propose we add a 'simple' filter that can hide specific comment types from view. If `comment_type` is not queried in any other way, this blacklist will make sure that all comment types in the blacklist are not returned from the query.
'''Why not wait for full comment_type support?'''
Full `comment_type` support is a much bigger effort. This filter would benefit us in the short run and doesn't conflict with full `comment_type` support.",atimmer
Unpatched Bugs,39566,WordPress ignoring previously approved comment for some comment authors,rachelbaker,Comments,4.7,normal,major,Future Release,defect (bug),assigned,needs-unit-tests,2017-01-12T15:41:04Z,2018-10-08T02:36:17Z,"I seem to have a reproducible bug with the option ""Comment author must have a previously approved comment"".
My client has a site that heavily uses guest commenting. They have selected the option ""...must have previously approved comment"". This works well most of the time, however more frequently some guests (identified by email) are being flagged as not having a previously approved comment even though they do. For one author (email) in question I am able to replicate this every time.
- All other possible comment moderation disabled.
- Comment as the guest in question, comment moderated.
- Log in as admin, approve the comment.
- Comment a second time as the guest, comment moderated again (shouldn't be)
- Disable the option ""must have previously approved...""
- Comment a third time, now the comment is approved automatically.
- Re-enable option ""must have previously approved...""
- Comment a forth time, the comment is moderated.
This appears to be a bug to me, and I can reproduce it every time. Not sure how to troubleshoot this further from here.",rperrett
Candidates for Closure,50538,WP_Comments_List_Table should not show views that have a count of 0,pbiron,Comments,,normal,normal,Awaiting Review,enhancement,assigned,dev-feedback,2020-07-02T17:14:28Z,2021-03-12T11:00:37Z,"Other core list tables that have a get_views() method do not output a view if the count for that view is 0, e.g., `WP_Posts_List_Table` doesn't output ""Pending (0)"" if there are no posts with $post_status === 'pending').
However, `WP_Comments_List_Table` does output ""Pending (0)"" if there are no pending comments.
For consistency's sake, I think `WP_Comments_List_Table` should skip views with count of 0.
Related: #47495",pbiron
Tickets with Patches,54149,Audit `get_comment()` response checks.,hellofromTonya,Comments,5.9,normal,normal,Future Release,defect (bug),assigned,has-patch,2021-09-21T02:14:44Z,2022-09-27T16:55:50Z,"There are currently 164 calls to `get_comment()` across 36 files in the codebase (see attached file), with more pending with at least one upcoming PR.
Some of these calls check the response of `get_comment()` in one of the following ways:
{{{#!php
comment_ID ) {...
if ( ! empty( $comment->comment_ID ) {...
}}}
Some do not check the response at all. A [https://wordpress.slack.com/archives/C02RQBWTW/p1630738445035900 discussion on Slack] between myself and @jrf led to the suggestion that we audit the use of `get_comment()`.
@hellofromtonya suggested two alternative checks on the response:
{{{#!php
I think it'd be a nice enhancement for comment forms in both the admin and front end to submit this way.
However, the r45790 introducing the feature does so only for frontend. Submitting comment by pressing ctrl/cmd + 'enter' does not seem to be working in wp-admin.
It would be cool if the new feature could be added to wp-admin as well.",david.binda
Tickets with Patches,23634,New hook for adding content after each comment,chriscct7,Comments,,normal,normal,Future Release,enhancement,assigned,has-patch,2013-02-26T19:29:57Z,2017-10-23T14:56:06Z,"Similar to #18561 (which is for a new ""after post"" hook) add a hook that fires after each comment output with {{{wp_list_comments}}}.",lancewillett
Tickets with Patches,22198,Realigning the Discussions Settings page,chriscct7,Comments,3.4.2,normal,normal,,enhancement,assigned,has-patch,2012-10-15T14:50:34Z,2019-06-04T19:23:31Z,"[I looked for some tikets for this but didn't find any directly related, so hopefully I haven't missed a big one out there floating around.]
The Discussions Settings page (options-discussion.php) always trips me up when setting up a new site. There's a lot of options, descriptions, directions, etc on that page — much of which is probably unavoidable. When I visit it, I always think that the hierarchy isn't quite right.
To help with this, I thought of two half-measures.
1. A very simple solution:
Put the ""Allow people to post comments on new posts"" at the top of the options list, with a little space below it. That would make that option the most prominent on the page, without making it stand out too much.
Like this:
[[Image(http://f.cl.ly/items/3e0c062W0N1l3J2D0q0Y/Screen%20shot%202012-10-15%20at%2011.56.02%20AM.png)]]
2. A more involved solution:
I really like the new click-to-reveal-the-options at work in the ""Page on Front"" (#16379) workflow and thought it might work well here.
*Something* in this direction:
[[Image(http://f.cl.ly/items/022A1G3k0O3q0g1u380L/Screen%20shot%202012-10-15%20at%2012.12.09%20PM.png)]]
The first could be accomplished for 3.5, but the second re-working could be a further down the line item.
",saltcod
Tickets with Patches,35075,Comment cache ignores custom query vars,boonebgorges,Comments,,normal,normal,,defect (bug),assigned,has-patch,2015-12-14T14:41:42Z,2020-03-06T01:08:10Z,"It's currently very possible to add custom query vars to the get_comments function, for themes and plugins to extend. A problem occurs, however, if the function is being used and a custom query var is being used, but no standard ones are changing. This is because it caches the first query, and every subsequent query is then assumed to be the same since custom query vars are ignored.
I first thought about just using the entire query_vars array for caching, but decided there's probably a reason this wasn't done. So instead I decided it would make the most sense to make a filter for the cache keys so a plugin/theme can add its own keys that should be considered for caching.",jason_the_adams
Tickets with Patches,11248,Paged wp_list_comments() should always output something,boonebgorges,Comments,2.9,normal,normal,,defect (bug),assigned,has-patch,2009-11-24T06:00:23Z,2019-06-04T19:21:40Z,"Enable comment paging on your blog and visit `http://yourblog.com/a/single/post/comment-page-999999/`. Note no comments will be displayed.
There's situations where the comment form will redirect you back to the wrong page (for example if you mess with the type parameter and exclude pings). The Walker should detect if there's no comments to be displayed on the requested page and if that's the case, then display the latest page that actually has comments.",Viper007Bond
Unpatched Bugs,35805,Reverse page order in wp_list_comments() with newest comments first,boonebgorges,Comments,4.4.2,normal,normal,,defect (bug),reviewing,needs-unit-tests,2016-02-12T00:21:26Z,2019-06-04T19:34:45Z,"Hey there,
since wp 4.4 there were lots of bugs in the wp_list_comments()-function. Some of them are already fixed, now I found another one.
If you change the comments order from default (oldest first) to newest first, the page order is wrong (reverse page order).
== Example ==
You have 4 pages by sending following param you get these pages:
{{{
page=1 -> 4
page=2 -> 3
page=3 -> 2
page=4 -> 1
}}}
== How I call this function ==
Inside the post-loop I'm calling:
{{{#!php
}}}
And comments-content.php has following part:
{{{#!php
$cpaged, // Variable defined before, default: 1
'per_page' => 2
) );
?>
}}}
PS: In ticketing system the version 4.4.2 is not available :-)",Ninos Ego
Unpatched Bugs,31188,Very slow query in comments_template -> get_comments -> WP_Comment_Query->query,boonebgorges,Comments,4.1,normal,normal,,defect (bug),assigned,,2015-01-31T02:01:45Z,2019-06-04T19:27:50Z,"In my quest to improve performance of core Wordpress functionality (see #31071, #31072, and #31171), I'm back with another optimization that is quite significant for large WP installations with lots of comments on some posts.
The query in question:
{{{
# Query_time: 25.314234 Lock_time: 0.000074 Rows_sent: 10 Rows_examined: 699220
SET timestamp=1422666393;
SELECT wp_comments.* FROM wp_comments WHERE comment_post_ID = '87814' AND comment_approved = '1' ORDER BY comment_date_gmt DESC LIMIT 10;
}}}
As you can see, 25s is not great to say the least. The query isn't using an optimized index, which I've now created, at which point it started running in milliseconds.
The index is as follows:
{{{
CREATE INDEX `comment_post_ID_approved_date_gmt` ON `wp_comments`(`comment_post_ID`, `comment_approved`, `comment_date_gmt`);
}}}
I've verified the performance improvements using SQL_NO_CACHE as well as EXPLAIN.
The post in question here had over 3000 comments, which isn't uncommon on our site (androidpolice.com).
Interestingly, MySQL queries using a different strategy internally which isn't nearly this slow for posts with fewer comments. But at some point, it switches it up because it thinks it's better, and things go sour.",archon810
Tickets with Patches,35501,"Dashboard page: incorrect work of ""Activity"" group box bottom counters",adamsilverstein,Comments,4.4.1,normal,normal,Future Release,defect (bug),assigned,has-patch,2016-01-17T21:22:17Z,2019-01-10T22:26:26Z,"STEPS TO REPRODUCE
Create new post, add comment through front end, go to dashboard page, click showed up menu items Approve/Unapprove/Spam/Trash in different combinations:
- click ""Approve"" and quick click ""Trash"",
- click ""Unapprove"" and quick click ""Trash""
- quick click ""Approve"" twice
EXPECTED RESULT: bottom counters ""All"", ""Pending"", ""Approved"", ""Spam"", ""Trash"" counts correct.
ACTUAL RESULT: see attachment.",antonrinas
Tickets Awaiting Review,18630,Custom Comment Validation Error,,Comments,3.3,normal,minor,Awaiting Review,feature request,new,has-patch,2011-09-09T19:49:33Z,2022-07-15T15:49:43Z,"One of the things that bugs me about WordPress is not being able to customize the wp_die() function that is called on comment form validation. I have seen some people sugget core hacks, eek. I'm hoping that a hook is added to allow overriding of the default wp_die(). Maybe even a new template file wp_error.php that would be called first.
I haven't found a lot of discussion on this in trac just #11286 and #10551",bandonrandon
Tickets Needing Feedback,20977,Add Dynamic Comment Statuses,,Comments,3.4,normal,normal,Future Release,enhancement,new,dev-feedback,2012-06-15T17:12:07Z,2020-01-14T02:35:50Z,It would be great to add some filters/actions that would allow plugin developers to add additional statuses to comments.,supercleanse
Tickets Needing Feedback,16365,Comment transition for new comments,,Comments,3.1,normal,minor,,enhancement,new,needs-docs,2011-01-24T21:07:46Z,2019-06-04T19:22:11Z,"As far as I can tell wp_transitions_comment_status() does not get called for new 'comments' based on my testing and review of comment.php in wp-includes.
There is a similar transition for posts that gets called for new 'posts' including hooks like 'new_to_publish' and 'new_to_private'.
I feel that there should be a similar hook to this form comments so that plugins can hook into new comments differently from comments moved from one existing status to another (like comment_unapproved_to_approved'.",MattyRob
Tickets Needing Feedback,22579,Confusion of WP admin Discussion settings,,Comments,,normal,normal,Future Release,enhancement,new,,2012-11-24T20:46:05Z,2019-11-05T13:26:24Z,"On the ""Settings>Discussion"" page:
1) ""'''Default article settings'''"" should be replaced by ""'''Default comment settings'''"" (because these important settings do not only apply to posts (''articles'')), but also to pages!
2) ""'''Allow people to post comments on new articles'''"" should be replaced by:
--> ""'''Allow people to post comments'''"" (best option in my opinion)
or
--> ""Allow people to post comments on new pages and posts""
Sorry if this is not the right place to make such suggestions.",Lorangeo
Tickets Needing Feedback,22164,"Move comment ""keyboard shortcuts"" setting to comments -> screen options",,Comments,,normal,normal,,enhancement,new,dev-feedback,2012-10-11T14:14:23Z,2019-06-04T19:23:27Z,"Seems like it would make more sense to move the comment ""keyboard shortcuts"" setting from ""Your Profile"" to the screen options pane of edit-comments.php. Something like:
[[Image(http://f.cl.ly/items/1k210Z2V1o0b350I1n0V/keyboard-shortcuts.jpg)]]",lessbloat
Tickets Needing Feedback,23179,New avatar related option - use gravatar only for registered users,,Comments,,normal,normal,,enhancement,new,dev-feedback,2013-01-11T15:40:59Z,2019-06-04T19:23:48Z,"The use of gravater is problematic because there is no attempt to verify that a comment with which an email was used was actually left by the owner of the email (AFAICT gravatar doesn't even have an API for authentication).
This makes impersonating to someone else that have a gravatar in a wordpress site comments much too easy.
IMO non autogenerated gravatars should be displayed by default only for users for which it is known that they actually own the email address, which are usually only the registered users.",mark-k
Tickets Needing Feedback,17913,Site-level comment options may override individual post settings. Improve help/docs.,,Comments,,normal,normal,Future Release,enhancement,new,has-patch,2011-06-27T20:46:43Z,2019-11-18T18:11:40Z,"Post comments may be automatically closed for a site's posts if site option 'close_comments_for_old_posts' is true and the post was published before 'close_comments_days_old' days ago. These two options are set in options-discussion and override the 'comment_status' of an individual post.
The edit posts screen's comment meta box displays comments open/close status, allowing publishers to open or close comments for a single post. It's possible the site-level discussion settings will override the individual post yet we still might display a different post comment status than the site settings allow.
1. Enable site-level option to close comments on articles ( wp-admin/options-discussion.php#close_comments_for_old_posts )
1. Enter a days value of 1 for maximum impact
1. Edit a post published over a day ago
1. View the Discussion meta box ( #commentstatusdiv )
1. Interact with the 'comment_status' field
I would like to better communicate expected failure and let the post author or editor know this particular setting has been overridden at the site options level. If the current user can manage options I might you could link to the override in the options page.
I created a new test blog, set comments to auto-close after a day, and checked allow comments in the post screen. I was wondering why comments_open() was false for the post when I was looking at a checked box on the post screen.",niallkennedy
Tickets Needing Feedback,16252,Allow comment reparenting to fix poor threading,,Comments,,normal,normal,Future Release,feature request,new,has-patch,2011-01-15T23:12:25Z,2023-11-23T06:26:37Z,"For the OCD among us, it would be super nice to be able to edit the comment_parent, to properly thread comments made in the wrong place/threading order.
Choose your own UI, but even just a numeric editor in the Quick Edit area would be a huge enhancement.",Otto42
Tickets with Patches,12104,'moderate_comments' capability by itself should grant the user the permission to See/Edit all comments from the Comments menu.,,Comments,3.0,normal,normal,Future Release,defect (bug),new,has-patch,2010-01-31T22:25:24Z,2021-11-08T19:10:31Z,"I tried to create a Comment Moderator role today and realized it wouldn't work. My intention was to create a role for people who can't write or edit posts, but can keep an eye on the comment threads. I created the role like so:
{{{
#!php
add_role('moderator', 'Moderator', array(
'read' => 1,
'moderate_comments' => 1,
));
}}}
... then created a new user with that role. When I logged in as my test user, I realized that it was for all intents and purposes a Subscriber. I couldn't see any admin panels but the Dashboard, my profile, and the Tools. I went poking around in edit-comments.php and discovered that it's checking for another capability altogether:
{{{
#!php
if ( !current_user_can('edit_posts') )
wp_die(__('Cheatin’ uh?'));
}}}
I double-checked wp-admin/includes/menu.php and it agreed that 'edit_posts' was the minimum capability to see this page, so I tried adding 'edit_posts' to my new role, and I still couldn't get there.
Later on in edit-comments.php, when actually trashing a comment, there is a check for 'moderate_comments', but it's a moot point: this screen doesn't even show up in the admin menu, and if you navigate directly to it, you'll get the ""You do not have sufficient permissions to access this page"" message.
I thought it was entirely possible I'd missed some finer point of creating roles, so I redid it with Justin Tadlock's excellent Members plugin, and that didn't work either.
This behavior might be intentional, but if so, I'm not following the logic. I know roles are due for an overhaul in the next version or two.",sillybean
Tickets with Patches,26596,Edit comments from wpAdmin don't process well radio button fields,,Comments,2.7,normal,normal,,defect (bug),new,has-patch,2013-12-13T08:38:04Z,2019-06-04T19:24:43Z,"I'm filtering for 'wp_comment_reply' to add a custom radio button selector in the wpAdmin comments.
Then the ajax request don't send this field value, always send the last one, checked or not.
wp-admin/js/edit-comments.js process all INPUT fields as a text (except type button)
I attach the patch to allow radio buttons but doesn't works for checkbox.",corretge
Tickets with Patches,13792,Invalid reply link from comment admin when comment nested level > max,,Comments,2.9.2,normal,normal,Future Release,defect (bug),reopened,needs-unit-tests,2010-06-09T07:05:56Z,2017-07-31T16:17:39Z,"I have a blog with nested comments enabled, max depth of 4. When the last level comment is posted, it no longer contains a Reply link.
However, in the Comment admin, the Reply link is still present. If used, this new reply will show up at the very bottom of the comment list once posted (even if other newer regular comments are entered, this new reply will still show up at the very bottom).
The bug is, basically, that Comment admin doesn't respect the max nested value.",archon810
Tickets with Patches,22301,Performance problem with Recent Comments widget,,Comments,2.8,normal,normal,,defect (bug),new,has-patch,2012-10-29T06:07:14Z,2019-06-04T19:23:37Z,"When a comment is posted (or the status of a comment changes), the `widget_recent_comments`cache item is invalidated, which the Recent Comments widget uses to populate the widget content. On the next widget display, it will call `get_comments()` to repopulate the cache.
The problem occurs when you have a very large number of comments, the MySQL query will use the `(comment_approved, comment_date_gmt)` index, but if MySQL has to scan too many rows in an index, it'll switch to table scan instead. As the `comment_approved` column is mostly the same value, this will almost always happen. This is compounded by the query occurring on every page load until the cache is re-populated - if the query takes 60 seconds to run, there could potentially be hundreds of instances of the same query running.
So, we need a solution that either hides or eliminates how slow this query can be, and only runs it (at most) once per new comment.
After discussing this with @matt, we have a couple of ideas:
1. Move this query to a `wp_schedule_single_event()` call, which has the bonus of ensuring only one is scheduled at any given time. The downside is that it may cause the cache to be outdated on a low traffic site.
2. Keep a queue of recent comments in cache, and push a new one onto the queue when posted. This avoids the query entirely, but there would be a race condition if two comments were posted at nearly the same time - one of them could be left out of the queue entirely.",pento
Tickets with Patches,20302,Allow comment_form() to add attributes to