Make WordPress Core

Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#21117 closed defect (bug) (fixed)

CPT called "content" triggers a PHP notice

Reported by: bpierre's profile bpierre Owned by: nacin's profile nacin
Milestone: 3.5 Priority: normal
Severity: minor Version: 3.4
Component: Administration Keywords: has-patch
Focuses: Cc:

Description (last modified by scribu)

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)

21117.diff (503 bytes) - added by jeremyfelt 12 years ago.
Replaces wp_parse_args() with a direct assignment to avoid PHP notice
21117.2.diff (2.5 KB) - added by jeremyfelt 12 years ago.
Replaces wp_parse_args() with a direct assignment to avoid PHP notice and changes the Add New menu ID to add-new

Download all attachments as: .zip

Change History (12)

@jeremyfelt
12 years ago

Replaces wp_parse_args() with a direct assignment to avoid PHP notice

#1 @jeremyfelt
12 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 @scribu
12 years ago

  • Description modified (diff)
  • Summary changed from Custom post called "content" triggers a PHP notice to CPT called "content" triggers a PHP notice

@jeremyfelt
12 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 @jeremyfelt
12 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.

#4 @nacin
12 years ago

  • Milestone changed from Awaiting Review to 3.5

#5 @nacin
12 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 @nacin
12 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 @nacin
12 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.

#8 @nacin
12 years ago

In [21258]:

Admin bar: Avoid clash with a parent node and a 'content' post type. see #21117.

#9 @nacin
12 years ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from new to closed

In [21259]:

Admin bar: When calling add_node() for an existing node, all properties should be merged into the existing arguments, including individual meta arguments. Corrects a logic inversion. fixes #21117.

Note: See TracTickets for help on using tickets.