[wp-trac] [WordPress Trac] #29615: Hierarchical Post Type 'Default' Permalinks
WordPress Trac
noreply at wordpress.org
Wed Sep 10 16:35:30 UTC 2014
#29615: Hierarchical Post Type 'Default' Permalinks
--------------------------+-----------------------------
Reporter: loushou | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Permalinks | Version: 4.0
Severity: normal | Keywords:
Focuses: |
--------------------------+-----------------------------
'''Intro'''
I recently helped release a plugin that I have worked on for a while now.
Until now, every environment that has used this plugin has been using
'non-default' permalinks, usually something involving %postname%.
Yesterday I as doing some testing on a clean, unmodified install of
WordPress and found that my post permalinks are not working. After some
short investigation this morning I found out why, which I will explain in
a second. Also, I did some checking on my various legacy dev environments
and have found that this problem has been around since at least 3.2.1.
Here is a detailed explanation of the problem and it's roots:
'''My Setup(s)'''
I have verified that this problem exists in as early as version 3.2.1 and
as late as version 4.0 (official release). My dev environments span the
gamut between those versions, and this problem exists in all of them.
'''Description'''
The basic problem boils down to one key issue: there is a mismatch in
permalink generation and permalink interpretation for 'non-page'
hierarchical post types, when using 'default permalinks'
(http://example.com/?p=123).
For 'non-page' hierarchical post types, when we generate the permalink for
the post, while the 'default permalinks' are selected, we use this format:
http://example.com/?post_type=pagename , where 'post_type' is the 'slug
name' of the post type itself, and 'pagename' is equal to
'$post->post_name'. Nothing seems wrong with this until you look at how
the permalink is interpreted by WP_Query. In WP_Query, when looking up a
'non-page' hierarchical post type, we use the 'get_page_by_path()'
function to determine the post_id. This function expects that the pagename
be something like http://example.com/?my_post_type=parent-post/child-post.
In the current format of the permalink (http://example.com/?my_post_type
=child-post), that function tries to find a 'parent post' (post_parent =
0) that is named 'child-post', and thus fails, returning 0 as the post_id.
'''Reproduction Steps'''
- Freshly install any version of WordPress 3.2.1 or later.
- Verify that 'Default' is selected as the permalink structure on
'Settings -> Permalinks'
- Create a hierarchical post type
- Create a parent post of that post type
- Create a child post of that parent post, of that same post type
- Click the 'view post' link in the edit post page of the child post (or
browse to it some other way)
- Observe a 404 error
'''Expectations'''
First, this is only a problem when there is a 'non-page' hierarchical post
type and default permalinks, which by definition means that it is only a
problem when a plugin or theme is active. None-the-less it is a problem.
Second, when clicking the admin 'view post' link, we should be able to
view the post. This logic flaw prevents that in all cases.
Lastly, the get_permalink function (more specifically the
get_post_permalink() function) should return a permalink that can be
interpreted by WP_Query, no matter what permalink structure is used.
'''Additional Information'''
Based on some research, it seems that this whole problem could be solved
by moving one of the if statements in the get_post_permalink() up a couple
ranges, so that it affects both halves of the primary if statement. To be
clearer, in version 4.0, move wp-includes/link-template.php at 262-263 above
line wp-includes/link-template.php at 260.
If this is done, then the else statement on wp-includes/link-
template.php at 267 will also have a hierarchical value for $slug, and thus
will produce proper permalinks. I have tested it any it will still produce
valid non-hierarchical permalinks with this code also.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/29615>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list