#21117 closed defect (bug) (fixed)
CPT called "content" triggers a PHP notice
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 3.5 | Priority: | normal |
Severity: | minor | Version: | 3.4 |
Component: | Administration | Keywords: | has-patch |
Focuses: | Cc: |
Description (last modified by )
If a custom post type is called "content", the following error appears on all the admin pages:
Notice: Undefined index: meta in /path/to/wp-includes/class-wp-admin-bar.php on line 108
"content" is not in the taxonomy reserved terms list: http://codex.wordpress.org/Function_Reference/register_taxonomy#Reserved_Terms
PS: according to the ticket:19868, the taxonomy reserved terms are used for everything?
Attachments (2)
Change History (12)
#1
@
13 years ago
- Keywords has-patch added
Confirmed on latest trunk. Looks like two separate, but related, issues here.
First, when the admin menu is built, an ID is auto generated of the structure new-{$post_type}
. The default id for the Add New item in the WP Admin bar is new-content
. When a post type is registered as content
, a conflict appears because that ID already exists. The bigger problem is that the Add New menu does not appear at all at this point.
I would personally assume 'content' is too generic a name to use when registering a post type, but perhaps the ID used for the Add New item is too generic as well. Prefixing the post type is probably the best answer to avoid any other unforseen conflicts.
Separately from this - The code in add_node()
detects that a node already exists with this ID and grabs the default data associated with it. The next line of code attempts to then use wp_parse_args()
with data it has just confirmed was empty, which generates the PHP notice.
The patch attached (attachment:21117.diff) addresses only the removal of wp_parse_args()
in this scenario.
#2
@
13 years ago
- Description modified (diff)
- Summary changed from Custom post called "content" triggers a PHP notice to CPT called "content" triggers a PHP notice
@
13 years ago
Replaces wp_parse_args() with a direct assignment to avoid PHP notice and changes the Add New menu ID to add-new
#3
@
13 years ago
For historical interest... 'New Content' was the first version of 'Add New' when the Admin Bar as we know it was being created 106:ticket:14772. This appears to be why new-content
was used as the menu ID in 16077. The name change to 'Add New' was made in 16302, but the ID of the menu remained.
The use of new-content
as an ID appears to only be for the display of the menu. As the children of 'Add New' are automatically assigned IDs as new-{$post_type}
, it makes sense to change the parent ID to something other than new-content
to avoid conflict.
This updated patch 21117.2.diff addresses both the empty wp_parse_args()
argument and changes the ID for the Add New menu item to add-new
.
#5
@
13 years ago
I know there was a reason for the wp_parse_args() there, even if it isn't working as designed. It was supposed to allow you to register new meta over an existing node and for the existing meta to merge.
#6
@
13 years ago
We can also push new-content into the $back_compat_parents array in add_node(). Potentially, we can also look further up the stack and confirm that new-content's parent isn't already add-new, in case someone has a "content" post type and then adds a child node to it.
#7
@
13 years ago
None of this works very well. If you end up with both a 'content' post type and manually added child nodes of the current 'new-content' menu, either the child nodes don't get mapped, or you can't assign child nodes to the 'content' post type's node. Neither of these are ideal situations.
I suggest instead that we just insert a condition to rename the ID for a 'content' post type to avoid the conflict at that level.
Replaces wp_parse_args() with a direct assignment to avoid PHP notice