comment submitted on static front page causes unnecessary jump to blog page

[aritchie1]

Install plain vanilla 2.9.1. Default theme comes up with no activated plugs.
Immediately create 'home' page and 'blog' page.
Go to settings/reading. Assign start page to 'home' and posts page to 'blog'.
Go to front end and add a comment on 'home' page.
Submission of comment causes a jump to the blog page, where the comment isn't!
That's the bug part.

Returning to the static front 'home' page, the comment is in place where it should be.

Unnecessary jump repeats with additional comment. Comments are correctly placed on return to front page.

OSX 10.5.x Safari MAMP server environment

[nacin]

Confirmed without pretty permalinks. It looks like with any public query var appended to the blog URL, WP will think you want the posts page, when (in this case at least) you want the home page.

[nacin]

See also #12391

[dd32]

(In [13493]) When using Page on front, Do not jump back to Blog listing when per-page query vars are set. Fixes #12047

[aaroncampbell]

The [13493] revision caused a problem for me. Basically, I'm doing a custom query like this on a page on my site:

$clients_query = new WP_Query();

$args = array(
    'post_parent'   => $id,
    'post_type'             => 'page',
    'paged'                 => $paged,
    'posts_per_page'=> 5,
    'orderby'               => 'menu_order',
    'order'                 => 'ASC',
);
$clients_query->query($args);

Where $id is 245, a specific page ID that has child pages.

Unfortunately that means that on lines 1473-1474 of wp-include/query.php is_home is set to true. Then the newly re-written conditional here causes $qv['page_id'] = get_option('page_on_front'); which means I get the front page instead of the sub pages I want.

I fixed it for me by adding ( empty($this->query) || $qv['preview'] == 'true' ) back to the conditional. Why exactly was that part removed?

I'm attaching a patch that will put it back.

[aaroncampbell]

To be clear, I'm assuming it would be better to fix the existing conditional (which already tries to take into account preview and query) rather than add the extra bit in like my patch does. I'm just not sure what exact conditions were being addressed with the original change. Maybe I'll get some time at WCSF to take a look at this if no one else gets to it.

[aaroncampbell]

I guess I can't leave well enough alone. The problem in my case is that I'm specifying the paged parameter and the new conditional checks that and assumes that since I want the query to be paged that I must want the front-page. Can we just remove the !empty($qv['paged']) part of this?

[aaroncampbell]

Just removes the !empty($qvpaged?) check

[dd32]

(In [14341]) Fix custom WP_Queries when using page_on_front. Props aaroncampbell. See #12391 (Which caused it), Fixes #12047

[dd32]

(In [14445]) Handle $wp_query->query being a string in r14341. See #12391, #12047. Fixes #13241

[nacin]

Related, I'm pretty sure, #13840