Problem/Motivation
I created a custom Text Format/Editor profile that uses only two buttons in the CKEditor toolbar: DrupalLink and DrupalUnlink (both of which are part of the plugin \Drupal\ckeditor\Plugin\CKEditorPlugin\DrupalLink). When this Text Format/Editor loads, my browser's developer tools console displays the error message:
/core/assets/vendor/ckeditor/config.js?t=G2T0 404 (Not Found)
The issue appears to be caused because, in the absence of a customConfig property in the CKEditor instance settings, CKEditor attempts to load a config.js file, based on its global default settings. This issue usually doesn't become apparent because most Text Format/Editor profiles use buttons from \Drupal\ckeditor\Plugin\CKEditorPlugin\Internal, which includes the following in its getConfig() method:
// Reasonable defaults that provide expected basic behavior.
$config = array(
'customConfig' => '', // Don't load CKEditor's config.js file.
'pasteFromWordPromptCleanup' => TRUE,
'resize_dir' => 'vertical',
'justifyClasses' => array('text-align-left', 'text-align-center', 'text-align-right', 'text-align-justify'),
'entities' => FALSE,
);
If a Text Format/Editor does not include any buttons from \Drupal\ckeditor\Plugin\CKEditorPlugin\Internal, however, this configuration is not loaded, and CKEditor attempts to load a config.js file, which doesn't exist as part of the Drupal core build.
Proposed resolution
Set a default value for customConfig for all editor instances by adding it to the settings in \Drupal\ckeditor\Plugin\Editor\CKEditor::getJSSettings():
$settings += array(
'toolbar' => $this->buildToolbarJSSetting($editor),
'contentsCss' => $this->buildContentsCssJSSetting($editor),
'extraPlugins' => implode(',', array_keys($external_plugin_files)),
'language' => $display_langcode,
// Configure CKEditor to not load styles.js. The StylesCombo plugin will
// set stylesSet according to the user's settings, if the "Styles" button
// is enabled. We cannot get rid of this until CKEditor will stop loading
// styles.js by default.
// See http://dev.ckeditor.com/ticket/9992#comment:9.
'stylesSet' => FALSE,
// Don't load CKEditor's config.js file.
'customConfig' => '',
);
Remaining tasks
Reviews needed.
User interface changes
None.
API changes
None.
Data model changes
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 2696557-12.patch | 3.89 KB | wim leers |
| #12 | 2696557-12-test_only_FAIL.patch | 2.5 KB | wim leers |
| #5 | editor.editor.links_only.yml | 467 bytes | danmuzyka |
| #3 | filter.format.links_only.yml | 327 bytes | danmuzyka |
| #2 | 2696557-2.patch | 1.44 KB | wim leers |
Comments
Comment #2
wim leersWow, what a find! Amazing that it's only discovered now :)
Can you please export your text editor's configuration and post it here? That'll make it easier to reproduce.
In the mean time, this is IMO the correct solution.
Comment #3
danmuzyka commentedAbsolutely! I'm attaching the files, but also including the code below:
editor.editor.links_only.yml:filter.format.links_only.yml:Comment #4
danmuzyka commentedBy the way, I applied 2696557-2.patch locally and removed my own patch, and I can confirm that the approach in 2696557-2.patch works on my end.
Comment #5
danmuzyka commentedI just realized I uploaded the wrong version of my
editor.editor.links_only.ymlfile in the attachment in my previous comment (though the copy pasted into the content of my above comment is correct). Uploading the corrected version here.Comment #6
alexpottDiscussed with @xjm, @effulgentsia and @cottser we agreed that this is a 8.1.x rc target as it is a good bug fix that can not be commited in a patch release.
Comment #7
wim leersActually, I don't think that's true. This affects 8.0, 8.1 and 8.2. It's a small bugfix for a pretty crazy edge case: when you configure CKEditor to not use any of the typical features: bold, italics, format dropdown, etc. In other words: if you don't use any of the "absolutely basic" functionality, then you run into this.
In other words: this does not cause any regressions, nor any change in behavior. Except in case you aren't using any of those "absolutely basic" things, in which case you're already seeing this 404, but on top of that, you can also resize horizontally and you're getting HTML entities being created. Because this is not added:
This can safely be committed to 8.0, and would be fine to commit to 8.1.1 for example, if this doesn't make it before 8.1.0.
Comment #8
xjm@Wim Leers, in general, we do not allow classes to extend additional interfaces in patch releases, because this could cause collisions in any extending child classes (even if the chance that someone actually extends the class is very theoretical or unlikely). See https://www.drupal.org/core/d8-bc-policy for details. So this would normally be targeted for a minor version.
However, we agreed on it being worth doing for RC, which should avoid that slight risk of semver break.
Comment #9
wim leersAh, I see. I did not think of that in this context — thanks for the explanation, much appreciated!
Comment #10
alexpottLooking at the issue summary - this ought to be testable.
Comment #11
wim leersTotally agreed, this was RTBC'd a bit prematurely.
Comment #12
wim leersComment #14
thpoul commentedTest looks great, marking RTBC. Thank you!
s/et cetera/etc
Just a nit that could be fixed on commit by the committer
Comment #15
alexpottThere's already a for example so et cetera is not necessary. Committed 6205925 and pushed to 8.1.x and 8.2.x. Thanks!
Fixed on commit.