WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 21 months ago

Last modified 21 months ago

#19919 closed defect (bug) (wontfix)

Do not work сustom fields in XML-RPC

Reported by: xpert13 Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.3.1
Component: XML-RPC Keywords:
Focuses: Cc:

Description

Temporary solution: replace line

} elseif ( current_user_can( 'add_post_meta', $post_id, stripslashes( $meta['key'] ) ) ) {

to line

} else {

I think bug is in file /wp-includes/capabilities.php

	case 'add_post_meta':		
		$post = get_post( $args[0] );
		$post_type_object = get_post_type_object( $post->post_type );
		$caps = map_meta_cap( $post_type_object->cap->edit_post, $user_id, $post->ID );

		$meta_key = isset( $args[ 1 ] ) ? $args[ 1 ] : false;

		if ( $meta_key && has_filter( "auth_post_meta_{$meta_key}" ) ) {
			$allowed = apply_filters( "auth_post_meta_{$meta_key}", false, $meta_key, $post->ID, $user_id, $cap, $caps );
			if ( ! $allowed )
				$caps[] = $cap;
		} elseif ( $meta_key && is_protected_meta( $meta_key, 'post' ) ) {
			$caps[] = $cap;
		}
		break;

Because any custom field could not pass this check.

Change History (4)

comment:1 SergeyBiryukov2 years ago

  • Component changed from General to XML-RPC

comment:2 nacin2 years ago

A custom field that starts with an underscore does not pass this check. It is considered "protected" and cannot be modified through any UI, which includes a generic XML-RPC method.

If you wish to whitelist a custom field, you can use register_meta(). This takes a meta type (i.e. "post"), the meta key, a function to sanitize the value on save (similar to the sanitization callback for register_setting()) and an authorization callback to determine whether a user can edit_post_meta, add_post_meta, or delete_post_meta.

comment:3 markoheijnen21 months ago

  • Resolution set to wontfix
  • Status changed from new to closed

comment:4 helenyhou21 months ago

  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.