Make WordPress Core

Opened 14 years ago

Closed 9 years ago

Last modified 9 years ago

#14302 closed enhancement (duplicate)

Post object property getters and setters

Reported by: filosofo's profile filosofo Owned by: filosofo's profile filosofo
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Posts, Post Types Keywords: has-patch dev-feedback
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 14 years ago.
object_property_functions.14302.2.diff (2.8 KB) - added by filosofo 14 years ago.

Download all attachments as: .zip

Change History (20)

#1 @filosofo
14 years ago

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

#2 @scribu
14 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', ...)

#3 @filosofo
14 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_*

#4 @westi
13 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

#5 @filosofo
13 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.

#6 @scribu
13 years ago

Marked #16421 as duplicate.

#7 @sc0ttkclark
13 years ago

  • Cc sc0ttkclark@… added

#8 @mikeschinkel
13 years ago

  • Cc mikeschinkel@… added

#9 follow-up: @westi
13 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

#10 in reply to: ↑ 9 ; follow-up: @mikeschinkel
13 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.

#11 in reply to: ↑ 10 @westi
13 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.

#12 @scribu
13 years ago

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

#13 @sc0ttkclark
13 years ago

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

#14 @filosofo
13 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.

Last edited 13 years ago by filosofo (previous) (diff)

#15 @sc0ttkclark
13 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.

#16 @chriscct7
9 years ago

  • Keywords dev-feedback added

#17 follow-up: @DrewAPicture
9 years ago

  • Milestone Future Release deleted
  • Resolution set to duplicate
  • Status changed from accepted to closed
  • Summary changed from Object Property getters and setters to Post object property getters and setters

Duplicate of #21309.

Getters and setters were included when WP_Post was introduced in [21559] for 3.5.

#18 in reply to: ↑ 17 @chriscct7
9 years ago

Replying to DrewAPicture:

Duplicate of #21309.

Getters and setters were included when WP_Post was introduced in [21559] for 3.5.

Using wp_set_object_terms you can set terms, but what do you do for ( as an example) setting the post title?

Note: See TracTickets for help on using tickets.