Problem/Motivation

Discovered while reviewing #3245720: [drupalMedia] Support choosing a view mode for <drupal-media>.

#3245720: [drupalMedia] Support choosing a view mode for <drupal-media> made <drupal-media data-view-mode> an essential part of the media integration.

But in the issue where the MediaEmbed filter was introduced #2940029-97: Add an input filter to display embedded Media entities.

This also explains why SmartDefaultSettingsTest was failing in https://git.drupalcode.org/project/drupal/-/merge_requests/1796/diffs?co... because it did not expect the data-view-mode attribute to be added to the result of the CKEditor 4 → 5 upgrade path.

Proposed resolution

1. Make <drupal-media data-view-mode> a separate array value in media_media's drupal.elements
2. Add a configuration UI for the CKEditor 5 media plugin: a checkbox that indicates whether content creators are allowed to override the default view mode
3. Implement \Drupal\ckeditor5\Plugin\CKEditor5PluginElementsSubsetInterface, to respect the configuration added in step 2, and hence unset the <drupal-media data-view-mode> when that checkbox is not checked
4. Add a case for media_media to \Drupal\ckeditor5\Plugin\CKEditor4To5Upgrade\Core::computeCKEditor5PluginSubsetConfiguration(), to generate the correct configuration during the upgrade path.
5. Add an extra test case to SmartDefaultSettingsTest, to test a variation of $basic_html_format_with_media_embed: one that has <drupal-media data-view-mode> allowed as well.
6. Add a validation constraint (see #7) to ensure that the media_embed's allowed_view_modes setting is in sync with the media_media CKE5 plugin's new setting.

Remaining tasks

See proposed resolution.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A

Problem/Motivation

GHS attributes are not retained in linked media when no additional GHS attributes are allowed on <drupal-media> element.

This would allow retaining data-bar in linked media:
<drupal-media data-foo> <a data-bar>

However, this does not, even though it should:
<a data-bar>

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

This lays out what remains to be done after #3231364: Add CKEditor 5 module to Drupal core lands in Drupal core.

This plan was originally taken from the IS at #2966864: Add optional support for CKEditor 5 in D9 so we can remove CKE 4 from Drupal 10, and after that from #3201824: Roadmap to core.

Roadmap to Stable

1. Ensure that sites can update from using CKE4 to CKE5 safely when using no contributed CKEditor modules
   1. #3230230: [upstream] Enable table captions; override CKE5's default downcast to generate <table><caption></table> instead of <figure><table><figcaption></figure>
   2. #3247634: [upstream] [drupalImage] Unlinking linked inline images while GHS is enabled: wrapping <a> is impossible to remove
   3. #3268311: [upstream] [drupalMedia] GHS-enabled markup in data-caption crashes CKEditor 5
   4. #3268306: [upstream] [GHS] Custom/unofficial HTML tags not retained: <drupal-media>, <drupal-entity>, <foobar>
   5. #3271418: [upstream] [drupalMedia] Linked media wrapped with <div> doesn't upcast correctly
   6. #3273510: [PP-1] CKEditor 5 crash when multiple alignment buttons are activated due to duplicate configuration
   7. #3274651: [upstream] Impossible to enable <ol type> or <ul type> with GHS
   8. #3276217: GHS attributes are not retained in linked media
2. ✅ Ensure contrib modules can do everything: translations, automatic upgrade path from CKE4 …
   1. Currently none
3. ✅ Ensure CKE5 equivalent plugins of CKE4 generate/support equivalent markup: #3222801: [META] Ensure CKE5 equivalent plugins of CKE4 generate/support equivalent markup
   1. Currently none
4. Ensure CKE5 functionality matches that of Drupal core's CKE4:
   1. #3222756: [upstream] Allow using images from external source
   2. #3222797: [upstream] Upgrade path from CKEditor 4's StylesCombo
   3. #3269657: [drupalMedia] The CKEditor 4 → 5 upgrade path for the media_embed filter should not forcefully allow the `data-view-mode` attribute on `<drupal-media>`
   4. #3274937: Get CKEditor 5 to work in (modal) dialogs
5. Documentation gates:
   1. #3248425: Ensure that all classes and functions in Drupal-specific CKEditor 5 plugins are documented
6. ✅ Theming CKEditor 5
   1. Currently none
7. ✅ Accessibility
   1. Currently none
8. Test coverage, reliability and maintainability matching or exceeding CKEditor 4's:
   1. #3229078: Unit tests for all @CKEditor5Plugin plugin classes
   2. #3231334: Global attributes (<* lang> and <* dir="ltr rtl">): validation + support (fix data loss)
   3. #3247683: Disable CKEditor 5's automatic link decorators (in Drupal filters should be used instead) + explicitly test manual link decorators
   4. #3268983: FilterHtml throws Unsupported operand types error when * used in tag attribute
9. Low-hanging fruit major UX improvements over CKEditor 4:
   1. #3261599: Use CKEditor 5's native <ol start> support (and also support <ol reversed>)
10. Superior configuration UX:
    1. #3228691: [PP-1] Restrict allowed additional attributes to prevent self XSS
    2. #3245967: Messages upon switching to CKEditor 5 are overwhelming
    3. #3261943: Confusing behavior after pressing "Apply changes to allowed tags" with invalid value
11. ✅ Performance
    1. Currently none.

Roadmap after Stable

1. Upstream improvements that would simplify or improve CKEditor 5:
   1. #3226673: API addition: \Drupal\editor\Plugin\EditorPluginInterface::getDefaultSettings() should accept old Editor + Format to generate smart defaults
   2. #3230829: editor_form_filter_format_form_alter() does not remove "editor_plugin" from form state when needed
   3. #3231322: Fix a @todo: move a form alteration to the CKEditor 5 plugin's subform definition
   4. #3231341: Deprecate EditorLinkDialog and EditorImageDialog in Drupal 9, remove in Drupal 10
   5. #3231342: Introduce ConfigEntityForm to standardize use of validation constraints for config entities
   6. #3231347: Add Editor::setFilterformat()
   7. #3231354: [META] Discuss: merge the Editor config entity into the FilterFormat config entity
   8. #3246260: [PP-1] Simplify CKEditor5ImageController once #2940383 lands
2. Obsoleteness of upgrade path in Drupal 11:
   1. #3239012: [late 2023] Deprecate the upgrade path from CKEditor 4
3. Performance:
   1. #3224261: [PP-2] Front-end performance: concatenate CKEditor 5 JS assets for every unique configuration
4. Media improvements
   1. #3196593: Ease the transition to Media: save image uploads in CKEditor 5 as media entities when media is enabled? (or module specific solution if core issue won't land)
   2. #3073901: Determine an upgrade path from CKEditor image button to media library (or module specific solution if core issue won't land)
5. Low-hanging fruit major UX improvements over CKEditor 4:
   1. #3227354: Add support for ckeditor5-autoformat
6. Superior configuration UX:
   1. #3225033: Make image upload plugin depend on editor_file_reference filter + ensure good UX for this
   2. #3227948: Hide incompatible filters

Completed

This section mimics the structure of the above sections.

💯 Roadmap to Alpha

1. ✅ Create the ckeditor5 module
2. ✅ Create an @Editor PHP plugin with the ID ckeditor5.
3. ✅ Create a Drupal.editors JS plugin with the ID ckeditor5.
4. ✅ Getting CKE5 (CKEditor 5) to load at all on the /node/add/article form.
5. ✅ #3201820: Manually test that CKE 5 can be used in off-canvas
6. ✅ Enable a Drupal + CKE5 ecosystem
   1. #3196178: Provide test module to verify contrib can extend CKEditor5
   2. #3200008: Validation and editor settings
7. ✅ A CKE5 configuration UI
   1. #3198297: Toolbar UI for selecting and sorting buttons
8. ✅ Ensure Quick Edit integration works
   1. #3201648: Add test coverage for Quick Edit integration
   2. #3205090: Field html not restored when cancelling Quick Edit
9. ✅ Evaluate CK4 plugins and match features
   1. #3194650: Support media elements and browse media library
   2. #3194111: Support inline image upload
   3. #3201646: Add support for image caption (<img data-caption>)
10. ✅ #3201821: Add JavaScript test coverage for CKE 5
11. ✅ #3206686: IE11 warning for CKE5 in Drupal 9

💯 Roadmap to Beta

1. ✅ #3215506: Plugins should be enableable based on toolbar configuration
2. ✅ Ensure filter_html's HTML restrictions are respected inside CKE5 — tackled in #3201637: Figure out how to prevent data loss during upgrade/migration path
3. ✅ #3206687: Toolbar UI accessibility review
4. ✅ #3201641: Improve the HTML filter configuration UX
5. Enable translation features for CKEditor 5
   1. ✅ #3202664: CKEditor 5's UI language should match Drupal's interface translation

Roadmap to Stable

1. Ensure that sites can update from using CKE4 to CKE5 safely when using no contributed CKEditor modules
   1. Ensure that Arbitrary HTML is not lost: #3216021: Automatically use CKE5's General HTML Support feature on text formats without any TYPE_HTML_RESTRICTOR filter + add `sourceEditing` button
   2. #3201637: Figure out how to prevent data loss during upgrade/migration path
   3. #3216015: Generate CKEditor 5 configuration based on pre-existing text format configuration
   4. #3245079: Automatic upgrade path always enables all <h*> tags when only >=1 was enabled before
   5. #3245320: Automatic upgrade path always disables image uploads — in the UI
   6. #3228464: API for contrib projects to load CKEditor translations
   7. #3227822: [GHS] Ensure GHS works with our custom plugins, to allow adding additional attributes
   8. #3268174: Bug in CKE 4 → 5 upgrade path "format" does not always map to "heading", it could map to "codeBlock" too, or both, or neither
   9. #3269868: [drupalImage] Some Image attributes are lost in edge cases where image upcasts into inline image
   10. #3273527: Upgrade path never configures the ckeditor5_heading plugin to allow <h1>
   11. #3273312: Upgrading from CKEditor 4 for a text format that has FilterInterface::TYPE_MARKUP_LANGUAGE filters enabled
   12. #3268318: [drupalMedia] <a> with GHS allowed attributes downcast wraps data-caption with <a>
2. Ensure contrib modules can do everything: translations, automatic upgrade path from CKE4 …
   1. #3226335: Follow-up for #3216015: allow contrib & custom Drupal modules providing CKEditor 4 plugins to specify their CKEditor 5 equivalents + settings to be migrated
   2. #3228778: Drupal-specific CKEditor 5 plugins should be able to use Drupal's JS translation API: Drupal.t()
   3. #3245723: Follow-up for #3201637: omitting PrimitiveTypeConstraint violations for filter settings is implemented too broadly
   4. #3245807: DX: allow contrib modules to subclass \Drupal\Tests\ckeditor5\Kernel\ValidatorsTest
   5. #3274278: Migrate "codetag" contrib CKEditor 4 plugin to built-in equivalent in core's CKEditor 5
   6. #3273325: CKE5 and contrib: better "next action" description on upgrade path messages
3. Ensure CKE5 equivalent plugins of CKE4 generate/support equivalent markup: #3222801: [META] Ensure CKE5 equivalent plugins of CKE4 generate/support equivalent markup
   1. Infra: #3215466: Attribute values not accounted for in CKEditor5PluginManager::getProvidedElements
   2. Infra: #3207660: Allow using a subset of the tags supported by the enabled CKEditor 5 plugins
   3. #3222851: <cite>
   4. #3222847: <img width height>
   5. #3222838: Configure basicStyles.Italic to output <em> instead of <i>
   6. #3222842: <a hreflang> + <blockquote cite>
   7. #3222847: <img width height>
   8. #3220293: Make all supported heading types visible in the UI
   9. #3222840: <ol start>
   10. #3222852: <dl> <dt> <dd> by introducing "Manually editable HTML tags" configuration on Source Editing
   11. #3224256: <h* id> (or more generically: <$block id>)
   12. #3222808: Follow-up for #3201646: markup in image captions is lost
   13. #3228346: Follow-up for #3222852: revert ineditable attributes (<blockquote cite> and <a hreflang>) now that Source Editing plugin can handle arbitrary elements & attributes
   14. #3246168: Images are not linkable through UI; already linked images are unlinked (data loss!)
   15. #3246169: Embedded media are not linkable through UI; already linked embedded media are unlinked (data loss!)
   16. #3259493: [GHS] Unable to limit attribute values: ::allowedElementsStringToHtmlSupportConfig() does not generate configuration that CKEditor 5 expects
   17. #3246365: [drupalMedia] Show the Image Media's default alt text that is being overridden
   18. #3260853: [GHS] Partial wildcard attributes (<foo data-*>, <foo *-bar-*>, <foo *-bar>) and attribute values (<h2 id="jump-*">) not yet supported
   19. #3260869: Resolve mismatch between <$block> interpretation by CKEditor 5 and Drupal
   20. #3268860: Elements wrapping <drupal-media> are not retained
   21. #3268307: $block wildcard resolves into a superset of the actual $block tags
4. Ensure CKE5 functionality matches that of Drupal core's CKE4:
   1. #3201646: Add support for image caption (<img data-caption>)
   2. #3211050: Add "Alignment" plugin
   3. #3211125: Add "Block Indentation" plugin, but only allow list indentation
   4. #3211282: Add plugins which are provided as a part of essential plugin: Undo/Redo
   5. #3211610: Add "Horizontal line" plugin.
   6. #3227871: Add ckeditor5-paste-from-office to allow pasting from Microsoft Office & Google Docs
   7. #3227875: Add ckeditor5-remove-format to allow removing formatting from pasted content
   8. #3227890: Add ckeditor5-special-characters to allow inserting special characters for users that do not know the native picker
   9. #3247246: Attribute value encoding not compatible with Xss::filter()
   10. #3248448: Dialog loading text is unstyled
   11. #3260554: [drupalMedia] Support alignment on <drupal-media>
   12. #3246380: [drupalMedia] Media previews do not update after alt text was modified
   13. #3224652: [drupalImage] Add ckeditor5-image's imageresize plugin to allow image resizing
   14. #3246385: [drupalMedia] Support captions on <drupal-media>
   15. #3264775: [drupalMedia] Toolbar should be visible when element inside <drupalMedia> is focused
   16. #3264727: [drupalMedia|drupalImage] Allow removing data-align in the UI, and making an image inline
   17. #3245950: [upstream] <script> tag support in GHS
   18. #3256566: [upstream] <style> tag support in GHS
   19. #3263384: Add ckeditor5-code-block package and CodeBlock plugin
   20. #3245720: [drupalMedia] Support choosing a view mode for <drupal-media>
5. ✅ Documentation gates:
   1. #3205654: ckeditor5_hook_help()
   2. #3201186: Create ckeditor5.api.php (the core equivalent of README.md) + CKEditor5PluginDefinition::toArray()
   3. #3243850: hook_ckeditor5_plugin_info_alter()'s example sets ['drupal']['config'], but that's not one of the documented definition properties
   4. #3248430: Improve Drupal.ckeditor5 documentation
6. Theming CKEditor 5
   1. #3202666: Follow-up for #3198297 Improve admin CSS DX
   2. #3194084: Support functionality equivalent to ckeditor_stylesheets
7. Accessibility
   1. #1872206: Improve CKEditor toolbar configuration accessibility
   2. #3218252: Toolbar configuration fieldset aria cleanup
   3. #3218260: Safari focus outline on buttons leaves artifacts after blur
   4. #3207451: Toolbar UI Button size accessibility
   5. #3238257: Fragment link pointing to <textarea> should be redirected to CKEditor 5 instance when CKEditor 5 replaced that textarea
   6. #3245735: Follow-up for #3222852: validation errors are not associated with the correct form element
   7. #3258030: Text fields using CKEditor 5 do not get visual error indicator
   8. #3258668: Extraneous closing parentheses and curly brace in visually-hidden button description text
   9. #3231321: Improve keyboard accessibility in a particular edge case
   10. #3261942: Compatibility issues with inline form errors
   11. #3218297: Voiceover + Safari reads aria-describedby twice when focusing toolbar button
   12. #3248440: [drupalMedia] Media embed attributes are rendered in container div in editing view
   13. #3239423: Toolbar UI accessibility review: round 2
   14. #3270112: Excessive aria-live announcing from ckeditor5-admin-help-message live region
   15. #3270110: Toolbar config items missing "press arrow to do {x}" instructions for screenreaders
   16. #3270108: Editor does not load when using Edge + WHCM
   17. #3222757: [drupalImage] Make image alt text required or strongly encouraged
8. Test coverage, reliability and maintainability matching or exceeding CKEditor 4's:
   1. #3206522: Add FunctionalJavascript test coverage for media library
   2. #3201641: Improve the HTML filter configuration UX
   3. #3228920: Improve internal consistency: consistent variable names and return type syntax
   4. #3231327: Plugin definition DX: validate ckeditor5.drupal.elements items
   5. #3231362: Refactor ImageUpload's ::validateImageUploadSettings() into the proper validate and submit methods
   6. #3228505: Plugin definition DX: automatically check for plugin definitions whether their ::getDefaultSettings() matches the config schema
   7. #3243867: ckeditor5_module_implements_alter() looks like it has incorrect logic
   8. #3245400: Add an @throws PHPDoc everywhere exceptions are thrown
   9. #3246280: Defense in depth: add anti-CSRF token to this module's routes
   10. #3246521: Make plugin.manager.ckeditor4to5upgrade.plugin a private service
   11. #3246524: Make more (all?) classes @internal
   12. #3247711: Simplify and accelerate builds: update our use of the CKEditor 5 DLL manifest
   13. #3248188: Plugin definition DX: validate drupal.conditions
   14. #3248423: Decide how CKEditor 5-provided types should be referenced
   15. #3259174: Add missing CKE5 SmartDefaultSettings test coverage (wildcard tag with unsupported attribute)
   16. #3228334: Refactor HTMLRestrictionsUtilities to a HtmlRestrictions value object
   17. #3206523: Add FunctionalJavascript test coverage for image upload
   18. #3267721: Add DrupalCI step for ensuring that CKEditor 5 build files are build correctly
   19. #3231337: [drupalMedia] Remove manual dataDowncast from DrupalMediaEditing
   20. #3231328: SmartDefaultSettings should select the CKE5 plugin that minimizes creation of HTML restriction supersets
   21. #3228580: Follow-up for #3222852: additional test coverage for real-time validation race conditions
   22. #3265626: Changes to "Manually editable HTML tags" lost if form is submitted without triggering AJAX
9. Low-hanging fruit major UX improvements over CKEditor 4:
   1. Currently none
10. Superior configuration UX:
    1. #3201641: Improve the HTML filter configuration UX
    2. #3216015: Generate CKEditor 5 configuration based on pre-existing text format configuration
    3. #3226694: Follow-up for #3216015: refactor SmartDefaultSettings to return messages rather than sending them
    4. #3248177: Language toolbar item cannot be removed from the toolbar
    5. #3259443: Plugin settings do not appear when a configurable plugin is added AFTER removing all buttons
    6. #3261585: Remove IE11 warning for CKEditor 5 in Drupal 10, since Drupal 10 does not support IE anyway
    7. #3260857: Expand SourceEditingRedundantTagsConstraintValidator to also check attributes and attribute values
11. Performance
    1. #3248469: Research if the CKE off-canvas CSS reset could be optimized
    2. #3264512: Enable aggregation for CKEditor 5 assets
    3. #3260032: CKEditor 5 adds ie11.user.warnings library to every page, triggering a FOUC even for anonymous users
12. ✅ Moving things into core that can only happen once it is in core:
    1. #3231324: Use core icons where possible after moving to core
    2. #3231325: Use pre-existing filter format config from YAML instead of duplicating it in PHP

Steps to reproduce

Create a view (page) that:

1. Has an exposed search input
2. Ajax is enabled
3. Exposed form style is Input required

Expected behaviour

When performing an empty search to get all results, using the pagination to go to the next page should display the second page results.

Actual behaviour

The second page does not show any results. Instead, the view displays as it would when first visiting the page.

Problem and possible solution

The Drupal.Views.parseQueryString function in base.js does not return an argument if its value is an empty string. Therefore, when performing an empty search and navigating to the second page results, the empty search query is removed from the parameters and displays the view with no results.

The culprit is this portion of code:

if (pair[0] !== 'q'&& pair[1]) {
        args[decodeURIComponent(pair[0].replace(/\+/g, ''))] = decodeURIComponent(pair[1].replace(/\+/g, ''));
}

Because the value of pair[1] is an empty string, the argument does not get added to the args array.

A possible fix could be changing the statement to check if pair[1] !== 'undefined' and this would allow for empty strings. However, I'm unsure of all the potential use cases and unsure if this would invalidate a use case that I'm unaware of.

Problem/Motivation

See https://git.drupalcode.org/project/drupal/-/blob/9.4.x/core/modules/cked...

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Go to media library form, and select a media(image) file and upload an image, now you will see, you can select multiple image files. and when you submit the form. it will through an error that multiple media files are not allowed and when we try to remove them, it doesn't work and media files doesn’t removed.

I have added a screenrecording for reference.

Problem/Motivation

We added support for markup in data-caption in #3222808: Follow-up for #3201646: markup in image captions is lost. However, we only ever tested data-caption with data that upcasts into $text. However, there are examples of valid child elements of <figcaption> that would upcast into a model element (e.g. <section> would be a valid child of <figcaption).

Steps to reproduce

1. Create new text format that has Drupal Media + Image captions enabled and add <section> to source editable elements
2. Create content using the new text format
3. Embed media to the content and enable captions
4. Add <section> to the data-caption value in source editing
5. Return back to editing 💥

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Currently you need to specify alpha, beta or rc, to download the latest Drupal 10 release with Composer:

$ composer create-project -n drupal/recommended-project:^10.0.0-alpha

It would be great if this syntax was supported, so you automatically got alpha-3, alpha-4, beta-1, rc-1, etc. when they were ready:

$ composer create-project -n drupal/recommended-project:^10

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

I've setup a content type having several field groups configured as horizontal tabs with field collections inside it (several ones including text, dropdowns, date, etc) one field collection for each field group (tab)

Im using:
Field collection 7.x-1.0-beta3+4-dev
Fieldgroup 7.x-1.1
File entity 7.x-2.0-unstable3+21-dev
Entity API 7.x-1.0-rc2+0-dev
Field Collection Table 7.x-1.0-beta1

Everything is working fine except for the issue of having 1 added empty row for each time I save the node. I know there's a bug report about that and Its in progress.

When I hit the remove button on each row to remove those empty lines (from the bottom-up), happens this:

1st row: deleted OK

2nd row: deleted OK but I got the following on the FF javascript console:

Error: $("#" + base, context).once is not a function
Source File: (obscured)/node/123/edit
Line: 16

3rd row: looks like goes to server, but when the "working" animated gif dissapears, nothing happens and I got this on javascript console:

Error: $("fieldset.path-form", context).drupalSetSummary is not a function
Source File: (obscured)/sites/all/modules/pathauto/pathauto.js?m3nlsr
Line: 5

Im setting this before that line on the other module's scripts

if (typeof jQuery.fn.drupalSetSummary == 'undefined') {
  return;
}

and works, but then another module (like metatag) that uses drupalSetSummary raises the error. etc.

Looks to me like jQuery is breaking and then everything that depends on it cease to work.

Plus, if I try to save the node on this instance (when remove button stopped working) im getting "An illegal choice has been detected. Please contact the site administrator."

I cannot find $("#" + base, context).once on the module's code to see whats going on. Any help?

Edit:
Additional data: http://drupal.org/node/445130#comment-2851276
/misc/form.js is loaded on my edit page when I see the source code, but maybe when this module makes ajax calls somehow the drupalSetSummary() function is removed or something.

Thanks for reading this.

Problem/Motivation

If CKEditor 5 is selected as text editor for the Basic HTML format then the "Language" button is added automatically to the toolbar. This is also the case, if the text editor is switched from a CKEditor configuration where the Language button is disabled. (I suppose that would be a regression.)

For the other default text formats (Full and Restricted HTML), the Language button is not automatically added.

The Language button has very limited use in a Drupal site because content languages are organized through the Core modules, and the user experience can be really confusing if HTML markup for languages can also be added within a field. Therefore enabling the Language button should be a concisous choice of a sitebuilder, not the default option.

Steps to reproduce

• Enable the CKEditor 5 module
• Go to the configuration of Basic HTML at /admin/config/content/formats/manage/basic_html
• Change the text editor from "CKEditor" te "CKEditor 5"

Proposed resolution

Do not add the Language button to the default CKEditor 5 toolbar configuration for Basic HTML.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Ckeditor 4 supports them, and they're already available in CKEditor 5, so lets support them.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

There is the desire to make iframes load lazy. See #3167034-23: Leverage the 'loading' html attribute to enable lazy-load by default for images in Drupal core as an example. Currently, there is one iframe usage in core, but lots in contrib.

Steps to reproduce

Proposed resolution

Add a new render element for iframe. We could even get fancy and throw a warning if someone does the anti-pattern of '#tag' => 'iframe' (if we want to).

Continue to use the existing html tag approach. Add a feature to the oembed field formatter to toggle lazy load on/off.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Add validation for so called "global" attributes (see https://html.spec.whatwg.org/multipage/dom.html#global-attributes) allowed or forbidden on all elements to Drupal\ckeditor5\Plugin\Validation\Constraint\FundamentalCompatibilityConstraintValidator.

FilterHtml supports:

<* dir="ltr rtl">

https://html.spec.whatwg.org/multipage/dom.html#attr-dir

<* lang>

https://html.spec.whatwg.org/multipage/dom.html#attr-lang

As proven in #27 and further clarified in #29's refined test coverage (\Drupal\Tests\ckeditor5\FunctionalJavascript\CKEditor5Test::testFilterHtmlAllowedGlobalAttributes()), this represents a data loss bug in HEAD.

Steps to reproduce

1. Data loss: content like this would have its lang and dir attributes stripped:
   

   <p dir="ltr">Hello World</p><p dir="rtl">مرحبا بالعالم</p>
   

2. Validation: no warning about not supporting these global attributes is provided.

Proposed resolution

1. Add support for <*> to \Drupal\ckeditor5\HTMLRestrictions as per \Drupal\filter\Plugin\Filter\FilterHtml::getHTMLRestrictions()— and require that this tag has attributes listed for it, because this tag on its own is absolutely meaningless.
2. Fix the data loss bug by adding ckeditor5_globalAttributeDir + ckeditor5_globalAttributeLang CKEditor 5 plugins that use GHS to prevent the data loss, and automatically enable them for text formats using filter_html.

Remaining tasks

Reviews.

User interface changes

None.

API changes

None. \Drupal\ckeditor5\HTMLRestrictions is entirely internal.

Data model changes

None.

Problem/Motivation

The current patch in #3231364: Add CKEditor 5 module to Drupal core adds ~390 new dependencies on top of the current ~300 core dependencies. The growing number of third party JavaScript dependencies make it unreasonable to evaluate and monitor each dependency individually. While most of the dependencies are used only in the development environment, many of them are used one way or another to build the application from source, meaning that they could impact code that is run in production environments.

Proposed resolution

Allow reviewing built assets by providing a build tool that doesn't minify the assets to reduce the risk of security issues being added. This allows reviewing changes to the minified build files with the following process:

1. Create new branch for the development build
2. Build files using development build and commit changes
3. Go back to the development branch
4. Apply patch
5. Rebuild files using development build
6. Compare against the branch create earlier

Remaining tasks

TBD

User interface changes

N/A

API changes

TBD

Data model changes

TBD

Release notes snippet

TBD

Problem/Motivation

It is desirable to be able to output table rows in multiple tbody elements. This can be used for semantic grouping and styling.

One use case (original report): The possibility to group table rows with tbody is needed for the redesigned permissions page, #30843: Redesign permissions page. Even though that is probably a rare case the functionality could be useful in other situations as well, e.g. if you would like to have a group of rows to have a distinct color.

Proposed resolution

Here is some example code to illustrate:

<table>
  <thead>
    <tr><th>...header information...</th></tr>
  </thead>
  <tbody class="even collapsible collapsed">
    <tr><td>...first row of block one data...<td></tr>
    <tr><td>...second row of block one data...<td></tr>
  </tbody>
  <tbody class="odd collapsible collapsed">
    <tr><td>...first row of block two data...<td></tr>
    <tr><td>...second row of block two data...<td></tr>
    <tr><td>...third row of block two data...<td></tr>
  </tbody>
</table>

Remaining tasks

1. Agree on the properties which will be used to express this in render arrays.
2. Implement by updating template_preprocess_table() and table.html.twig.

User interface changes

None; this is a feature for developers.

API changes

template_preprocess_table() accepts a new variable, #rowgroups:

#rowgroups = [
  [
    'rows' => $rows, // Same as #rows.
    ..., // Attributes to put on the tbody.
  ],
  $more_rows_1, // Further rowgroups.
  $more_rows_2,
];

If both #rowgroups and #rows are specified, put the #rows in their own tbody before the contents of #rowgroups.

Problem/Motivation

Steps to reproduce:

1. Create a view using a user contextual filter. Set the user contextual filter up to fall back to the current user.

2. Check the exported views YAML and see it has the route cache context.

This is because ArgumentPluginBase always adds the url cache context.

 /**
   * {@inheritdoc}
   */
  public function getCacheContexts() {
    $contexts = [];
    // By definition arguments depends on the URL.
    // @todo Once contexts are properly injected into block views we could pull
    //   the information from there.
    $contexts[] = 'url';

    // Asks all subplugins (argument defaults, argument validator and styles).
    if (($plugin = $this->getPlugin('argument_default')) && $plugin instanceof CacheableDependencyInterface) {
      $contexts = Cache::mergeContexts($contexts, $plugin->getCacheContexts());
    }

Proposed resolution

No idea, but if we had a way to specify that the argument is always going to come from the request and never from the URL it might be possible to skip this. Maybe a dedicated User-from-request argument implementing a different interface or something and this overrides that method to not add the URL cache context.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

How can I indent the image to the right so that it starts at the same place as the rest of the objects (see screenshot)?

Problem/Motivation

We went through a few iterations here. The solution landed on is a filter format. See comments in #8 and #10

Proposed resolution

Add a new filter format that replaces the functionality already added to editor_file_reference and move lazy loading logic into it. Enable this new filter, but only if editor_file_reference was enabled. This gives all sites that currently have lazy loading, that same ability. But now gives them the ability to disable lazy loading if they do not want it. This new filter only adds loading="lazy" if the markup on the <img> tag doesn't already designate something else.

History:
In #3167034: Leverage the 'loading' html attribute to enable lazy-load by default for images in Drupal core, lazy loading was added for editor file referenced files. Back at that point, the understanding from many in the industry was that lazy loading was a great win. But then some things were learned and in certain situations, it would be great to disable that. That is what this new filter does. And it does it by moving that feature out of editor_file_reference into a dedicated editor_image_lazy_load filter.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

After pressing "Apply changes to allowed tags" with invalid value in "Allowed HTML tags", the page scrolls up and there's an error message indicating that the value is invalid. However, the "Apply changes to allowed tags" button with the error styles from "Limit allowed HTML tags and correct faulty HTML" have now disappeared. It's unclear how changes to the textarea should be applied now.

Gif for demonstration.

This issue should also fix styling of the text area with the area that was surfaced in #3261942: Compatibility issues with inline form errors

The only indication about errors is not styled appropriately to indicate that's it's describing an error.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In SessionConfiguration we always set a cookie domain even if one is not configured. If the current domain is example.com the cookie domain is set to .example.com and if the domain is www.example.com we set it to .www.example.com. If the cookie domain is set to .example.com then the cookie will also be available on all the sub-domains. It is more secure if it is not.

Note not setting a cookie domain is an OWASP recommendation:

It is recommended to use a narrow or restricted scope for these two attributes. In this way, the “Domain” attribute should not be set (restricting the cookie just to the origin server) and the “Path” attribute should be set as restrictive as possible to the web application path that makes use of the session ID.

Proposed resolution

If we don't set a cookie domain then browsers will automatically consider the cookie host-only (i.e. the request's host must exactly match the domain of the cookie).

This means on browsers other than IE and Edge we are more secure but on those browsers we are the same as now. The question is whether or not this normalisation of behaviour is desired on not.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None