Make WordPress Core

Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#12047 closed defect (bug) (fixed)

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

Reported by: aritchie1's profile aritchie1 Owned by: ryan's profile ryan
Milestone: 3.0 Priority: normal
Severity: normal Version: 2.9.1
Component: Query Keywords: front page comment
Focuses: Cc:


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

Attachments (2)

12047.001.diff (1.4 KB) - added by aaroncampbell 14 years ago.
12047.002.diff (1.4 KB) - added by aaroncampbell 14 years ago.
Just removes the !empty($qvpaged?) check

Download all attachments as: .zip

Change History (11)

#1 @nacin
14 years ago

  • Component changed from Comments to Rewrite Rules
  • Owner set to ryan

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.

#2 @nacin
14 years ago

  • Component changed from Rewrite Rules to Query
  • Milestone changed from Unassigned to 3.0

See also #12391

#3 @dd32
14 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

#4 @aaroncampbell
14 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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',

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.

#5 @aaroncampbell
14 years ago

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.

#6 @aaroncampbell
14 years ago

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?

14 years ago

Just removes the !empty($qvpaged?) check

#7 @dd32
14 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

#8 @dd32
14 years ago

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

#9 @nacin
14 years ago

Related, I'm pretty sure, #13840

Note: See TracTickets for help on using tickets.