Object Property getters and setters

[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 )

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', ...)

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_*

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

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.

Marked #16421 as duplicate.

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

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.

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.

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

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

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.

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.