[wp-trac] [WordPress Trac] #20860: Multiple Query String on URL Damage the Page

WordPress Trac wp-trac at lists.automattic.com
Wed Jun 6 22:20:06 UTC 2012


#20860: Multiple Query String on URL Damage the Page
--------------------------+---------------------------------------
 Reporter:  arieputranto  |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Query         |    Version:  3.4
 Severity:  critical      |   Keywords:  needs-testing needs-patch
--------------------------+---------------------------------------
 Since the page generated by WP_Query from the query variables from the
 URL, I tried to add multiple query string on an URL like this:

 {{{
 http://localhost/?cat=1&author=1
 }}}

 For what I've been testing, it's resulting TRUE to both
 $wp_query->is_author and $wp_query->is_category. The problem is that
 WP_Query, based on the given query vars, will generate the page using DB
 request:

 {{{
 SELECT SQL_CALC_FOUND_ROWS  wpdb_posts.ID FROM wpdb_posts  INNER JOIN
 wpdb_term_relationships ON (wpdb_posts.ID =
 wpdb_term_relationships.object_id) WHERE 1=1  AND (
 wpdb_term_relationships.term_taxonomy_id IN (1) ) AND
 (wpdb_posts.post_author = 1) AND wpdb_posts.post_type = 'post' AND
 (wpdb_posts.post_status = 'publish' OR wpdb_posts.post_status = 'private')
 GROUP BY wpdb_posts.ID ORDER BY wpdb_posts.post_date DESC LIMIT 0, 5
 }}}

 On default Twenty Eleven, it returns a Category page with error:

 {{{
 Notice: Undefined property: stdClass::$user_nicename in
 D:\Webserver\wordpress\wp-includes\post-template.php on line 456

 Notice: Undefined property: stdClass::$ID in D:\Webserver\wordpress\wp-
 includes\post-template.php on line 456

 Notice: Undefined property: stdClass::$ID in D:\Webserver\wordpress\wp-
 includes\post-template.php on line 457
 }}}

 Fixing the post-template.php WILL NOT be the solid solution. IMHO, I
 suggest to tweak the WP_Query class a bit to make it decide which query
 var will be use.

 Temporary solution that works for me to handle this situation is
 redirecting visitors when such condition occurred to a custom search
 results page.

 It could be happened once in thousands years, but not if there are
 thousands like me who like to inject queries in some random URL. :)

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/20860>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list