![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
#14088 closed defect (bug) (fixed)
Don't return 404 in backend
| Reported by: | nacin | Owned by: | frankperez87 |
|---|---|---|---|
| Priority: | normal | Milestone: | 3.0.1 |
| Component: | Administration | Version: | 3.0 |
| Severity: | major | Keywords: | has-patch dev-feedback |
| Cc: | Focuses: |
Description
http://wordpress.org/support/topic/415526
Trash all of your posts. wp-admin/edit.php sends a 404 header. In 2.9, this was a 200 header. Even though no posts are found, I don't see a reason for a 404 header in the backend.
Attachments (2)
Change History (10)
#2
@
16 years ago
Worth taking into consideration I think: http://core.trac.wordpress.org/ticket/11312#comment:14
#3
@
16 years ago
- Keywords has-patch dev-feedback added
- Owner set to
- Status new → accepted
- Version → 3.0
Changed the handler for the query in post.php to use query_posts and that did the trick.
#4
@
16 years ago
We also use wp() in wp_edit_attachments_query(), which affects upload.php.
I'm trying to think of what would change by going from wp() to query_posts() (as it has been wp() for some time), and whether it makes sense to repair our regressed logic in the handler instead. I wonder if that is as simple as an !is_admin() check.
#5
@
16 years ago
Since the only thing that was really being used by that line was a query handling for the array $query changing it to query_posts should not affect the other parts of the system. One of the differences i have noticed is in the headers that are sent out. I could look into the wp function and get down to the line that is causing it, but query_posts works just fine. Let me know.
#6
@
16 years ago
That patch is likely a good way to go, but I'm worried about unintended consequences. The !is_admin() check suggested by nacin seems safer for 3.0.1.
This can cause some server issues. Someone reported some nginx issues.