Opened 7 years ago
Closed 7 years ago
#49368 closed defect (bug) (worksforme)
Posts query is broken after changeset 47181
| Reported by: | audrasjb | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Posts, Post Types | Version: | 5.4 |
| Severity: | normal | Keywords: | |
| Cc: | Focuses: |
Description
Looks like one of the recent changes in wp-includes/class-wp-query.php broke some things in WordPress Core trunk.
Running trunk, there is a 404 on every Posts/Page in front end.
The issue is fixed when restoring the previous wp-includes/class-wp-query.php file.
Related changeset: [47181]
Change History (5)
#3
in reply to: ↑ 1
@
7 years ago
Since get_post_status_object will return null for unregistered post statuses, checking $post_status_obj->public will likely produce warnings.
The purpose of my patch was to check for a valid status object before attempting to get info from it.
#4
in reply to: ↑ description
@
7 years ago
Replying to audrasjb:
Running trunk, there is a 404 on every Posts/Page in front end.
Thanks for catching that!
I can reproduce the issue in [47179], which indeed had some broken logic, not allowing any posts with a public status to be viewed. This was also confirmed by unit test failures on Travis.
However, that should be fixed in [47181], which added an if ( ! $post_status_obj ) check to the else part of the initial condition. This seems to work as expected, and the unit tests also pass.
Unfortunately, [47179] made it into the nightly build, while [47181] did not. The nightly build is now refreshed, could you download it and double-check? Thanks again :)
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
@SergeyBiryukov I made some tests and it looks like it works again if I replace:
with: