WordPress.org

Make WordPress Core

Opened 8 years ago

Closed 8 years ago

#25786 closed defect (bug) (invalid)

Using custom_fields with wp.newPost does not add meta on clean WordPress installs.

Reported by: timgws Owned by:
Milestone: Priority: normal
Severity: minor Version: 3.7.1
Component: XML-RPC Keywords:
Focuses: Cc:

Description

When using wp.newPost with WordPress' XML-RPC on a clean install of WordPress 3.7.1, the meta fields fail to be added.

This is due to checks inside class-wp-xmlrpc-server.php.

When the custom_fields struct is used in a new WordPress post using wp.newPost, $this->set_custom_fields is called with the value of custom_fields, along with the posts id.

current_user_can is then called asking for the add_post_meta role. This check returns false for all default role types, including Administrator.

The only way that I have been able to resolve it so far is to run the following code inside a WordPress plugin first:

$role = get_role( 'administrator' );
$role->add_cap('edit_post_meta');
$role->add_cap('delete_post_meta');
$role->add_cap('add_post_meta');

After running this code, posts can finally be added with custom meta data.

Is there something that I am missing? There does seem to be code inside the map_meta_cap function inside capabilities.php to map this capability to edit_post, but this mapping code does not seem to run when a new post is being added or edited.

This results in all attempts to add meta values (such as post specific meta data for plugins) to fail.

Change History (4)

#1 @nacin
8 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

add_post_meta is not a capability that should be assigned to a user or role. That's very bad, you don't want that, and can lead to security issues. I've seen that suggested once or twice before, and we should probably disable meta capabilities from being assigned to users.

If your custom field starts with an underscore, then it is "protected" and cannot be edited by a user free-form. That includes not just the Custom Fields meta box but also XML-RPC. Otherwise XML-RPC would be an easy workaround to update private metadata, which is privilege escalation and could possibly cause other security issues.

If you are using an underscore simply to keep it out of Custom Fields but still want it editable by XML-RPC, try register_meta() on for size. It doesn't do much yet (it specifically only does this), but you can pass it an authorization callback that receives six arguments (as seen in map_meta_cap) and you either return true (yes, user can edit) or false (no, user can't).

register_meta() could use some tutorials. It's one of those APIs we didn't really announce because we wanted to see how people might use it. It also doesn't do much now, as I said — though in the future it may form the backbone of a new meta box API (#18179). You'll note how it also handles sanitization callbacks, just like register_setting() does, so when you call update_post_meta(), your callback would be called automatically. You can see the potential here.

#2 @timgws
8 years ago

Although I can see the potential, it still does not resolve the facts that:

  1. The documentation states that I can use wp.newPost (http://codex.wordpress.org/XML-RPC_WordPress_API/Posts#Parameters_3) to add custom_fields. It does not say that "protected" custom fields can not be added using the XML-RPC. No failure is returned in the response to say that custom fields were completely ignored.
  2. Plugins that run hooks when a new post is inserted add meta data when using the WordPress admin interface, but not the XML-RPC interface.
  3. Using register_meta() will require additional plugins to be installed inside WordPress in able to use WordPress' API efficiently.

I don't see how it should be a requirement to install a plugin and/or modify WordPress code in order to be able to add meta data to a WordPress post, seeing as it is something that ships in core.

#3 @timgws
8 years ago

  • Keywords dev-feedback removed
  • Resolution invalid deleted
  • Status changed from closed to reopened

#4 @markoheijnen
8 years ago

  • Resolution set to invalid
  • Severity changed from major to minor
  • Status changed from reopened to closed

Documentation isn't complete in that area. Being angry on that is misplaces because it's build by volunteers. Also you can change that page yourself. I think we decided not to through an error because it's an edge case that was better to silently ignore it then not save the post at all.

XML-RPC uses the same hooks as the admin interface.

If you use fields starting with an underscore then you mark them as private. Reason for this can be that it's only for numbers or pre defined values. You don't want that to be changed through the XML-RPC. That would mean hacking the system. If you would like to allow that certain field to be changed with XML-RPC then you would use register_meta().

Closing the ticket again since I don't see a reason to change the code in WordPress. In this case it means not using keys starting with underscores or using register_meta().

Note: See TracTickets for help on using tickets.