Upgraded to 2.5.1, have_posts() stopped working.

Additional information:

The blog is installed to: mysite.com/blog/
The page I’m working on is at: mysite.com/foo.php

All the posts are displaying correctly at mysite.com/blog/.

Some help would be greatly appreciated. Everything seems to be in perfect working order; I don’t understand why this code suddenly stopped working.

Thanks. ??

have_posts still exists. None of that has changed in any significant way.

Make sure you uploaded all the files. Specifically look for those in wp-includes and wp-admin.

Your above code is weird with that odd “continue:” line though. I’m honestly not sure what it’s trying to do. It’s certainly not valid PHP code.

Er, that’s not a line of code. That’s a badly word-wrapped comment, as the text field is narrow and I cannot adjust font-size. ?? Apologies for the confusion.

Here’s the snippet without those comments, and some attempt at indenting for clarity:

if ( have_posts() )
{
  while ( have_posts() )
  {
    the_post();
    if (in_category('6'))
    {
      /* assorted output functions here. */
    }
  }
}

I’m using the automated installation/upgrades that Dreamhost provides; it’s a little disheartening to think they’d botch it, but I’ll do some manual double-checking myself.

I’m also having the same issue, FWIW. The simplified version of my code is here:

get_header();
if (have_posts()):
  while (have_posts()):
    the_post();
  endwhile;
  // pagination navigation
else:
  // display a search box and 404 error;
endif;

… How exactly are you calling the WordPress functions to begin with? Is this a normal WordPress install, or did you integrate it into some other site somehow?

If you integrated it, then 2.5 slightly changed the unspoken rules in that respect. Prior to that, the main blog query was a given, you didn’t need to specify it if you wanted it. However, the rewriting changed significantly and this “side-effect” disappeared. It was never designed or intended behavior, it was just the way it worked. Now you don’t get a free query for the main blog posts when you’re not using the normal URL patterns.

Easy fix: Add a call to query_posts(); just before your usage of have_posts.

For myself, it’s a typical install, but a custom theme. It has it’s own subdomain. https://blog.perfectspace.com.

Also, every other page works fine except my home page.

I tried putting a query_posts() before the have_posts() and it didn’t change anything. Here’s the output of $wp when I look at it prior to the have_posts():

wp Object
(
    [public_query_vars] => Array
        (
            [0] => m
            [1] => p
            [2] => posts
            [3] => w
            [4] => cat
            [5] => withcomments
            [6] => withoutcomments
            [7] => s
            [8] => search
            [9] => exact
            [10] => sentence
            [11] => debug
            [12] => calendar
            [13] => page
            [14] => paged
            [15] => more
            [16] => tb
            [17] => pb
            [18] => author
            [19] => order
            [20] => orderby
            [21] => year
            [22] => monthnum
            [23] => day
            [24] => hour
            [25] => minute
            [26] => second
            [27] => name
            [28] => category_name
            [29] => tag
            [30] => feed
            [31] => author_name
            [32] => static
            [33] => pagename
            [34] => page_id
            [35] => error
            [36] => comments_popup
            [37] => attachment
            [38] => attachment_id
            [39] => subpost
            [40] => subpost_id
            [41] => preview
            [42] => robots
            [43] => taxonomy
            [44] => term
        )

    [private_query_vars] => Array
        (
            [0] => offset
            [1] => posts_per_page
            [2] => posts_per_archive_page
            [3] => what_to_show
            [4] => showposts
            [5] => nopaging
            [6] => post_type
            [7] => post_status
            [8] => category__in
            [9] => category__not_in
            [10] => category__and
            [11] => tag__in
            [12] => tag__not_in
            [13] => tag__and
            [14] => tag_slug__in
            [15] => tag_slug__and
            [16] => tag_id
            [17] => post_mime_type
            [18] => perm
        )

    [extra_query_vars] => Array
        (
        )

    [query_vars] => Array
        (
            [posts_per_page] => 8
            [what_to_show] => posts
            [orderby] => date
            [order] => DESC
        )

    [query_string] => posts_per_page=8&what_to_show=posts&orderby=date&order=DESC
    [request] =>
    [matched_rule] =>
    [matched_query] =>
    [did_permalink] =>
)

It’s a standard WordPress install, installed to mysite.com/blog/ — everything works as expected there.

The reason I’m not just using that page is because I really don’t care for any of the WordPress themes — basically, I’m wanting to use WordPress for the post-creating/backend functionality, and then use a few choice functions to output the posts as I prefer.

(Creating my own WordPress theme seemed to be massive overkill when I could just put The_Loop into a [div] of my choosing.)

That said, your quick fix worked perfectly. I’m using this now:

`
query_posts(‘cat=6’);

if ( have_posts() )
{
while ( have_posts() )
{
the_post();
/* etc. */
}
}
`

…and no longer need the in_category() checking.

Since you mentioned this was an easy fix, is there a downside to this method, or another method that is more preferred?

Thank you very much. I have a site again. ??

NM, found that the “Category Visibility” plugin broke it. ?? All better. Cheers.