[wp-trac] [WordPress Trac] #22271: get_post_class() does not always apply filter to output

[WordPress Trac]

#22271: get_post_class() does not always apply filter to output
-------------------------+------------------------------
 Reporter:  F J Kaiser   |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Template     |     Version:  3.4
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |
-------------------------+------------------------------

Comment (by F J Kaiser):

 Replying to [comment:27 Rarst]:
 >  - `get_post_class()` does not pass post object, only ID. Any filter
 will have to retrieve post object anyway... and as for me it's filter's
 problem if it doesn't check that if that came up with something.
 >  - there are other filters that will happily pass non-valid ID, for
 example `get_the_title`. So case can be made that specific
 `get_post_class` filter ''historically'' only passes valid ID, but there
 is no general case that filter passing ID as additional argument must
 ensure that it is valid one.

 I took a look at other functions like {{{the_content();}}},
 {{{the_guid()}}}, etc. There're dozens that behave like this. This kept me
 thinking about it for a while.

 * {{{get_post_class()}}} is a public function. It neither has leading
 {{{_}}}/underscore to tell that it's not meant for public usage, nor a
 line stating this in the phpDocBlock.
 * When we then take a look at the input arguments, then both
 {{{$classes}}} as well as {{{$post_id}}} are ''optional''.

 So the default behavior of this function is to simply fail, returning the
 empty {{{array()}}}, when publicly used and no global {{{$post}}} object
 is present that can be used as fallback inside {{{get_post()}}}. And that
 is strange.

 Replying to [comment:28 scribu]:
 > Yes, it would be the callback's problem, if we always applied the filter
 from the beginning.

 I don't see anything wrong with throwing a {{{Notice}}} or a
 {{{Warning}}}.

 > "NOTICE messages will warn you about bad style."
 [http://php.net/manual/en/errorfunc.configuration.php#ini.error-reporting
 quote from php.net]

 The ''error'' that happens if one doesn't check if an object is set, will
 only be visible with {{{WP_DEBUG}}} (or PHP error env) turned on. And that
 shouldn't happen in production.

 Based on all heard ideas and arguments so far, my personal preference
 would be to do the merge as early it is in scribus patch (no need to merge
 with the final array - speeds things up slightly), but also move the
 filter in for early returns.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/22271#comment:30>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software