wp.Options lies about the updatability of options.

[westi]

When an XMLRPC client calls this API we give it a readonly status for each of the options returned which lets it know whether or not the options are writable or not.

This status is hardcoded in the code and not capability aware so a user with only subscriber level access is given the impression that they can update options they can't.

A tangentially related issue was raised in #16986.

The simple fix for this bug.

The test cases for this are in ​[UT567]

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.

Replying to 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.

I would love to see this in 3.6 because I also agree that method B is right

Patch still applies, and I think it's the right fix.

Can we commit this?