[wp-trac] [WordPress Trac] #16815: Home page slug in URL of child pages

[WordPress Trac]

#16815: Home page slug in URL of child pages
--------------------------+-----------------------------
 Reporter:  meustrus      |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Permalinks    |    Version:  3.0
 Severity:  normal        |   Keywords:
--------------------------+-----------------------------
 The issue is: Say I have a page called "Home" that is set to the static
 home page. Therefore, when I go to www.example.com, I'm really going to
 www.example.com/?p=4 or whatever. Then, I want to create a page that is a
 child of Home, in my particular case because a plugin is building a menu
 automatically from the page hierarchy. The new page gets the permalink
 www.example.com/home/page , but I want it to be at www.example.com/page .

 I believe this is a BUG because there is no page called
 www.example.com/home because that page is accessed from the root of the
 website.

 I have attempted to solve the problem with a plugin but filters are not
 provided in the right places. It's trivially easy to provide this fix with
 some tactical edits to /wp-includes/post.php

 Before I post the edits I am proposing (and which I have tested and
 confirmed that they work), I state that I am working with version 3.0.0 .
 Nobody needs to lecture me about this as it is not my decision at the
 moment; I have, however, checked with recent copies to be sure that this
 bug has not already been fixed.

 First, an edit to the function get_page_uri (approx. line 3030):
 {{{
 #!php
         while ($page->post_parent != 0) {
 # EDITS (meustrus)
                 if ( 'page' == get_option('show_on_front') && get_option(
 'page_on_front' ) && $page->post_parent == get_option( 'page_on_front' ) )
                         return $uri;
 # /EDITS
                 $page = get_page($page->post_parent);
                 $uri = $page->post_name . "/" . $uri;
         }
 }}}
 This causes the URI generator to stop building the URI if the next parent
 is the front page.

 Second, an edit to the function get_page_by_path (approx. line 2900):
 {{{
 #!php
                 while ( $curpage->post_parent != 0 ) {
 # EDITS (meustrus)
                         if ( 'page' == get_option('show_on_front') &&
 get_option( 'page_on_front' ) && $curpage->post_parent == get_option(
 'page_on_front' ) )
                                 break;
 # /EDITS
                         $curpage = $wpdb->get_row( $wpdb->prepare( "SELECT
 ID, post_name, post_parent FROM $wpdb->posts WHERE ID = %d and post_type =
 %s", $curpage->post_parent, $post_type ));
                         $path = '/' . $curpage->post_name . $path;
                 }
 }}}
 This causes the system which converts ?pagename=SLUG into a post ID to
 stop building the path if the next item is the front page.

 If this is not accepted as a patch to the core files, these are some notes
 for building a plugin (feel free to tl;dr from this point):

 The get_page_uri function is called 5 times; get_post_permalink and
 _get_page_link in wp-includes/link-template.php (both of which can be
 altered with filters), twice in page_uri_index in wp-includes/rewrite.php
 (neither is filterable but they are only used with verbose page rules),
 and once in get_sample_permalink in wp-admin/includes/post.php (which is
 filterable only once it gets to get_sample_permalink_html, and changing it
 with that filter would basically require rewriting the function).

 The get_page_by_path function can't be simply filtered out, but it may be
 possible to use rewrite rules or a filter on "request" to test for a page
 of this format by adding the slug for the front page in front of the URI
 and trying to call the original get_page_by_path on that.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/16815>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software