Make WordPress Core

Opened 3 years ago

Closed 3 years ago

#16815 closed feature request (wontfix)

Home page slug in URL of child pages

Reported by: meustrus Owned by:
Milestone: Priority: normal
Severity: minor Version: 3.0
Component: Permalinks Keywords:
Focuses: Cc:


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):

        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;
                $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):

                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' ) )
                        $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.

Attachments (1)

rerooted-permalinks.zip (4.0 KB) - added by meustrus 3 years ago.
Re-Rooted Permalinks plugin

Download all attachments as: .zip

Change History (4)

comment:1 solarissmoke3 years ago

Your proposed solution means that if someone changes the show_on_front page, the permalinks for the old home page and the new home page (and all their child pages) change. This can cause permalinks to break because canonical redirect will not always work, especially when pages in different heirarchies share the same name.

meustrus3 years ago

Re-Rooted Permalinks plugin

comment:2 follow-up: meustrus3 years ago

  • Severity changed from normal to minor
  • Type changed from defect (bug) to feature request

@solarissmoke: You made a good point, and I've been forced to conclude that the best way to solve my problem is with a plugin. I've finally gotten around to writing such a plugin, which is attached. Not that this is the best place for plugin review, but I'd at least like feedback on the name before I try to get it published. I couldn't think of a better name and I'm afraid this one isn't very self-descriptive.

comment:3 in reply to: ↑ 2 SergeyBiryukov3 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Looks like plugin material indeed.

Note: See TracTickets for help on using tickets.