Comment “allowed” checks in WordPress 4.7

In WP 4.4, comment submission was abstracted so that most of the logic was run in a function that returned a value, rather than inline in wp-comments-post.php. See #34059 for background. This overhaul was incomplete: the process of checking for comment floods and duplicate comments – wp_allow_comment() and friends – contained direct calls to die() and wp_die(), making it impossible to use the results of a failed comment check in the context of unit tests, the REST API, or other clients. See #36901. [38778] introduced an optional parameter for wp_allow_comment() and related functions that lets the caller decide whether to preserve the default behavior (wp_die()) or, instead, to return WP_Error objects in the case of failed comment checks.

There is a small backward-incompatible change in [38778]. Historically [5947] it’s been possible to unhook the default comment flood check as follows:

remove_action( 'check_comment_flood', 'check_comment_flood_db', 10, 3 );

In order to maintain backward compatibility with this usage, while at the same time changing the comment flood check so that it returns a value, we’ve performed a trick: check_comment_flood_db() is still hooked in the same way, but is now a wrapper for an add_filter() call that hooks the actual comment flood checking function to the new 'wp_is_comment_flood' filter.

The backward compatibility break is as follows. Calling check_comment_flood_db() directly, in isolation, will no longer do anything (except to register a filter callback). If you need to run WP’s default comment flood check manually, outside the context of wp_allow_comment(), use the new wp_check_comment_flood() function. I searched GitHub and the plugin repo and didn’t find a single instance check_comment_flood_db() being used this way in the wild – it’s hard to imagine a situation where it’d be done, given its previous reliance on wp_die() – but if you’ve done custom work related to comment floods, it’s worth double-checking your code before 4.7 is released.

#4-7, #comments, #dev-notes

Comments in 4.6 can now be cached by a persistent object cache

The ‘comment’ cache group was made non-persistent in [7986], to address the difficulty of reliable cache invalidation. This meant the comment cache values were only held for the current page load, and lost on reload or navigation. The comment API has improved since WordPress 2.6, and cache is king.

In WordPress 4.6 the ‘comment’ cache group has been removed from the list of non-persistent cache groups, see [37613]. When comments are added, modified, or deleted we properly invalidate out of date cache values. You can now cache with confidence.

If you have a plugin which modifies comment data directly please change them to make use of the various comment API functions or use clean_comment_cache().

Don’t miss out on this change. For more background on the change, see #36906.

#4-6, #comments, #dev-notes

Comments Bug Scrub Summary, 2016-05-09

The 90-minute bug scrub took place in #core-comments and ended in a 1 – 1 tie between @boonebgorges and @rachelbaker. You can read an archive of the bug scrub and discussion:

@rachelbaker, @boonebgorges, @aaroncampbell, @ocean90, @samuelsidler, @sidati, @presskopp, and @dshanske

Bug Scrub:
#6342 – moved to “Future Release”
#16365 – moved to “Future Release”
#16576 – moved to “Future Release” and needs testing for backwards compatability
#17913 – needs a refresh and screenshots
#18762 – closed, after testing confirmed this was resolved in 4.4
#26596 – moved to “Future Release” to limit the scope of the JS selector
#20302 – moved to “Future Release”, with suggestion from @boonebgorges
#20977 – moved to “Future Release”, but needs more input to determine how to approach

Open Floor:
#36427 – milestoned for 4.6, needs a refresh for the inline docs
#36564 – needs additional exploration before we can decide how to store the data/time of when a comment was last modified
#36424 – moved to “Future Release”, and requested a patch refresh and screenshots
#36409@sidati is going to attempt writing the unit tests

#4-6, #comments

Comments Component Bug Scrub – May 9, 2016

A bug scrub focused on open tickets in the Comments component will be held in the #core channel on Slack at May 9, 2016 19:00 UTC.

Meeting Goals

  1. Give attention and feedback to the tickets gathering dust in the Awaiting Review milestone
  2. Reduce the number of tickets in the Awaiting Review milestone to 20 (currently at 37)
  3. Have an open floor for anyone to request feedback for any Comments component ticket

If you have a ticket you want included in the open floor feedback leave a comment below. I promise to “read the comments”.

#4-6, #bug-scrub, #comments

Comment Changes in WordPress 4.5

WordPress 4.5 includes several ancient bug fixes and a few enhancements in the Comments component. We have closed 25 tickets. Check out the full list of changes.

Moderate Comment Screen Refresh

This often neglected screen has received a UX update. Don’t know what the “Moderate Comment” screen is? This is where you land when clicking one of the moderation actions from a comment notification email message.

Changes of note:

  • Comment content is formatted for display, instead of one massive block of escaped text
  • Include navigation via a text link to the Edit Comment screen at the bottom of the comment
  • Updated message styles that match other screens
  • Only wrap the comment date in a link if the comment permalink exists to avoid confusion
  • Appended #wpbody-content to the comment email message links for accessibility


See #34133

Max Lengths for Comment Form Fields

Be verbose without having to worry that your insightful words will be lost.

The comment form will now enforce the maximum length of each field’s respective database column with hardcoded maxlength attributes. The hardcoded maxlength attributes can be adjusted for custom database schemas by using the comment_form_default_fields filter.

The default length settings are as follows:

  • Comment: 65525 characters
  • Name : 245 characters
  • Email: 100 characters
  • Url: 200 characters

Comments will also have the input lengths checked by the new function wp_get_comment_fields_max_lengths(), and accompanying filter wp_get_comment_fields_max_lengths, upon submission returning a WP_Error object if any value is longer than its database column.

See #10377.

Comment Error Page Navigation

Previously, visitors who submitted a comment that was unable to be processed were shown an error message without a method to navigate back to their comment. Your potential commenter would have to use their browser’s back button to get back to their comment to resolve the error.

A simple back link has been added to the bottom of the error message page. See the screenshots below.



See #4332.

Other Changes of Note

  • The rel=nofollow attribute and value pair will no longer be added to relative or same domain links within comment_content. See #11360.
  • WP_Comment_Query now supports the author_url parameter. See #36224.
  • The new pre_wp_update_comment_count_now filter allows you to bail out of updating the comment count for a given Post. See #35060

#4-5, #comments, #dev-notes

Comment Object and Query Features in 4.4

Without comments, a website is as effective at creating a community as the Chicago Cubs are at winning World Series titles. WordPress 4.4 is a rebuilding release and the comments system is much improved under the hood.

This release lays the groundwork for future features and improvements.

A New Classy and Strong Comment Object

The new WP_Comment class provides a single organized comment object that models its row in $wpdb->comments. You may be familiar with this approach from WP_Post, which inspired the caching implementation used in WP_Comment.

This was a prerequisite to many of the other comment-related bug fixes and features added in 4.4. The WP_Comment class is marked final to retain flexibility while it is young.

See #32619.

Comment Queries for the Whole Family

WP_Comment_Query has new query parameters for traversing your comments family tree.

  • parent__in takes an array of comment parent IDs to return all matching children.
  • parent__not_in takes an array of comment parent IDs and does not return any matching children.
  • hierarchical can be set to either threaded, flat, or false.
    • threaded returns a tree for matched comments, with the children for each comment included in its children property.
    • flat returns a flat array of matched comments plus their children.
    • false does not include descendants for matched comments. This is the default behavior.
  • orderby has a new option comment__in, useful when querying by comment__in the matched results will return in the same order.

See #8071 and #33882.

#4-4, #comments, #dev-notes

Changes to fields output by comment_form in WordPress 4.4

A change in WordPress that just landed in trunk is to move the comment textarea to the top for logged-out users when replying. This is done largely with the goal to improve keyboard/focus navigation, but also aims to make it easier for end users to leave comments on WordPress sites. The change necessitated some filters and actions now being run in a different order. It also means that the HTML output by comment_form will now be different.

This is what the comment form looked like before

This is what the comment form looked like before

This is what the comment form looks like after.

If you use any of the hooks inside comment_form, but especially comment_form_field_comment and comment_form_after_fields, you are highly encouraged to test your code against the current WordPress nightly and report any issues on ticket #29974 so that any necessary adjustments can be made. Visual records and example code will help ensure everyone is satisfied with the final result.

#4-4, #comments, #dev-notes

Today in the Nightly: Site icons in the customizer, editor patterns, more accessible comment bubbles, row toggle focus styling

Install the nightly, and try out this fresh batch of shiny.

Site Icons in the Customizer

I’ve long wanted site icons in the customizer alongside site title and tagline. The identity information that I always want to edit when first setting up a site are now all together in the customizer.

For more visuals, see these visual records.

See #16434.

Editor Patterns

Create bulleted lists, ordered lists, and blockquotes using markdown like patterns. I find this particularly handy on phones when the editor toolbar is offscreen.

Screen Shot 2015-07-14 at 4.39.12 PM

See #31441.

Better focus styling for list table row toggles

See #32395.

Better accessibility and design for the comments bubble

The comments columns in our list tables were among the most confusing for screen reader users. Accessibility and visuals are now improved.

See #32152.

Eliminate content overruns on small screens

An audit of content overruns on small screens resulted in many fixes.



See #32846.

Styling improvements on small screens for Right Now in the network admin

See #32962.

Improved header information in Network Admin Edit Site tabs

  • Use the site’s name rather than URL in the Edit Site header.
  • Provide “Visit” and “Dashboard” links for the site on all tabs.



See #32525.

Disambiguate “Automatically add new top-level pages to this menu”

In the customizer, a menu’s auto-add pages option is now separated from the preceding menu location checkboxes.

See #32820.

 Passwords UI Improvements

Passwords received a couple of improvements. The show/hide toggles look better, and passwords ui is on the install screen. Passwords on the install screen still needs a little more flow work.

See #32589 and #32925.

For more visuals, see these visual records.

Reduce link noise in media library list view

This is visually subtle but removes confusion for screen readers.


See #32254.


Previously: Today in the Nightly: Customize in the Toolbar, Passwords UI, List Tables on Phones, Dashicons

#accessibility, #bubbles, #comments, #content-overrun, #customize, #edit-site, #editor, #list-tables, #media, #menus, #multisite, #network-admin, #right-now, #site-icons, #today-in-the-nightly

Comments are now turned off on pages by default

In [33041] and [33054] for #31168, we’ve turned comments off on new pages by default.

I know many of you have done the “make a bunch of pages, fill them out, realize comments are turned on, go back into the admin, turn off comments” dance. Now when you make a page, you won’t have to manually turn off comments — it’ll match the expected behavior of being off by default.

In addition to pages, this functionality has been extended to all custom post types. Post registrations that don’t explicitly add support for comments will now default to comments being off on new posts of that type (before, they defaulted to on). Up until now, post type support for comments has only affected admin UI; a developer could omit comment support on registration but still allow comments to be posted. This is a change in behavior, and we will be closely monitoring its effects during beta. Moving to explicit support will allow core behavior to be more predictable and robust in the future, but we will always consider real-world usage.

In trunk, you’ll notice two new things: the get_default_comment_status() function, which accepts the post type and comment type as arguments (both optional), and within it a get_default_comment_status filter, which receives the status, post type, and comment type as arguments. If you’ve been directly checking options such as with get_option( 'default_comment_status' ), you will likely want to replace those calls with get_default_comment_status(). We recommend explicit registration of post type support for comments, but as an example of using the filter, you can restore current behavior using the following:

 * Filter whether comments are open for a given post type.
 * @param string $status       Default status for the given post type,
 *                             either 'open' or 'closed'.
 * @param string $post_type    Post type. Default is `post`.
 * @param string $comment_type Type of comment. Default is `comment`.
 * @return string (Maybe) filtered default status for the given post type.
function wpdocs_open_comments_for_myposttype( $status, $post_type, $comment_type ) {
    if ( 'myposttype' !== $post_type ) {
        return $status;

    // You could be more specific here for different comment types if desired
    return 'open';
add_filter( 'get_default_comment_status', 'wpdocs_open_comments_for_myposttype', 10, 3 );

#4-3, #comments, #dev-notes, #post-types

Trying to decide what to do with comment …

Trying to decide what to do with comment permalinks when paging is turned on.

#comments, #permalinks