Support » Fixing WordPress » What happened to $post->ID

  • I just ran the auto update for a clients site. Now all of my code that is pulling in custom fields and building wp_list_pages menus are broken.

    It appears that with the auto update to 2.9.2 that $post->ID isn’t working. I’ve searched on the site and on Google but I’ve only found a few people citing the same issue.

    What happened? I have to say this is really really really worrying me as there are number of sites out there that would break or completely crumble.

    I understand that ‘get_the_id()’ works but how can we be expected to go back and replace every instance of $post->ID.

    Please, someone tell me I’m overreacting and that there is a fix or answer to this. Otherwise I have to tell clients to NEVER updat their site??? Or risk backlash for the hours needed to fix this? Or work for hours on end for free???

    I hope I’m jumping to conclusions.

Viewing 13 replies - 1 through 13 (of 13 total)
  • What version of WP was your client running before the upgrade to 2.9.2?

    It would help to see some code to see how you’re using $post->ID. Custom field functions and wp_list_pages() all work outside of the loop. However, get_the_ID() only works inside the loop. If you’re using the custom field functions and wp_list_pages() outside of the loop, are you calling $post to global scope?



    Forum Janitor

    I can assure you that $post->ID does work, as I’m using it on my blog.

    How are you using it?

    Moving this thread to how-to forum as it’s not a request or feedback for WordPress itself.

    I hope I’m jumping to conclusions.

    You are..

    Can you confirm what cnorris was asking in relation to $post.

    Thanks everyone.

    I’m not 100% sure what version this client had before updating, it shouldn’t have been earlier than 2.9

    Here is an example of how I’m using Custom Fields with $post->ID.
    I do this in a number of places and it has worked very well for me for a while. I’m calling it directly in the Loop. Usually after the endif; of The Loop or in the sidebar.

    <?php $suite = get_post_meta($post->ID, 'suite', true); echo $suite; ?>

    As for the sidebar menu using wp_list_pages I have with in a conditional that has worked equally well for a number of sites for quite awhile. This is in the sidebar.php file of my theme.

    $thelist = wp_list_pages("title_li=&child_of=".$post->ID."&echo=0&depth=1&exclude=211");

    In both cases once I replaced $post->ID with get_the_id() it was fixed.

    I’m still really confused as to why this happened.
    In fact I tried to echo $post->ID as well and was getting no result in the page.

    Thanks for any clarification / advise in advance.


    Correction: I’m not calling it directly in the Loop.

    Then $post->ID is not necessarily available to you..

    Outside the loop you should be using get_the_ID()..

    Thanks but I’d still like to understand why this worked before and what the rationale for changing it might have been.

    I have far too many instances where I’ve used this and I’m sure there have to be others out there with the same issue.

    Anyone who can give me a more in-depth explanation?


    I’ve written about three responses and deleted each one, i’m useless at explaining these types of things..

    I don’t honestly think i can explain it, because i don’t fully understand it myself, but enough to know $post->ID outside the query won’t necessarily be available, because $post refers to the current $post object in the loop …

    Outside the loop which post should it refer to, the first in the query, the last, the one in the middle…

    For queries that only contain 1 post, yeah it might be fine, but for queries that contain several posts, you would probably need to reference $posts[0]->ID assuming you want the first post in the array of post objects.. 0 being the key of the first item in the array ..

    Beyond that, ask one of the chaps on IRC, they’d probably explain it much better than i will, and there’s plenty of fellas there that know this stuff inside out..

    Thanks for trying. I appreciate it.

    Not sure if it helps but most of the sites I work on are built using Pages so there shouldn’t be more than one ‘post’ in the loop or query.

    Is there anything to suggest that $post->ID no longer works on Page templates?

    Thanks again. Anyone who cares to add to this I would appreciate it.


    Why don’t you test my theory, try ..

    echo $post[0]->ID;

    ..where you reported the echo not giving anything..

    Failing that see if $post is available..

    echo ( !$post ) ? 'post var not here' : 'post var is here';

    .. which is just a short way of writing..

    if( !$post ) {
    echo 'post var not here';
    else {
    echo 'post var is here';

    Outside of the loop, you need to add this line
    global $post;
    before you call $post. Are you doing this?

    Thanks. I will look into this.

    I haven’t had to do this in the past but if this is a fix
    I’m open to it.

    Also interested to find out if $post not working would have anything to do with running the automatic update?

    I have another site where the install started at 2.9.2 and I was using the same method for custom fields and I am not having the same problem.

    Thoughts on how updating could affect this? Glitch?

    Also (forgive my ignorance) but the sidebar.php code is technically ‘outside’ The Loop, correct?

    Thanks in advance.

    I think it really depends what happens between when you’re at the loop and when you reach that point in the sidebar, if one post exists, then $post refers to the current post (and will in the loop), if something else fills that var somewhere between the point of the loop, up till the point when you reach the code to be run in the sidebar that var could be filled with another post’s data.

    $posts an array of posts for the current query
    $post the current post in the iteration, or if it’s the only post in the loop then it’s likely to that post(unless something else fills it with data)

    In my last response i wasn’t clear, nor exactly correct..

    There’s alot that can happen between the point of the loop and that of the sidebar, you could have content rendered after the main loop, at the top of the sidebar, etc… but the point being, if any other queries of the page want to occupy or fill in that var with their data it’s no longer going to contain the data you’re expecting it to.

    One such piece of code that will refill(in a manner of speaking) that var is this(and i’m sure you’ve seen this before).


    You often see this in examples for writing custom queries, usually using get_posts using a foreach loop(and other cases to)… and therefore $post no longer holds the data you expect..

    There’s also the variable scope to, but that’s really just a matter of printing/echoing the var to see if it’s there, if you get nothing from printing, then global it, problem resolved (it’s not a big issue simply global $post; as suggested before).

Viewing 13 replies - 1 through 13 (of 13 total)
  • The topic ‘What happened to $post->ID’ is closed to new replies.