Problem/Motivation

In a similar way that Views display extenders at #2387149: Display extenders are not possible to describe with config schema do, hook_editor_default_settings() and hook_editor_default_settings_alter() go against the configuration system's assumptions. In the configuration system we assume that we know the owners of each piece (so for example configuration entities depend on all their requirements). However the way that hook_editor_default_settings() and hook_editor_default_settings_alter() allowed to work, they may add arbitrary new settings without ownership. This is not deployment friendly and cannot be described by config schema.

The editor_test module demonstrates adding two new settings that are not supported by the 'unicorn' editor originally.

/**
 * Implements hook_editor_default_settings().
 */
function editor_test_editor_default_settings($editor) {
  if ($editor === 'unicorn') {
    return array(
      'rainbows' => TRUE,
      'sparkles' => TRUE,
    );
  }
}

/**
 * Implements hook_editor_default_settings_alter().
 */
function editor_test_editor_default_settings_alter(&$settings, $editor) {
  if ($editor === 'unicorn' && isset($settings['sparkles'])) {
    $settings['sparkles'] = FALSE;
  }
}

Proposed resolution

Editors support using plugins, which CKEditor module does already. This supports pluggable settings. The config entity system itself allows for modification of settings too, so the altering hooks are not required as a special parallel API. They were added before the config entity API was in place.

This issue should also make QuickEditIntegrationTest participate in strict schema checking again. This was removed in #2387141-18: Missing field configuration schemas across core tests.

Remaining tasks

Commit.

User interface changes

None.

API changes

The hook_editor_default_settings() and hook_editor_default_settings_alter() hooks are removed.

Files: 
CommentFileSizeAuthor
#19 interdiff.txt1.56 KBGábor Hojtsy
#19 rm_editor_default_settings-2389697-19.patch8.06 KBGábor Hojtsy
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,066 pass(es). View
#16 rm_editor_default_settings-2389697-16.patch6.87 KBWim Leers
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,109 pass(es), 1 fail(s), and 0 exception(s). View

Comments

Gábor Hojtsy’s picture

Issue summary: View changes
Wim Leers’s picture

There's no actual reason for that example to violate config schemas, those settings were just funny examples to pick back in the day that we didn't have config schemas.

The question is do we want to have the capability to alter in arbitrary settings (in which case we'd need to use the Third Party Settings API). The answer to that is "no". At least, I don't see a reason currently. If necessary, we could still add that in Drupal 8.1.0 or later.

Gábor Hojtsy’s picture

Priority: Critical » Normal
Status: Active » Postponed
Issue tags: -D8 upgrade path +Needs tests

I am fine with that. I don't have enough info on what editors should support to complain about that :D In that case though, we should (a) postpone this on #2387141: Missing field configuration schemas across core tests and (b) build in settings filtering to not allow additional settings. The same was done in field settings, formatters, etc. For example this is in FormatterPluginManager

    // Filter out unknown settings, and fill in defaults for missing settings.
    $default_settings = $this->getDefaultSettings($configuration['type']);
    $configuration['settings'] = array_intersect_key($configuration['settings'], $default_settings) + $default_settings;

We also need tests that additional settings cannot be added. Also demoting to normal then and removing the D8 upgrade path tag.

Gábor Hojtsy’s picture

So what is the point of editor_default_settings then? If we are to filter down settings to the keys allowed by getDefaultSettings() only (like we do with fields, widgets, etc) then hook_editor_default_settings() would not have the chance to add any new keys (or change values, since we only use it as additive). So there is no point in that hook then? There is only the point of the alter hook then to modify defaults.

From \Drupal\editor\Entity\Editor::__construct().

    $default_settings = $plugin->getDefaultSettings();
    $default_settings += \Drupal::moduleHandler()->invokeAll('editor_default_settings', array($this->editor));
    \Drupal::moduleHandler()->alter('editor_default_settings', $default_settings, $this->editor);
Wim Leers’s picture

That's a very good point. I think you're right.

Wim Leers’s picture

I'm almost wondering whether we should remove both hooks? You can use the standard config entity hooks/events to make alterations. It seems there's no value in keeping them?

(I've always found them strange anyway. IIRC it was quicksketch who wanted them.)

Gábor Hojtsy’s picture

I don't think we have had the config entity system in its complete form back then...

Gábor Hojtsy’s picture

OTOH this is the API docs for the defaults hook:

 * Modules that extend the list of settings for a particular text editor library
 * should specify defaults for those settings using this hook. These settings
 * will be used for any new editors, as well as merged into any existing editor
 * configuration that has not yet been provided with a specific value for a
 * setting (as may happen when a module providing a new setting is enabled after
 * the text editor has been configured).
 *
 * Note that only the top-level of this array is merged into the defaults. If
 * multiple modules provide nested settings with the same top-level key, only
 * the first will be used. Modules should avoid deep nesting of settings to
 * avoid defaults being undefined.

So looks like the assumption is modules extending editors with new features that would store settings on the editor object. Is there some documented use case for this?

Wim Leers’s picture

I don't think we have had the config entity system in its complete form back then...

Exactly.

So looks like the assumption is modules extending editors with new features that would store settings on the editor object.

Indeed. But by now, Editor module supports Drupal plugins that add additional editor plugins (e.g. a "Smiley plugin" for CKEditor), and if they have settings, it's required for them to add a schema. I think that ever since we have that, this actually became obsolete.

Is there some documented use case for this?

No.

Gábor Hojtsy’s picture

So where are those plugins supposed to store their settings? Looking at editor.editor.*, its settings key is dependent on the editor type and nothing else.

Wim Leers’s picture

editor.schema.yml has this:

editor.editor.*:
  …
  mapping:
    …
    settings:
      type: editor.settings.[%parent.editor]

which is then implemented by ckeditor.schema.yml:

editor.settings.ckeditor:
  type: mapping
  label: 'CKEditor settings'
  mapping:
    toolbar:
      …
    plugins:
      type: sequence
      label: 'Plugins'
      sequence:
        - type: ckeditor.plugin.[%key]

Where at the bottom you can see that each Drupal plugin representing a CKEditor plugin can specify a schema for the settings for that CKEditor plugin. One example of that exists:

# Plugin \Drupal\ckeditor\Plugin\ckeditor\plugin\StylesCombo
ckeditor.plugin.stylescombo:
  type: mapping
  label: 'Styles dropdown'
  mapping:
    styles:
      type: string
      label: 'List of styles'
Gábor Hojtsy’s picture

Ok, so I guess we can assume that contrib modules should be able to extend editors that DO support plugins which is not baked into the default editor schema but it needs to be editor specific anyway. I am fine with that.

Wim Leers’s picture

Status: Postponed » Needs review
FileSize
6.07 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch rm_editor_default_settings-2389697-13.patch. Unable to apply patch. See the log in the details link for more information. View

Exactly.

Basically, those 2 hooks allow you to write invalid config. We don't want that. Removing them fixes that. Here's a patch.

Gábor Hojtsy’s picture

Status: Needs review » Needs work

We also need to remove this hunk in this patch:

 class QuickEditIntegrationTest extends QuickEditTestBase {
 
   /**
+   * Set to TRUE to strict check all configuration saved.
+   *
+   * @see \Drupal\Core\Config\Testing\ConfigSchemaChecker
+   *
+   * @todo Altering not schema compatible. https://www.drupal.org/node/2389697
+   *
+   * @var bool
+   */
+  protected $strictConfigSchema = FALSE;
+
+  /**
    * {@inheritdoc}
    */
   public static $modules = array('editor', 'editor_test');

Was added in #2387141: Missing field configuration schemas across core tests to work around the fail.

Gábor Hojtsy’s picture

Issue tags: +Ghent DA sprint
Wim Leers’s picture

Status: Needs work » Needs review
Issue tags: -Needs tests
FileSize
6.87 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,109 pass(es), 1 fail(s), and 0 exception(s). View
869 bytes

Done.

The last submitted patch, 13: rm_editor_default_settings-2389697-13.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 16: rm_editor_default_settings-2389697-16.patch, failed testing.

Gábor Hojtsy’s picture

Status: Needs work » Needs review
FileSize
8.06 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,066 pass(es). View
1.56 KB

The unit test will not need the module handler I believe. The Editor is not dependent on that anymore.

Wim Leers’s picture

Haha, that's EXACTLY the patch I was just uploading :)

Gábor Hojtsy’s picture

Title: Editor settings altering not compatible with config schema assumptions » Editor settings altering not needed (and not compatible with config schema assumptions)
Priority: Normal » Major
Issue summary: View changes
Status: Needs review » Reviewed & tested by the community

Nice, so you think my part looks good, I think yours does :)

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to 8.x. Thank you!

  • Dries committed 3e33607 on 8.0.x
    Issue #2389697 by Wim Leers, Gábor Hojtsy: Editor settings altering not...

Status: Fixed » Closed (fixed)

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

YesCT’s picture

Issue tags: -Configuration schema. Configuration system +Configuration system, +Configuration schema

fixing a tag so I can delete the wrong one.