[wp-trac] [WordPress Trac] #13753: get_page() breaking $post when it's called with empty parameter

[WordPress Trac]

#13753: get_page() breaking $post when it's called with empty parameter
--------------------------+-------------------------------------------------
 Reporter:  shidouhikari  |       Owner:  westi    
     Type:  defect (bug)  |      Status:  accepted 
 Priority:  normal        |   Milestone:  3.0      
Component:  General       |     Version:  3.0      
 Severity:  normal        |    Keywords:  has-patch
--------------------------+-------------------------------------------------

Comment(by shidouhikari):

 I believe the desired behavior is that passed $post be updated by the
 function to reflect the post. Consumer of the function should be aware the
 variable is being passed as reference and is possible to be changed. If he
 doesn't want it, he must create a secure variable to pass, but in this
 case we have lower memory efficiency.

 Indeed, the function returns an object of the required post, so there
 wouldn't be the need of editing the parameter. Maybe it's this way because
 $output and $filter parameters makes the returning value have an altered
 format (note that the code that uses them doesn't touch $post anymore, and
 returns $_post, a different variable). So, the parameter has the object
 and returning value has the formatted data.

 If you wanna get the post with a different format and also the raw object,
 the alternative would be call the function twice... So the function offers
 you 2 outputs. We MUST be aware that when get_post() returns, $post may
 have changed (but not always...).

 The problem here is that when get_page() is called and $post is empty, it
 tries to use the global variable to identify current post, and aparrently
 only calls get_post() so that it can be formatted as required. But when
 the global variable is sent as parameter, the post object is replaced by
 its ID, which shouldn't happen with global $post.

 It seems get_page()'s author just wanted to use get_post() to format the
 returning variable, and didn't note that get_post() must receive a
 variable that's secure to be edited.

 get_post() isn't intended to format an existing object, if get_page()
 remains as it is, it should duplicate $post and leave global variable
 alone, or we should have a separate function just to format the object,
 which should be called by both get_post() and get_page() when they find
 the object they want, just to format the output. I believe get_page() is
 wrongly using get_post().

 get_post() wasn't developed intended to receive an object and just format
 it. When it receives an object, it believes the object can be freely
 edited, so the variable is assigned to the received object's ID and tries
 to retrieve a valid post object from cache or database. *Indeed, anybody
 that gets global $post and later pass it to get_post() to have it
 formatted will break the global variable... that's bug prone and should be
 fixed!*

 Note also that, even receiving a post object, get_post() doesn't believe
 it's a valid object, *deletes* its content and try to get a new post based
 on the object's ID. I believe it was intended to update that post data, or
 maybe just doesn't consider it's content valid since the function doesn't
 know where it came from...

 Another interesting thing is that if $post is an object and
 empty($post->filter), it's sanitized and added to cache... I don't
 understand the objective in this case, why $post->filter being empty makes
 the object so reliable that it's added to cache without any verification,
 while when it's not empty  the object's content is deleted and re-
 retrieved?


 Also, the paramater content is totally inconsistent when get_post()
 returns, so inconsistent we almost can't trust in it:

 - if it's empty, it's left empty

 - if it's an object and empty($post->filter), it's content is sanitized
 and cached, sometimes being considered as that posts's official content
 (maybe it was intended for a plugin hack into specific posts? I doubt,
 because for that it would be better to use filters), and not altered

 - else, $post is considered to be the post ID (and if it's an object, it's
 overwridden as the object's ID), retrieved from cache or database and
 assigned as the post ID



 I'm not skilled enough to judge it, but I think get_post() would be more
 consistent if the parameter always had an object related to the formatted
 output when the function returns, or left alone if that post wasn't found
 and return null. As we saw, some people may try to use get_post() just to
 format a post, but in some situations $post may be altered and its content
 lost. Documentation is faulty for not alerting about it. If there's a need
 of just formatting some data, there should be a function for that only
 purpose, that doesn't receive this data as reference and that's used by
 get_post(), so that people only wanting to format a post doesn't need to
 use a more complex function.


 Well I hope I didn't make it even more confused and helped somehow o.O

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