Using Edit 7.x-1.0, Drupal 7.26, CKeditor 7.x-1.13, CKeditor library 4.3.2

Changes made to your CKeditor profile do not update the quickedit toolbar until user permissions are altered.

Steps to reproduce:

  1. Logged in as admin user, CKeditor filtered html profile is set to use basic toolbar.
  2. Quick edit a page: Basic toolbar appears as expected.
  3. Alter CKeditor profile to use Full toolbar.
  4. Quick edit a page: It's still using the basic toolbar - problem
  5. Go to permissions, change any permission associated with the logged in user's role. E.g. Check / uncheck "Select method for cancelling own account" permission on authenticated user role.
  6. Quick edit a page: The Full toolbar is used as expected

Could be something to do with https://drupal.org/node/2178567

The behaviour should be documented in README.txt at least ...

Comments

Leo Pitt’s picture

I have narrowed down the conditions for this, it seems that the toolbar does not update until user permissions are changed (even if the user permissions is entirely unrelated to edit).

For example:

  1. Logged in as admin user, CKeditor filtered html profile is set to use basic toolbar.
  2. Quick edit a page: Basic toolbar appears as expected.
  3. Alter CKeditor profile to use Full toolbar.
  4. Quick edit a page: It's still using the basic toolbar - problem
  5. Go to permissions, change any permission associated with the logged in user's role. E.g. Check / uncheck "Select method for cancelling own account" permission on authenticated user role.
  6. Quick edit a page: The Full toolbar is used as expected
Leo Pitt’s picture

Title: Edit does not use CKeditor toolbar defined in CKeditor admin, but default toolbar » Changes to CKeditor quick-edit toolbar are not visible until user permissions are changed
Issue summary: View changes

Edited in light of new info

Wim Leers’s picture

Title: Changes to CKeditor quick-edit toolbar are not visible until user permissions are changed » Changes to CKEditor quick-edit toolbar are not visible until user permissions are changed
Assigned: Unassigned » Wim Leers
Category: Bug report » Support request

#2178567: Backport: Use client-side cache tags & caching to eliminate 1 HTTP requests/page for in-place editing metadata, introduce drupalSettings.user.permissionsHash would indeed be my guess, but CKEditor toolbar configuration data is not cached there at all, so that makes no sense.

I'll have to try to reproduce this.

leeowen’s picture

I had a similar issue where I changed the text format for the body field (the toolbar was far too large for front end editing!).
But it didn't change on the front end. After inspecting the Session Storage it was clear that the toolbar was cached:

{"label":"Body","access":true,"editor":"ckeditor","aria":"Entity node 1, field Body","custom":{"format":"editor","formatHasTransformations":true,"ckeditorSettings":{"defaultLanguage":"en","toolbar":[["Styles","Image","Table"],["Bold","Italic","Underline","Strike"],["NumberedList","BulletedList","-","Outdent","Indent"],["JustifyLeft","JustifyCenter","JustifyRight","JustifyBlock","-","Link","Unlink"]],"enterMode":2,"shiftEnterMode":1,"toolbarStartupExpanded":true...[trimmed]

Clearing the entry for this in the session storage fixed the issue. It is probably cleared by changing permissions in the admin also...

Wim Leers’s picture

Project: Edit » Quick Edit
Version: 7.x-1.0 » 7.x-1.1
Assigned: Wim Leers » Unassigned
Category: Support request » Bug report
Priority: Normal » Minor

Ugh, you're absolutely right! This is not a problem in Drupal 8, because in Drupal 8, the data stored in window.sessionStorage excludes the Text Editor settings; those are loaded independently.

I'd say this is a very low priority issue because:

  1. it only is a problem when changing text format settings, which happens very rarely
  2. it's only "per-browser session" caching, so even just closing a tab will make the problem go away

This should be fixed eventually, but for now, I have more important things to work on first. If a patch is posted, this will be fixed faster though.


The root cause is this:

  public function getMetadata(array $instance, array $items) {
    $format_id = $items[0]['format'];
    $metadata['format'] = $format_id;
    $metadata['formatHasTransformations'] = (bool) count(array_intersect(array(FILTER_TYPE_TRANSFORM_REVERSIBLE, FILTER_TYPE_TRANSFORM_IRREVERSIBLE), filter_get_filter_types_by_format($format_id)));

    // This part does not exist in the equivalent Drupal 8 code, because in Drupal
    // 8 we leverage the new Text Editor module, which takes care of all of this
    // for us. We could send this information in the attachments callback (like in
    // Drupal 8), but this makes the metadata for each field nicely contained,
    // which is simpler.
    // @todo Consider moving this to the attachments callback.
    module_load_include('inc', 'ckeditor', 'includes/ckeditor.lib');
    if ($settings = ckeditor_profiles_compile($format_id)) {
      // …

      // Set the collected metadata.
      $metadata['ckeditorSettings'] = $settings;
    }

    return $metadata;
  }

Whereas the equivalent code in D8 does this:

  function getMetadata(FieldItemListInterface $items) {
    $format_id = $items[0]->format;
    $metadata['format'] = $format_id;
    $metadata['formatHasTransformations'] = $this->textFormatHasTransformationFilters($format_id);
    return $metadata;
  }

Note the ckeditorSettings key in D7 that doesn't exist in D8. In fact, there already is a todo for this in the cited D7 code:

// @todo Consider moving this to the attachments callback.

That's exactly what needs to happen (move the ckeditorSettings part to ::getAttachments()), and that will fix this problem.