If I edit a global textarea the editor is not loaded, but the normal well known edit form is shown. How can I load the editor in this fields?

CommentFileSizeAuthor
#2 issue-ckeidt-on-views-global-text-area.jpg40.13 KBkendouglass
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dmsmidt’s picture

dmsmidt
he/him
Primary language Dutch
Location Amsterdam 🇳🇱🇪🇺
CreditAttribution: dmsmidt commented

Does the textarea use a input format with a ckeditor profile setup for it?

Check those two pages: admin/config/content/formats and admin/config/content/ckeditor.

If that's not the issue try to give some more info, like: modules installed, ckeditor package version, jQuery version.

Also read the readme and troubleshooting files in the module folder.

Good luck!

kendouglass’s picture

kendouglass CreditAttribution: kendouglass commented
Issue summary: View changes
FileSize
issue-ckeidt-on-views-global-text-area.jpg40.13 KB

Same problem here.

Drupal 7.31
ckeditor 7.x-1.15 (2014-Jul-15)
CKEditor 4.4.3 (standard-all)
Views 7.x-3.8
jQuery v1.4.4

cyberitch’s picture

cyberitch CreditAttribution: cyberitch commented

I also have this issue, anyone found a solution?

BartNijs’s picture

BartNijs CreditAttribution: BartNijs commented

This works as designed. In these files the wysiwig editor is disabled:

views/handlers/views_handler_area_text.inc
views/plugins/views_plugin_exposed_form_input_required.inc

To enable the editor find this line in both files and replace FALSE with TRUE:

'#wysiwyg' => TRUE,

selva8187’s picture

selva8187 CreditAttribution: selva8187 commented

#4 Working good for me Thanks Bartelli

Arunah’s picture

Arunah CreditAttribution: Arunah commented

Thanks Bartelli #4 works

noahterp’s picture

noahterp CreditAttribution: noahterp commented

Instead of hacking Views, you can also alter that property in a custom hook_form_alter() call, such as:

if ($form_id == 'views_ui_config_item_form' && !empty($form['options']['content'])) {
  // Views edit forms: Enable CKEditor
  $form['options']['content']['#wysiwyg'] = TRUE;
}

However, it appears that CKEditor is caching its contents. So if you have multiple textareas within a View — like both Header and Footer text — then the contents of the first textarea you visit will incorrectly reappear in the second one. Reloading the Views admin page will force CKEditor to show the correct contents for the first textarea you then visit, but subsequent textareas will again show the wrong one.

Does anyone know a way to prevent CKEditor from caching its contents here? [We can split this to a separate issue if it's an actual Views or CKEditor bug]

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

----- i'm mistake with branch, sorry -----

noahterp thanks for #7, it works, but now (8.x) "wysiwyg" replace to "editor"

$form['options']['content']['#editor'] = TRUE;

I tried to reproduce the problem of CKEditor cache. I used Header + Header and Header + Footer. No problem. Perhaps it is already solved.

jkstermitz’s picture

jkstermitz CreditAttribution: jkstermitz commented

Updating the views handler and views plugin inc files (and purging cache and browser cache) doesn't work for me (2017). Latest views, drupal 7, etc.

I noticed I have a "views_handler_text_area_custom.inc" file - which has the following in it:

 function options_form(&$form, &$form_state) {
    parent::options_form($form, $form_state);

    // Alter the form element, to be a regular text area.
    $form['content']['#type'] = 'textarea';
    unset($form['content']['#format']);
    unset($form['content']['#wysiwyg']);

    // @TODO: Use the token refactored base class.
  }

Any chance this is overriding my edited file with wysiwyg="TRUE"?? Just fishing for a cause.