[wp-trac] [WordPress Trac] #20201: wp.Options lies about the updatability of options.

[WordPress Trac]

#20201: wp.Options lies about the updatability of options.
-----------------------------------+-----------------------------
 Reporter:  westi                  |       Owner:  westi
     Type:  defect (bug)           |      Status:  new
 Priority:  low                    |   Milestone:  Future Release
Component:  XML-RPC                |     Version:  3.4
 Severity:  normal                 |  Resolution:
 Keywords:  3.5-early westi-likes  |
-----------------------------------+-----------------------------

Comment (by westi):

 Replying to [comment:4 nacin]:
 > I think this makes sense, but it also makes me wonder what the
 definition of 'readonly' is. There are two ways to look at it: A) the
 option is generally writable, B) the current user can write to a writable
 option.
 >
 > Currently, we're dealing with method A. This patch will change it to
 method B.
 >
 > I doubt many applications are using wp.getOptions to determine generally
 writable fields, but I could understand how the UI could be implemented
 differently, based on the context. Say, text for a read-only option,
 versus a disabled field if they don't have the ability to edit that
 option.

 Agreed, I think method A is wrong here and method B is right.

 As an application developer I would want to be able to write an
 intelligent UI which used the read-only status to determine how my ui
 presented options to the user.

 Switching to B allows us to also change our view on whether or not things
 are read-only in future more simply too because the API gives a
 application a true view of the current read/write status of the options.

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