Forms API is missing the readonly form field option

webform module seems to get round this like so:

$form_item['#attributes']['readonly'] = 'readonly';

(for example http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/webform/com...).

Changing version since this would be added (first) to 7.x.

Also we have a patch. Let's see what testbot makes of it, though it looks as though it may not apply to 7.x form.inc, even with fuzz.

That looks good. Setting status back to needs review so that testbot can do its worst...!

In D7, the variable name has changed from $form to $element.

Go, bot!

Looks good.

Bump. Quiet important as if people use #disabled while they mean #readonly the gonna run into a security issue, as #disabled does not secure that the user hacks the form and changes the value (or by some JS tools). So on submit the value changes in the DB!

#readonly would be the chance to secure settings.

And yes, there is a usecase. type=value is not always the way you want to work, especially when you think about use experience on edit / add

Passed all tests therefore back to RTBC.

Lots happened since then retest

Still passes :)

Regarding #10, the #6 patch does not fix that, as JavaScript code can alter the readonly HTML attribute as easily as it can alter the disabled HTML attribute. There's a different issue to make #disabled really mean disabled within FAPI input processing: #426056: Server-side enforcement of #disabled is inconsistent.

I'm not too keen on FAPI properties that are ONLY wrappers to HTML attributes. If all you're doing is setting an HTML attribute, that's what #attributes is for. I do think that at least #disabled or #readonly (or some other word that encompasses both) should exist as a FAPI property that ensures that the input is disregarded. I'm not so sure we want two properties that mean the same thing as far as FAPI is concerned, and only differ in the HTML attribute they set. OTOH, given that these are the two words chosen by HTML, I wouldn't be opposed to both properties existing within FAPI, as long as they both cause FAPI to disregard input and are not only wrappers to setting something within #attributes.

I posted a patch in #426056-27: Server-side enforcement of #disabled is inconsistent that incorporates the HTML 'readonly' attribute. I'd like this issue postponed until that issue is resolved. If that issue's resolution doesn't adequately address this issue's needs, this issue can be re-opened at that time. Please feel free to comment on the other issue. Thanks.

#426056: Server-side enforcement of #disabled is inconsistent landed, making #disabled have server-side meaning: FAPI will ignore input for elements whose #disabled is TRUE (so for example, if someone uses Firebug to un-disable an element, and submit input for it, Drupal 7 will not process it). This is an important security improvement, as people writing forms that set #disabled to TRUE generally assume that input for that element won't appear in $form_state['values'] and don't necessarily write their own security checks against users un-disabling an element client-side.

I've argued against introducing a #readonly property, as we would then need to decide whether that too should have server-side enforcement, and if it should, then we'd have two properties meaning the exact same thing with respect to server-side code. Instead, we added a #allow_focus property which can be used in conjunction with #disabled to provide the UI feature of what 'readonly' means for HTML.

If you're writing forms where you don't want server-side enforcement of 'disabled' or 'readonly', but just want what these attributes mean in HTML, then instead of setting #disabled with or without #allow_focus, you can set #attributes['disabled'] and/or #attributes['readonly']. #attributes is the appropriate place for things that should purely pass through to HTML without FAPI interpretation.

Form API documentation does need massive improvement, since it gets stale way too easily because it is too cumbersome to update. #100680: [meta] Make API module generate Form API documentation is working on an approach to make this better.

Please re-open this issue if something hasn't been adequately addressed.

@18: thanks for the comprehensive write-up. Really helpful, much appreciated. :-D

Well this solution is even better. Iam pretty fine with the server-side enforcement of #disabled - but dont forget this will break a lot of current implementations.