Opened 16 years ago
Closed 12 years ago
#10935 closed defect (bug) (fixed)
WP_Query and is_day() bug
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Milestone: | 3.7 | Priority: | normal |
| Severity: | normal | Version: | 2.8.4 |
| Component: | Canonical | Keywords: | has-patch needs-testing commit 3.7-early |
| Focuses: | Cc: |
Description
When you configure Wordpress with permalinks such as /%year%/%month% and even /%year%/%month%/%day/ there is
a failure when you request URLs like /2009/10/58, because it's still generating the query to the database
(AND YEAR(wp_posts.post_date)='2009' AND MONTH(wp_posts.post_date)='10' AND DAYOFMONTH(wp_posts.post_date)='58').
Also, is_day() returns true, when it should be returning false.
As adding a post with that date is nearly impossible trough the wordpress admin or the database, no posts will be found, so
Wordpress will show "No page found", but with HTTP status 200 OK, not 404 Not Found.
I think it's important to validate the day on the applicacion side, so for some ideas to work correctly under WP
(like take advantage of sticky posts and show all post for the month in day requests), and most importantly to save
those wasted mysql queries.
Of course I could validate the day using a filter, but that is not the general idea!
Attachments (9)
Change History (30)
#2
@
16 years ago
- Keywords needs-patch added
- Milestone set to Future Release
- Severity changed from major to normal
#3
@
16 years ago
- Keywords reporter-feedback added
is_day() == true means that the current query has a day specified so should return true in this case.
I'm not sure I see a bug here.
#4
@
16 years ago
You are right, but the actual bug is in doing the query to the database. I thought that if you validate the day before, you could save those wasted queries. Also, months never have more than 31 days, to querying for day 58 should obviously return false, because it's not a day!
#7
@
13 years ago
- Component changed from Query to Canonical
- Keywords has-patch added; needs-patch removed
If you pass an invalid date to WP_Query, it will fire a query that will fail and then 404. My patch 404s before the query is made and does canonical redirection on bad date URLs.
If it's a day url, and the day doesn't jive with the month: it will redirect to the month. If it's a month url, and the monthnum is 15 or something: it will redirect to the year.
Adds 2 functions: wp_is_valid_day() and wp_is_valid_month()
#8
@
13 years ago
Looky there, PHP has a function called checkdate() which validates day / month / year and takes leap years into account. Boom: http://php.net/manual/en/function.checkdate.php
Patch updated.
#9
@
13 years ago
- Milestone changed from Future Release to 3.6
Patch refreshed against trunk, ditches the new functions, just uses checkdate() - passes all Unit Tests
#10
@
13 years ago
As of 3.5 we have a wp_checkdate() with a filter, I think mostly to support other calendars. This looks great at a glance, otherwise.
#12
@
13 years ago
- Cc kovshenin added
- Keywords needs-unit-tests removed
10935.diff looks sane. 10935.tests.diff adds some unit tests.
#13
@
13 years ago
- Keywords needs-testing added
10935.2.diff fixes a small typo in the previous patch.
#14
@
13 years ago
We should probably use wp_checkdate() (introduced in [21922] for #17180), as noted in comment:10.
#15
@
13 years ago
10935.3.diff uses wp_checkdate(). A concatenated date of the format YYYY-MM-DD is passed in as $source_date.
#16
@
13 years ago
- Keywords commit added
10935.4.diff assigns some variables for better readability.
Ok, I noticed that HTTP status is working, but still is_day() returns true.