[wp-trac] [WordPress Trac] #20712: Wrong data type returned from get_option for "page_on_front" after update_option

WordPress Trac wp-trac at lists.automattic.com
Sun May 20 12:36:54 UTC 2012


#20712: Wrong data type returned from get_option for "page_on_front" after
update_option
--------------------------+------------------------------
 Reporter:  tszming       |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:  3.3.2
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |
--------------------------+------------------------------
Changes (by SergeyBiryukov):

 * keywords:   => has-patch


Comment:

 Replying to [comment:2 tszming]:
 > Need to be careful as the following lines of code does not work

 Confirmed. In `update_option()`, `$newvalue` is passed through
 `sanitize_option`: [[BR]]
 http://core.trac.wordpress.org/browser/trunk/wp-
 includes/option.php?rev=20784#L227

 When comparing `$newvalue` with `$oldvalue`, we apparently assume that
 `$oldvalue` was also sanitized previously, but that doesn't work for
 numeric values, so we end up comparing a number with a string in line 232.

 > The funniest thing is when you replace page_on_front with another option
 such as blog_public then it would be okay. (both return strings in my code
 above)

 `blog_public` doesn't get sanitized by `sanitize_option()` (which may be a
 separate bug), so the check is passed in that case.

 Replying to [comment:3 dd32]:
 > As a result, === shouldn't be used for comparison of core numeric ID's

 Perhaps we should also check for sanitized `$oldvalue`
 ([attachment:20712.patch])? This doesn't seem to break any of our current
 unit tests.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/20712#comment:4>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list