Search a bit and could not find duplicate for this one.

The default behaviour for a textarea like:

'flexibody_part_body' => array(
          '#type' => 'textarea',
          '#title' => t('Test'),
          '#default_value' => t('Test'),
          '#rows' => 5,
          '#required' => TRUE,
          '#weight' => 1,
          '#disabled' => FALSE,

is that when "'#disabled' => FALSE" is set the textarea is greyed out and can not be edited. This does not happen when using the TinyMCE plugin.


TwoD’s picture

Version: 6.x-2.0 » 6.x-2.x-dev
Component: Editor - TinyMCE » User interface
Status: Active » Postponed (maintainer needs more info)

Nice catch.
After a quick conversation on IRC we figured we need more user input on this.
What should happen when #disabled is encountered?

Currently, nothing special happens. The editor appears just as if #disabled was not there. You can edit the contents in the editors not relying on the textfield itself, but I'm assuming Drupal will not process the changes and might throw an error.

Should we completely disable Wysiwyg module for this field?
How will users react to not seeing an editor at all if this is normally the case? AJAX/AHAH will complicate things if fields are allowed to re-activate, at least in D6.

A few editors have a 'read-only' mode where nothing can be changed in the editor and it might get a different appearance. Should this be triggered if the editor supports it? Exclude the editor if not?
We'd have to figure out how to handle [editor independent] Drupal plugins in this case. Can they and are they allowed to put WYSIWYG placeholders for things like <!--break--> or the Image Assist/Filefield inline tags?

What do you think?

_rune’s picture

Did a little research on which plugins supports readonly / disabled mode:

  • tinymce: Yes.
  • FCKeditor: Maybe supported by third party script.
  • jwysiwyg: Dont think so.
  • markItUp: No.
  • NicEdit: No.
  • openWYSIWYG: Yes. Found in docs/doc.html in the download.
  • Whizzywig: No.
  • WYMeditor: No.
  • YUI editor: Yes.

Good questions. For plugins _with_ a readonly mode I would prefer triggering that behavior. For plugins _without_ I think the best option would be to still show the editor but add something like:

<span class="wysiwyg-disabled">(This field is disabled and any changes made will be disregarded.)</span>

to the fields description.

We'd have to figure out how to handle [editor independent] Drupal plugins in this case. Can they and are they allowed to put WYSIWYG placeholders for things like

or the Image Assist/Filefield inline tags?

Am uncertain about what you mean by this.

Thx a lot for you reply! Cheers.

_rune’s picture

Status: Postponed (maintainer needs more info) » Active
TwoD’s picture

Drupal plugins have attach/detach methods which get called by Wysiwyg module each time contents are retrieved from or sent to the editor, and the contents are passed via these methods and can be altered. To do this Wysiwyg module registers event listeners using the editor's API, so it could probably use the same API to figure out when the editor is in read-only mode. But it can not know if a certain Drupal plugin should be invoked in this mode. If none, then the user will see <!--break--> instead of the Teaser Break delimiter/placeholder and [img_assist|...] instead of images inserted via that module. During the conversion back and forth between placeholders and tags, it's likely the contents can change in subtle ways. It probably won't be noticed by the user, but Drupal will. If Drupal silently ignores this, we're clear and can invoke all the plugins. Needs investigation.

_rune’s picture

Ah ok thx for explaining. Obviously I dont know the inner workings of wysiwyg, but cant you just call all the plugins you normally would and then turn on the disabled switch after that? If this is stupid just ignore me :)

TwoD’s picture

I forgot to thank you for compiling that list, it will be a great help when implementing this.

I've been looking through the HTML 4 specs (same for XHTML) and they say a disabled element should not be included in the POST data. Given that, it should not matter if the contents of the field changes.

JavaScripts can of course change the state of the field to be enabled again so we'd need some kind of event listener to relay this to the editor itself, unless it can do that on its own. Editors without a read-only mode would of course need to be attached from the start when this happens. It looks like the read-only mode can't be toggled but only set on init, at least for TinyMCE, so we'd probably have to detach and re-attach editors as well.

_rune’s picture

Ahh - beginning to see the problems... it's never easy :)

Perused the source for a bit and it looks like drupal backend does _not_ care if a form element is #disabled or not. The posted value will end up in $form_state['values'] regardless of the #disabled setting, so stuff _needs_ to be done in the frontend to prevent this for non standard textareas, or - as you say - we have to be sure that the editors converts back to a standard disabled textarea before submit...zzz...

TwoD’s picture

Where's the fun in easy? ;)

I think all the editors leave the disabled attribute intact on the original textareas, as those are usually only hidden. Before a form is submitted, any attached editor is always detached and the original textarea is shown again, with updated contents. Like you say it appears that FAPI itself ignores #disabled during validation so no problem there if a field is enabled by JS. I've also confirmed that fields with the disabled attribute are not amongst the POSTed data and D6/7 simply treats this as empty values. Making a non-empty node body disabled will revert it to its default value in a preview or saved node and a title field will fail the empty-value-test since it's required and the non-emptiness test happens before the default value fallback.

Looks like we'll do the check for the 'disabled' attribute in Drupal.wysiwygAttach (wysiwyg.js) and add a flag to the settings passed to each editor implementation so it can decide how to handle that particular editor.
Doing the check on the server would be a lot more complicated since editor settings are sent to the client on a per-format basis.

How to find out if a field is re-enabled will be the hard part, not sure how to do that without checking it at some interval yet.

sun’s picture

wooohooo... reading through this makes me believe we should just skip #disabled fields ;)

#disabled fields are egde-cases anyway, so deferring to D7...8...9...10 won't hurt the 99% use-case and we can re-consider the UX based on actual user feedback.

sun’s picture

Version: 6.x-2.x-dev » 7.x-2.x-dev
Priority: Normal » Critical

Critical for D7, because Filter module disables an entire textarea in case a user does not have access to the stored text format.

TwoD’s picture

Status: Active » Needs review
467 bytes

It turns out that in D7 the editors won't activate at all when the field is disabled. Their settings are added to Drupal.wysiwyg.settings, but the field triggers are not.

When a field is blocked due a user not having permissions to use the active input format, there's no format selector so no need to take that into account.

What if someone sets #disabled using hook_form_alter()?
I tried that on the node form using the snippet below:

 function hook_form_alter(&$form, &$form_state, $form_id) {
   if (!empty($form['#node_edit_form'])) {
      $form['body']['und'][0]['#disabled'] = TRUE; // Weird key ('und') btw.

The body's input format selectbox got disabled too, but without the patch below the editor shows up so the field looks editable. With the patch it much looks like when the user can't use the active format, except the field's contents would have been displayed (if there were any).

Given that not all editors support a read-only mode, how about starting with just this patch?
Like I said earlier I don't know how to properly deal with the event that a field is reactivated, or if we can even detect it reliably, anyway...

I have only tested this with D7 so far.

sun’s picture

Status: Needs review » Fixed
822 bytes

Thanks for reporting, reviewing, and testing! Committed attached patch to HEAD.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

For now, I'm not interested in supporting #disabled textareas in D6, so marking as fixed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.