WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 3 years ago

#14302 accepted enhancement

Object Property getters and setters

Reported by: filosofo Owned by: filosofo
Milestone: Future Release Priority: normal
Severity: normal Version: 3.0
Component: Posts, Post Types Keywords: has-patch
Focuses: Cc:

Description (last modified by filosofo)

Currently, if you want to get or set a post object's property:

  • You have to know which database table it's located in
  • If that property is in the posts table, you have to set all properties to set any, via wp_update_post or wp_insert_post.
  • If that property is in the postmeta table, you have to specify that it be returned as a singular value (instead of an array of values)

My patch lets WP figure out where a particular value is stored, so you don't have to, with two new functions:

mixed get_post_property ( int $object_id, string $prop_name [, bool $force_single ] )

bool set_post_property ( int $object_id, string $prop_name, mixed $prop_value )

Attachments (2)

object_property_functions.14302.diff (2.8 KB) - added by filosofo 4 years ago.
object_property_functions.14302.2.diff (2.8 KB) - added by filosofo 4 years ago.

Download all attachments as: .zip

Change History (17)

comment:1 filosofo4 years ago

  • Owner set to filosofo
  • Status changed from new to accepted

comment:2 scribu4 years ago

I like the idea, but I think we should follow the same pattern as for the metadata api:

Separate functions for each object type:

get_post_property() - set_post_property()

get_comment_property() - set_comment_property()

get_user_property() - set_user_property()

and then a general one that is used by all of the above:

get_object_property('post', ...) - set_object_property('post', ...)

comment:3 filosofo4 years ago

  • Description modified (diff)

I think you're right that it makes more sense to call them get_post_property and set_post_property, in light of the other objects throughout WP (in the PHP sense of "object"), such as the taxonomy and user objects.

Since the advent of the current taxonomy system I've preferred thinking of posts in general as objects, but the naming conventions introduced in 3.0 suggest that I need to stop worrying and love the "post."

Second patch uses *_post_* instead of *_object_*

comment:4 westi3 years ago

  • Milestone changed from 3.1 to Future Release

I'm not convinced by this api - encouraging direct access to individual parts of the Posts table feels like it could cause issues.

Moving to Future Release for now as this is too late for 3.1

comment:5 filosofo3 years ago

This comes from a ton of work with custom post type stuff. Quite often I just need to update one field, and I instead have to retrieve the whole post object and re-save all of it.

It doesn't make any sense, especially since what fields are in the posts table and what fields are in the meta table are more or less arbitrary from historical accident.

comment:6 scribu3 years ago

Marked #16421 as duplicate.

comment:7 sc0ttkclark3 years ago

  • Cc sc0ttkclark@… added

comment:8 mikeschinkel3 years ago

  • Cc mikeschinkel@… added

comment:9 follow-up: westi3 years ago

There is a scenario in core where this might be useful.

Trashing a post runs all the filters on the post content which is explicitly not being changed.

It might be nice to just change the post status.

But then plugins lose the ability they have at the moment to filter/alter ... the content when this happens

comment:10 in reply to: ↑ 9 ; follow-up: mikeschinkel3 years ago

  • Cc mikeschinkel@… removed

Replying to westi:

But then plugins lose the ability they have at the moment to filter/alter ... the content when this happens

These functions could have filters too. Of course that might cause issue with backward compatibility, but that's an orthogonal concern.

comment:11 in reply to: ↑ 10 westi3 years ago

Replying to mikeschinkel:

Replying to westi:

But then plugins lose the ability they have at the moment to filter/alter ... the content when this happens

These functions could have filters too. Of course that might cause issue with backward compatibility, but that's an orthogonal concern.

Yes but if they are mutating and individual field it's not simple to upgrade that to complete object mutation.

I think before I would be keen on this It probably should be developed as a plugin and have some real world examples of usage too.

comment:12 scribu3 years ago

So the point of contention is set_post_property(). What about just get_post_property() ?

comment:13 sc0ttkclark3 years ago

Also, is the user version of this out of the discussion already?

comment:14 filosofo3 years ago

Another way of putting the need for set_post_property(): why is it if the information is stored in postmeta, we can update properties individually, but if it it's stored in posts we can't?

E.g.: With my event custom post type, I should be able to do the following:

set_post_property( get_the_ID(), 'title', 'My Event' );
set_post_property( get_the_ID(), 'location', '123 Main Street' );

For "location," I can do that: update_post_meta( get_the_ID(), 'location', '123 Main Street' );

For "title, I have to retrieve and re-save the entire post:

$event_object = get_post( get_the_ID(), ARRAY_A );
$event_object['post_title'] = 'My Event';
wp_update_post( $event_object );

I'm saying that it's a poor API that requires me to know the underlying database schema in order to use the API. At the API level we should be agostic about the underlying database structure.

Version 0, edited 3 years ago by filosofo (next)

comment:15 sc0ttkclark3 years ago

I'm in filosofo's boat, with Users specifically, but definitely see this as an across-the-board object issue in regards to 'best' practice and normalization of the two very different methods to update 'single' fields.

Note: See TracTickets for help on using tickets.