Problem/Motivation

The "Edit Media" button disappears when the "Convert line breaks into HTML" filter is enabled.

There's a javascript error.

Uncaught TypeError: Cannot read property 'insertBeforeMe' of null
    at h._setUpEditButton (plugin.js?t=q1mipb:242)
    at plugin.js?t=q1mipb:174
    at Object.success (plugin.js?t=q1mipb:320)
    at c (jquery.min.js?v=3.4.1:2)
    at Object.fireWith [as resolveWith] (jquery.min.js?v=3.4.1:2)
    at l (jquery.min.js?v=3.4.1:2)
    at XMLHttpRequest.<anonymous> (jquery.min.js?v=3.4.1:2)

The issue is that "Convert line breaks into HTML" is wrapping the drupalmedia tag in a `p` tag. The drupalmedia plugin.js assumes that the first element within the widget is the embed and that it has children (so you can call getFirst() on it). Since the `p` tag is empty, calling getFirst() fails returns null, (this is the null which has no insertBeforeMe property).

Proposed resolution

Modify the client-side JavaScript for the media embed filter so that it is able to anticipate the P tag added by filter_autop.

Remaining tasks

• Decide whether to ditch or postpone this work in favor of #3100066: "Convert line breaks into HTML" filter should exclude <drupal-media> tag (see #51-54 for some more info).
• Review and commit

User interface changes

API changes

Data model changes

Release notes snippet

At the moment, it is impossible to post a new comment or add a new patch to the original issue #1356276: Allow profiles to define a base/parent profile.
The problem was reported in #3265696: 5xx on any update to #1356276 issue.
This issue was created to unblock the progress. For full details see original issue #1356276: Allow profiles to define a base/parent profile.

Problem/Motivation

I have created a custom ckeditor5 plugin (run with Drupal 9) and that all works fine for initial editing and output. It creates a custom tag eg: <bbref ver="RSV">Ex 2:32</bbref>
A couple of days later (possibly after 9.5.2 update?) the editor now rejects my tag when it loads saved HTML (or creating new) and replaces it with <span data-ck-unsafe-element="bbref" ver="RSV">Ex 2:32</span> which is styled to be invisible in the editor.

ckeditor's domconverter.js seems to have a hand in this.

There is a method for handling a similar thing with data-ck-unsafe-attribute- (eg https://ckeditor.com/docs/ckeditor5/latest/updating/guides/update-to-31....) but not for unsafe-element and trying the unsafe-attribute method does not seem to work:

// Callback function provides access to the model attribute value
            // and the DowncastWriter
            view: (modelAttributeValue, conversionApi) => {
                const {writer} = conversionApi;
                const cae =  writer.createAttributeElement(
                        'bbref',
                        {
                            ver: modelAttributeValue
                        },
                        {
                            renderUnsafeAttributes: ['ver', 'bbref']
                        });
                console.log('cae');
                //console.dir(cae);        
                return cae;
            }

Current core: 9.5.2
Using full_html text format, 'Limit allowed HTML tags and correct faulty HTML' and 'Correct faulty and chopped off HTML' both disabled.

Steps to reproduce

Add any custom tag to ckeditor (ie using source-edit facility), switch back to normal editing. The text disappears and inspecting the element shows <span data-ck-unsafe-element="mytag" ...

Proposed resolution

Stop ckeditor 5 marking unknown tags.
Provide a method to bypass
Note: you cannot add accepted tags to 'Limit allowed HTML tags and correct faulty HTML' anymore, and notes: 'With CKEditor 5 this is a read-only field....'

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Since the notification the CKeditor is deprecated I changed over to CKeditor 5.
If I want to change my full HTML features, Ido not see any Icon, only text referring to the icons.....

{"undo":{"label":"Undo"},"redo":{"label":"Redo"},"heading":{"label":"Heading"},"style":{"label":"Style"},"specialCharacters":{"label":"Special characters"},"sourceEditing":{"label":"Source"},"bold":{"label":"Bold"},"italic":{"label":"Italic"},"underline":{"label":"Underline"},"code":{"label":"Code"},"codeBlock":{"label":"Code Block"},"strikethrough":{"label":"Strikethrough"},"subscript":{"label":"Subscript"},"superscript":{"label":"Superscript"},"blockQuote":{"label":"Block quote"},"link":{"label":"Link"},"bulletedList":{"label":"Bulleted list"},"numberedList":{"label":"Numbered list"},"horizontalLine":{"label":"Horizontal line"},"alignment":{"label":"Text alignment"},"removeFormat":{"label":"Remove Format"},"insertTable":{"label":"table"},"drupalInsertImage":{"label":"Image"},"indent":{"label":"Indent"},"outdent":{"label":"Outdent"},"textPartLanguage":{"label":"Language"},"drupalMedia":{"label":"Drupal media"}}

If I turn on the old (deprecated) CK editor, then the icons reappear.... see file

Steps to reproduce

No icons shown:
uninstall ck editor
install ck editor 5

Icons shown:

Install ck editor 5
change editor settings to ck editor
When I uninstall ck editor, icons are gone

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When image is resized in CKEditor 4, both height and width attributes are added. The attributes persist if the text format is upgraded to use CKEditor 5. Now if user resizes the image, the width attribute is converted to use percentages. In this process, the height is left untouched which may lead into the image rendering with incorrect proportions in some browsers.

Upstream bug: https://github.com/ckeditor/ckeditor5/issues/5154

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

#3222797: Upgrade path from CKEditor 4's StylesCombo to CKEditor 5's Style added the @ckeditor5/ckeditor5-style plugin.

But its plugin definition had its drupal.elements restricted to just HTML5 elements:

    elements:
      - <$any-html5-element class>

(And it has corresponding validation logic in StyleSensibleElementConstraintValidator— see \Drupal\ckeditor5\Plugin\Validation\Constraint\StyleSensibleElementConstraint::$nonHtml5TagMessage.)

Why?

1. Drupal's CKEditor 4 integration (StylesCombo) never supported setting styles on e.g. <drupal-media>— heck, not even on <img>!
2. In the CKEditor 5 equivalent (Style), images and Drupal media are impossible to support today, because they're implemented as "widgets", and I quote: Widget styling is out of the picture for now.— source: issue 5700. This is fine because this didn't work in Drupal 8 either — see #2642808: [upstream] CKEditor Style for <img> not working because it is an "image" widget + #3117172: Allow CKEditor styles for <drupal-media>.
   For images this is arguably bad, but for Drupal media this is arguably fine: because those allow choosing a view mode already: #3074608: Optionally allow choosing a view mode for embedded media in EditorMediaDialog.
   Combine this with the fact that the Drupal ecosystem is moving from "plain images" to "image media"— especially post-migration from Drupal 7 thanks to migration modules like https://www.drupal.org/project/media_migration, the value of making this work for plain images (<img>) is diminishing.
3. In the CKEditor 5 equivalent (Style), integration with GHS is incomplete, which means that some elements may not be able to use Style yet.
   Since CKEditor 5's official plugins only support official HTML5 elements, the obvious thing to do is to restrict the allowed HTML elements to configure Style for to just … HTML5 elements. Hence the validation logic mentioned above!

Steps to reproduce

N/A

Proposed resolution

Wait for Style to stabilize further, and in particular for it to gain full GHS support. Then we can consider allowing configuring styles for non-HTML5 tags.

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Release notes snippet

TBD

Problem/Motivation

If a site has a custom, non-HTML5 tag (<foo>) which is listed in the "Source editing" plugin settings, and the site is also using the filter "Limit allowed HTML tags and correct faulty HTML", the custom tag should be allowed and not filtered out. Tags in "Source editing" and "Allowed HTML tags" should be exempt being filtered out, should override the filter for faulty HTML. Without this, the only way to allow such a custom tag is to disable the filter, which disables the security protections the filter was created for.

This issue is spun off as a child issue from this issue: "[upstream] Consider allowing styles for non-HTML5 tags (3280124)".
In the discussion of that parent issue two separate concerns were surfaced.
"Allowing styles for non-HTML5 tags"
and
"CKEditor5 retaining non-HTML5 tags that are entered in the Allowed Tags.
This child issue is to track this separate issue of CKEditor5 retaining non-HTML5 tags.

Steps to reproduce

1. Create a text format using CKEditor 5
2. Check the filter "Limit allowed HTML tags and correct faulty HTML"
3. In "Source editing" enter <foo>
4. Note that <foo> is in the "Allowed HTML tags" list, and save
6. Create/edit content using this text filter
7. Click "Source" and add <foo>Some text</foo>
8. Click "Source"
9. Click "Source" again and note that "<foo>" and "</foo>" are not there, have been filtered out
10. In the text format, uncheck "Limit allowed HTML tags and correct faulty HTML" and try again, the foo tags are not filtered out

Proposed resolution

Rewrite the module code to compare the HTML restrictions result with the content of "Allowed HTML tags", and add any valid tags from "Allowed HTML tags" that are missing (the custom tags added by the developer) to the array to be used for filtering.

Remaining tasks

Once this child issue is resolved, please consider allowing non-HTML5 Styles (in the Styles drop-down).

User interface changes

API changes

Data model changes

Release notes snippet

bug js file:
core/misc/announce.es6.js
core/misc/announce.js

This file has the following bug code：

  Drupal.announce = function(text, priority) {
    // Save the text and priority into a closure variable. Multiple simultaneous
    // announcements will be concatenated and read in sequence.
    announcements.push({
      text,
      priority,
    });
    // Immediately invoke the function that debounce returns. 200 ms is right at
    // the cusp where humans notice a pause, so we will wait
    // at most this much time before the set of queued announcements is read.
    return debounce(announce, 200)();
  };

here "return debounce(announce, 200)();" , It's a misunderstanding of debounce ,
fixed to:

  let announce_debounce = debounce(announce, 200);
  Drupal.announce = function (text, priority) {
    announcements.push({
      text,
      priority,
    });
    return announce_debounce();
  };

Sign-offs needed

Regressions here would be serious. Manual testing with screen readers is important. Get sign-off from an accessibility maintainer.

Problem/Motivation

Routine content management events, such as creating a node, are logged with the "notice" log level, which is for "normal but significant events." On active sites, these events are not really significant per se, so the lower severity "info" log level, for "interesting events," would be a better fit.

Steps to reproduce

Install node module, create a node, find a notice entry in your database log or syslog.

Proposed resolution

Demote from notice to info:

• Delete node revision
• Revert node revision
• Delete node
• Create node
• Update node
• Update book

Keep as a notice:

• Create node type

Remaining tasks

None

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Log level changes

Some routine node and book events which were previously logged as notices are now logged at the lower-severity "info" level. A change record lists which node and book events are now logged at the "info" level.

Problem/Motivation

The caption image filter is not compatible with image resizing (i.e. <img width>). This is because with CKEditor 5, the width is provided in percentages. After wrapping the <img> with a <figure> element, the width attribute is still applied on the <img>. This means that the width is now calculated relative to the <figure> element.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Steps to reproduce:

1. Enable media library, etc
2. Go to node/add/article
3. Paste in a very long string of text that ensures that you there are multiple pages of scrolling
4. Scroll down to near the end. Inject the media image using the regular button / media library
5. After injecting this, note CK5 brings you all the way back to the top of the new article, forcing you to scroll down to find what you were working on.

Problem/Motivation

the toolbar items of ckeditor 5 is overlapping with the sidebar on the node form when it's being used in a multi-value field (or whenever the editor is being embedded in a table element?) and there are many toolbar items.

Steps to reproduce

1. Do a Drupal clean install. (I use https://simplytest.me/)
2. Navigate to a content type and create a field using ckeditor 5 and allow unlimited value.
3. Move the field to the top on the form display of the content type.
4. Add more items to the ckeditor.
5. Go to the create page of the content type and resize the browser down to around 1000px (depends on the number of the toolbar items)
6. See the overlapping issue.

Proposed resolution

Remove the default styling of ckeditor 5 "flex-wrap: nowwrap" seems to fix the issue but where should we add it in Drupal?

Problem/Motivation

The Remove Format button does not remove inline styles. When I have some text that contains inline styles, I select/highlight some text in the editor but the Remove Format button remains gray/inactive, and clicking it does nothing; formatting is not stripped. For example paragraph and span tags with some inline styles, and those inline styles don't get removed. There are no JavaScript errors in the console, either in Chrome or Firefox.

Steps to reproduce

Select some text in the editor and click the Remove Format button.

Proposed resolution

Not sure

Remaining tasks

No idea

User interface changes

None

API changes

On https://ckeditor.com/docs/ckeditor5/latest/features/remove-format.html I see there's a Ckeditor5 API for extending the Remove Format plugin to allow removing specific elements using the isFormatting property, but I think this is not needed here; somehow it seems the default Remove Format functionality isn't working, at least not for me.

Data model changes

No idea

Release notes snippet

N/A

Bug from https://www.drupal.org/node/2303525

As described in the description of the ticket as well as in the description of the page that is linked off to in the ticket that google (https://support.google.com/webmasters/answer/189077) has written up this tag needs to be in the head of the page.

The implementation that currently sits in core only adds these tags to the language switcher and not into the head of the html page.

Updates on reproducing issue as mentioned by #3. 2020/06/17

Once the language and content translation modules are enabled and configured, all entities (term, contents) created will have hreflang tag in head of html whether it is translated or not. Yet the default homepage (/node) doesn't apply.

There is an improvement issue filed for Improve the alternate hreflang implementation
https://www.drupal.org/project/drupal/issues/2994800.

steps to reproduce

1. install Drupal 9.1.dev with default language
(no hreflang tag in head of default homepage)

2. create new entity node of any content type (e.g. articles, /node/1)
(no hreflang tag in head of entity)

3. enable module language and content_translation, activate new language in /admin/config/regional/language and allow content types translation in /admin/config/regional/content-language.

4. Translate node/1 to chosen language.
(hreflang tag appears on both entity head, e.g. /node/1 & /zh-hant/node/1)

5. If default front page is set as "/node", expect no hreflang tag shown in head unless set default frontpage to other entity pages like "/node/1".

Default frontpage & HTML

Entity pages & HTML

Problem/Motivation

At core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php on setPersistentCache function, cache entries are created with tags that are too generic. We can use the entity information to also add tags specific to each entity in order to have a better cache invalidation.

Our particular issue is related to Memcache entries that when not cleared properly are showing multiple current revisions in the revisions table, and using the previous current revision for rendering the node.

Steps to reproduce

(Detailed instructions on how to reproduce the issue, including exact versions used, specific paths to visit, what actions to take, etc.)

Inspecting cache entries I noticed that the data for the cache entry that was not being invalidated properly has only 'node_values'& 'entity_field_info' tags, which is missing useful entity cache tags.

Proposed resolution

Append the entity that is being stored as data in the cache entry.

Remaining tasks

(reviews needed, tests to be written or run, documentation to be written, etc.)

• make patch (or branch) for change in most recent dev version (9.2.x)
• update steps to reproduce, starting from install drupal core
• get review for
  • if this change can/should be made,
  • and if so, is this an ok place for the change, or is there another place that it should be made,
  • does this need tests or changes to tests.

User interface changes

None expected.

API changes

None intended.

Data model changes

None intended.

Release notes snippet

(Major and critical issues should have a snippet that can be pulled into the release notes when a release is created that includes the fix)

TBD. Might change as this gets reviewed, right now this issue is "Normal", not Major or Critical.

Problem/Motivation

When you visit /admin/modules/uninstall and search for a module machine_name, you will not find a result. The problem gets really visible, when you use modules where the module's machine_name differs from the human-readable name.

Examples in Core and Contrib:

• Database Logging (dblog)
• Chaos tools (ctools)

Especially in contrib we see more such examples, where also the module project page presents another name, as the human-readable name (see Chaos tool suite, Configuration Update Manager).

Those inconsistencies let developers (when not using drush) to filter the module list by the module's machine_name. That is working fine at the module list, because the machine_name is part of the description, but not on the uninstall page).

Steps to reproduce the problem

Different behavior between the module list and uninstall module page.

Module list

1. Go to /admin/modules
2. Filter for dblog
3. You'll see the "Database Logging" module

Uninstall module

1. Go to /admin/modules/uninstall
2. Filter for "dblog"
3. You'll see no results

Proposed resolution

Make the filter by module machine_name working in the table at /admin/modules/uninstall.

Remaining tasks

• Decide, if it is a bug/feature request and/or should be fixed
• DONE. Going to add a machine name column. Decide, if we should
  • YES. Show the module machine_name in the description column in it's own column.
  • NO. or include it visibility-hidden (if it would be allowed UX-wise) to only make it searchable. Presenting content to screen reader users but not to sighted users isn't inclusive design, rejected on accessibility grounds.
• Update the system-modules-uninstall.html.twig template.
  • DONE. Add module machine name to template variables via preprocess hook.
  • Document the machine name variable in template docblock.
  • DONE. Add machine name column to the table.
  • DONE. Make the machine name column responsive, add priority-medium class.
  • Add the show-all-columns feature. {{ attach_library('core/drupal.tableresponsive') }} in template.
  • Decide: should we make the description column responsive? priority-low would match the install page.
  • DONE. Duplicate the template in Seven and Bartik, as we can't update the template in the Stable theme.

User interface changes

Introduces a new machine name table column on the modules uninstall page. The machine name becomes searchable in the filter.
Make the uninstall table responsive, because the install page is already responsive.
Before

After

API changes

None

Data model changes

None

On the status page, I'm seeing:

Errors found:
PHP APCu caching:
Enabled (96 MB)
Memory available: 8.96 MB.

Does this mean that there's only 8.96 MB left of the 96 MB that's enabled (which is too little), or that it's not possible to enable the full 96 MB because only 8.96 MB can be allocated?

If it's the former, there should be a message saying something like this:

Your APCu cache is too small; it needs to be made larger.

Otherwise:

You don't have enough RAM/storage/whatever to enable the full APCu cache you're enabled in your Web server settings.

So:

1. It's not clear what the error means, and
2. It's not clear how to fix it.

There's no helpful messaging here whatsoever.

Hello all, it’s time for the weekly migration subsystem meeting. The meeting will take place in slack in various threads
This meeting:
➤ Is for core migrate maintainers and developers and anybody else in the community with an interest in migrations
➤ Usually happens every Thursday and alternates between 1400 and 2100 UTC.
➤ Is done on the #migration channel in Drupal Slack (see www.drupal.org/slack for information).
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to. See the parent issue for an idea of the typical agenda.
➤*Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

Core migration issues

• RTBC
• NR
• all open
• Needs subsystem maintainer review
• Statistics, Google spreadsheet

Next video meeting 2023-04-13 2100Z (tentative)

Problem/Motivation

nginx is even more popular than Apache: https://w3techs.com/technologies/overview/web_server

We ship with .htaccess for Apache and web.config for IIS. We do not provide any sample configuration for nginx.

There is a recipe in the nginx wiki at https://www.nginx.com/resources/wiki/start/topics/recipes/drupal/ but it likely does not match our current set of regular expressions, header rules, etc, that we ship in .htaccess and web.config.

It is likely that we cannot provide a drop-in configuration file as the exact location of the php-fpm upstream depends on how php-fpm is installed, but we could provide a commented sample file that matches our current best practices for security.

Steps to reproduce

Proposed resolution

Add a sample configuration file for nginx that is equivalent to the rules in .htaccess/web.config.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Custom access checks can be added for operations in the layout builder either via custom code or via contrib modules like https://www.drupal.org/project/layout_builder_perms. In this way it is also possible to disallow moving blocks. In an advance use case it can be desirable to disallow blocks of a certain type into sections with a certain layout. This works fine but the layout builder UI does not respect the access on routes involved. This can lead to a situation in which the layout builder UI shows a move operation as successful (i.e. the block is move to another region in another section) but the ajax call to actually register the change resulted in a 403. The user will not notice this until reloading the page or saving the layout. Only then they will discover that the block was not moved.

Steps to reproduce

* Install Drupal, enable layout builder and create a layout builder enabled content type.
* Install Layout Builder Advanced Permissions (https://www.drupal.org/project/layout_builder_perms) and enable the Layout Builder Advanced Permissions Layout sub module.
* Create a custom role and configure permissions to allow the role to place blocks in sections with a layout of a certain type but not in sections with a layout of another type.
* Create a node of a layout builder enabled content type.
* Add a section (A) in the layout builder and configure it with a layout in which the custom role is allowed to place blocks.
* Add a section (B) in the layout builder and configure it with a layout in which the custom role is not allowed to place blocks.
* Add a block in section A.
* Save the layout.
* Go back to the layout builder and move the block from section A and section B. The layout builder will visually allow this and move the block to section B.
* Save the layout.
* See that the block is still in section A.

Proposed resolution

In core/modules/layout_builder/js/layout-builder.es6.js there is a behavior layoutBuilderBlockDrag. The Sortable that is created in this behavior can be extended with an onMove() callback. This callback is executed every time a block is dragged over a region. Returning false from this callback will disallow drop in that region. It will also prevent the region from being highlighted.

For this to work we will also need to add a URL that can be called via ajax and that only executes the access check for the layout_builder.move_block route and return the result (without actually executing the logic in the controller linked to the route).

Remaining tasks

- Create patch
- Review patch
- Commit patch

User interface changes

Block operations in layout builder that are not allowed will not be possible anymore in the layout builder UI.

API changes

N/A

Data model changes

N/A

Release notes snippet

TBD