We just upgraded WYSIWYG from 2.1 to 2.4. Using TinyMCE 3.2.6.

We have a custom form that contains multiple textareas, each of which should use WYSIWYG. The code that generates the textareas is copied below. It's inside a for-loop that generates form fields for multiple nodes (thus the $nid in the $form array keys). If I revert back to 2.1, the WYSIWYG editors appear correctly, but with any subsequent release (I tried 2.2, 2.3 and 2.4) the WYSIWYG editor does not appear -- the "Input format" selector appears below each textarea, but the WYSWIYG doesn't attach to the field.

Any ideas? Let me know if I can provide more info. Thanks.

$form["$nid:::caption"] = array(
  "$nid:::caption" => array(
    '#type' => 'textarea',
    '#default_value' => $image_node->field_caption[0]['value'],
    '#cols' => 30,
    '#id'=> "$nid:::caption",
  ),
);

$form["$nid:::caption"]['format'] = filter_form($filter_id, NULL, array('format' . $nid));

Comments

surgeonbor’s picture

surgeonbor commented

I should add that the WYSWIYG editor still works in node edit forms. It stopped working only in this one custom form.

twod’s picture

twod
Primary language Swedish
Location Sweden
commented
Status: Active » Postponed (maintainer needs more info)

Could you "unroll" the loop for two or more iterations and post the generated code?

Do you see any errors in the browser's JavaScript console when viewing the form?

surgeonbor’s picture

surgeonbor commented

Sorry, I should have looked for js errors in the first place. There is an error in line 75 of editors/js/tinymce-3.js: "$field.val() is undefined"

I copied line 75 and the preceding lines below. If I remove those lines, the WYSIWYG editors appear and work correctly.

  // Remove TinyMCE's internal mceItem class, which was incorrectly added to
  // submitted content by Wysiwyg <2.1. TinyMCE only temporarily adds the class
  // for placeholder elements. If preemptively set, the class prevents (native)
  // editor plugins from gaining an active state, so we have to manually remove
  // it prior to attaching the editor. This is done on the client-side instead
  // of the server-side, as Wysiwyg has no way to figure out where content is
  // stored, and the class only affects editing.
  $field = $('#' + params.field);
  $field.val($field.val().replace(/(<.+?\s+class=['"][\w\s]*?)\bmceItem\b([\w\s]*?['"].*?>)/ig, '$1$2'));
/* ^^^^ this last line is line 75 */
twod’s picture

twod
Primary language Swedish
Location Sweden
commented

If $field.val() is undefined, it means $('#' + params.field) does not return a jQuery wrapped textfield, probably because jQuery can't find any element with the id in params.field.

Can you check the contents of that variable and compare it to the id of the textarea from the page source?
To be safe, it's easiest to restrict ids to a-z, A-Z, 0-9, - and _.

extexan’s picture

extexan commented

Subscribing... (I *think* I have the same problem.)

twod’s picture

twod
Primary language Swedish
Location Sweden
commented

@ExTexan, Do you get the same error as in #3?
Can you check the variables mentioned in #4?

extexan’s picture

extexan commented

@TwoD, sorry for the delayed reply - had client issues to deal with. :(

I'm not really up on navigating thru the JS part of FireBug yet, so I'm not sure how to inspect the value of that variable, or where to look for js errors, for that matter.

But I can tell you this... in FireBug, I inspect the body field on a regular node (type "page") and compare it to the textarea field from my module. In *my* field, I don't see the extra divs and spans and such that (I assume) ckeditor adds. For example, there's a span with an id of "cke_edit-body" in the "page" node, but not in my page.

Maybe I'm not defining my textarea field correctly. Can you steer me in the right direction?

twod’s picture

twod
Primary language Swedish
Location Sweden
commented

Firebug's Console tab should list any script errors and the Net tab should show you [in red] if any files were not downloaded properly. (Clear/disable cache then reload to have it request all files.)

Can you post the FAPI code declaring your textarea? (You're on D6 too, right?)

extexan’s picture

extexan commented

On Drupal6, correct.

If I did it right, I didn't see any errors nor files not downloaded properly (running on a local virtual host anyway).

Here's the code for my textarea:

  $form['new-msg']['body'] = array(
    '#type' => 'textarea',
    '#rows' => 7,
    '#cols' => 50,
    '#maxlength' => 10000,
    '#default_value' => $form_state['values']['new-msg']['body'],
  );

I don't know if this might be an issue, but I have $form['#tree'] set to TRUE.

twod’s picture

twod
Primary language Swedish
Location Sweden
commented

Since you have

  $form['new-msg']['body'] = array(
    '#type' => 'textarea',
    '#rows' => 7,
    '#cols' => 50,
    '#maxlength' => 10000,
    '#default_value' => $form_state['values']['new-msg']['body'], // Unrelated note: Don't think you need this, default_value is only used if user didn't select a value, so you're assigning it to something the user might not have entered yet. Just assign a value from an existing msg, if one is being edited, instead.
  );

I'm assuming you have

  $form['new-msg']['format'] = filter_form(get_a_default_format_id_here(), NULL, array('new-msg_format'));

just below that? Otherwise Wysiwyg won't recognize it as a "format enabled" textarea and think it can just handle plain text.

Also, you might need to replace new-msg with new_msg.

extexan’s picture

extexan commented

Well, there you have it. That takes care of my problem. Funny that I could go *this* long working in Drupal and never have the need to invoke the filter_form. I guess that's because, other than the "body" field on nodes, I don't really use textarea fields much. And when I do, it's usually on an admin page, where I want plain text anyway.

I had already looked in the documentation for WYSIWYG (i.e. the "readme.txt") for any hint of something I might be missing in the setup, but didn't find anything. I DO see from that that you (TwoD) are one of the maintainers, so I have a suggestion to pass along... Even though the filter_form is a Drupal thing, not a WYSIWYG thing, perhaps including a little blurb in the ReadMe about that would help other Noobs avoid some headaches. I mean, if it makes or breaks the module, it would be good to include a warning about it, don't you think?

Anyway, thanks for your help, and thanks for a great module.

twod’s picture

twod
Primary language Swedish
Location Sweden
commented

The docs we have on the subject are currently linked from the project page, "How to integrate your module (for developers)". Adding a note pointing devs there from the ReadMe sounds like a good idea.

I'll leave this open a little while longer to see if we hear back from surgeonbor.

twod’s picture

twod
Primary language Swedish
Location Sweden
commented
Status: Postponed (maintainer needs more info) » Fixed
twod’s picture

twod
Primary language Swedish
Location Sweden
commented
Category: bug » feature
twod’s picture

twod
Primary language Swedish
Location Sweden
commented
Category: feature » support

...

Status: Fixed » Closed (fixed)

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