# WordPress.org

## Make WordPress Core

Opened 4 years ago

Closed 3 years ago

# Orphaned Comments From Nonexistent Post Type Causes Capability Warnings in Admin

Reported by: Owned by: Funkatronic normal normal 4.4 Comments needs-patch needs-unit-tests administration

So I have a comment or two attached to a post type that isn't currently active. Because the post type isn't turned on, I'm getting the following warnings in the admin screen whenever the comment is displayed:

Notice: map_meta_cap was called <strong>incorrectly</strong>. The post type series_season is not registered, so it may not be reliable to check the capability "edit_post" against a post of that type. Please see <a href="https://codex.wordpress.org/Debugging_in_WordPress">Debugging in WordPress</a> for more information. (This message was added in version 4.4.0.) in D:\Web Development\www\beta\wp-includes\functions.php on line 3787


It also shows up on the Dashboard in the comments widget:

I think this is related to #16956 (thanks @boonebgorges). Basically, because the post type doesn't exist anymore, the it messes up the capabilities of a comment that is attached to a post of that post type. I suggest maybe hiding the comments of post types that don't exist/inactive.

### #1 @SergeyBiryukov 4 years ago

• Description modified (diff)

### #2 @SergeyBiryukov 4 years ago

I suggest maybe hiding the comments of post types that don't exist/inactive.

This would make them impossible to edit or remove, see comment:51:ticket:16956.

I think the notice was the intended result of [34091].

### #5 follow-up: ↓ 7 @boonebgorges 4 years ago

+1 to SergeyBiryukov. The notice is by design; it warns the admin that the proper cap checks are not taking place. And the decision to leave this content (instead of hiding it) was a conscious one.

That said, @Funkatronic pointed out to me in a DM a powerful argument for hiding comments orphaned in this way: we don't show *posts* from unregistered post types. Does anyone else have a thought about this?

### #6 @nekojira 4 years ago

a powerful argument for hiding comments orphaned in this way: we don't show *posts* from unregistered post types.

+1

### #7 in reply to: ↑ 5 ; follow-up: ↓ 8 @Funkatronic 4 years ago

+1 to SergeyBiryukov. The notice is by design; it warns the admin that the proper cap checks are not taking place. And the decision to leave this content (instead of hiding it) was a conscious one.

That said, @Funkatronic pointed out to me in a DM a powerful argument for hiding comments orphaned in this way: we don't show *posts* from unregistered post types. Does anyone else have a thought about this?

+1 from me, but that's a given :p.

To me it makes sense to hide the comments if the posts they are connected to are "gone".

### #8 in reply to: ↑ 7 @SergeyBiryukov 4 years ago

To me it makes sense to hide the comments if the posts they are connected to are "gone".

Good point, was just thinking about that too. I guess we should be consistent.

### #9 @obrienlabs 4 years ago

+1, I think maintaining consistency is a good idea

### #10 follow-up: ↓ 11 @boonebgorges 4 years ago

• Keywords needs-patch needs-unit-tests added; 2nd-opinion removed
• Milestone changed from Awaiting Review to Future Release

OK, I guess hiding it is OK with me. Let's get a patch, and we can move it to a release.

### #11 in reply to: ↑ 10 @Funkatronic 4 years ago

OK, I guess hiding it is OK with me. Let's get a patch, and we can move it to a release.

To me, it's better than a user disabling a plugin and having all these errors appear because they have comments in a post type in that plugin.

### #12 @johnbillion 4 years ago

• Version changed from trunk to 4.4

### #14 @UmeshSingla 3 years ago

Attached a patch for hiding the comments if associated post type is not available.

WooCommerce comments were filling up my debug log after I deactivated the plugin, the patch fixes it for me.

Although, I guess I'd need to look up other core files to add a similar check if required elsewhere.

### @UmeshSingla 3 years ago

Hide the comments if associated post type isn't available

### #17 @chriscct7 3 years ago

• Milestone Future Release deleted
• Resolution set to duplicate
• Status changed from new to closed

Closing as duplicate of #36208. A summary of the discussion on this ticket + the patch has been moved to that ticket.

Note: See TracTickets for help on using tickets.