#39078 closed defect (bug) (fixed)
Theme starter content pages 404 if multiple auto-drafts were saved
Reported by: | dlh | Owned by: | westonruter |
---|---|---|---|
Milestone: | 4.7 | Priority: | high |
Severity: | normal | Version: | 4.7 |
Component: | Customize | Keywords: | has-patch has-unit-tests commit dev-reviewed |
Focuses: | Cc: |
Description
Steps to replicate running Twenty Seventeen on a "fresh" install:
- Open the Customizer
- Do something that adds new
auto-draft
s of the starter content. For example, refresh the Customizer. - Publish the starter content.
- Visit the frontend and attempt to navigate to one of the starter content page, like "Contact," and see the page 404.
Publishing the starter content publishes the most-recently created auto-draft
, but the earlier ones (with lower IDs) remain. get_page_by_path()
doesn't account for post status, so when you visit the starter content page, the query returns the auto-draft
.
Attachments (6)
Change History (19)
#1
@
8 years ago
- Milestone changed from Awaiting Review to 4.7
- Owner set to westonruter
- Priority changed from normal to high
- Status changed from new to accepted
#4
@
8 years ago
@westonruter The patch fixes the issue in my testing.
I noticed one side effect: If the Customizer loads with starter content, and there is a url
query parameter for a starter content page (like ?url=http%3A%2F%2Fwp.dev%2Fcontact%2F
), the preview will show "not found." It looks like the Customizer attempts to preview /contact/
, which invokes get_page_by_path()
, which in turn queries for a post_name
.
But I got into this scenario as I was reinstalling and refreshing quite a bit during testing, and I'm not sure how it would naturally occur. Plus, if you then click the link to the page in the nav menu, the starter content works as expected.
#5
@
8 years ago
- Keywords commit dev-feedback added; needs-testing removed
@dlh thanks so much for testing. Yes, the scenario you described is to be expected and is not a defect. Since the post_name is empty then only the non-pretty permalinks would ever be used for such starter content.
This ticket was mentioned in Slack in #core by helen. View the logs.
8 years ago
@
8 years ago
Revert wp_unique_post_slug() changes from [39411]/bdd33e9dff: https://github.com/xwp/wordpress-develop/pull/211/commits/8ab4a78ef51182e600b2abdfae074d998929e04a
@
8 years ago
Fix ajax unit tests: https://github.com/xwp/wordpress-develop/pull/211/commits/84b9898
#7
@
8 years ago
I'm not sure whether it was intentional, but starter content attachments still receive a post_name
. When the starter content is published, the slug ends up, e.g., /espresso-2/
.
Either way, 39078.4.diff still fixes the original issue for me.
@
8 years ago
Ensure that attachments also have their post_name set only when publishing: https://github.com/xwp/wordpress-develop/pull/211/commits/c193206575bffc5644f721b07c07b970c3f0c22b
#8
@
8 years ago
@dlh you're absolutely right. Great catch. Fixed in 39078.5.diff.
#10
@
8 years ago
Pages and attachments look good to me in 39078.5.diff.
@dlh another great catch. As we were talking at contributor day, our first thought was to make
get_page_by_path()
exclude auto-draft posts. But this could have the negative effect of making the posts/pages inaccessible in the preview. Also, there could be some plugins that are expectingget_page_by_path()
to include auto-drafts, and so it is dangerous to change that at this point during RC2.So what we discussed together with @mboynes was to leave the
post_name
empty when importing starter content, but to then instead store thepost_name
in postmeta for that post. Then when the post is published, at that time we can supply thatpost_name
at the time of publishing.