Problem/Motivation

It seems like #3269064: Update to CKEditor 5 v33.0.0 introduced a pretty serious bug when list plugin is enabled. It seems like data-caption attribute is removed on upcast from <img> elements. Also, downcasting <drupal-media> and <img> with a data-caption results into a uncaught exception:

ckeditor5-dll.js?v=33.0.0:5 Uncaught CKEditorError: mapping-view-position-parent-not-found {"modelPosition":{"root":"main","path":[0,0,0],"stickiness":"toNext"}}
Read more: https://ckeditor.com/docs/ckeditor5/latest/framework/guides/support/error-codes.html#error-mapping-view-position-parent-not-found
    at h.on.priority (ckeditor5-dll.js?v=33.0.0:5:133899)
    at h.fire (ckeditor5-dll.js?v=33.0.0:5:452678)
    at h.toViewPosition (ckeditor5-dll.js?v=33.0.0:5:136388)
    at d.C (list.js?v=33.0.0:5:16664)
    at d.fire (ckeditor5-dll.js?v=33.0.0:5:452678)
    at d._testAndFire (ckeditor5-dll.js?v=33.0.0:5:118620)
    at d._convertInsert (ckeditor5-dll.js?v=33.0.0:5:116742)
    at Object.convertChildren (ckeditor5-dll.js?v=33.0.0:5:119055)
    at d.<anonymous> (ckeditor5-dll.js?v=33.0.0:5:128741)
    at d.fire (ckeditor5-dll.js?v=33.0.0:5:452678)

Steps to reproduce

1. Enable CKEditor 5 on a text format with image upload, image captions and list and source editing buttons
2. Create new content using the new text format
3. Upload image and add caption
4. Press source editing and check console for exception

Proposed resolution

We should consider reverting #3269064: Update to CKEditor 5 v33.0.0. In the meanwhile, we should research what it causing this and whether the fix should be in our code or upstream.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Currently, using a PHP version between \Drupal::MINIMUM_PHP and \Drupal::MINIMUM_SUPPORTED_PHP leads to:

• A requirements error on installation
• A requirements error on the site status report
• A requirements warning on update

In #2917655: [PP-1] Deprecate or drop PHP 7.3 support in Drupal 9.4, it's been raised that the distinction between installation and update is somewhat artificial, because it's quite common to have a deployment workflow that involves installing from default config, even for site updates.

Proposed resolution

Change the behavior of \Drupal::MINIMUM_SUPPORTED_PHP to raise a warning on installation, rather than an error.

Remaining tasks

#3261602: Display installation warnings in the quick-start command is a followup to make this work properly with the quick-start command.

User interface changes

Instead of an error, sites installing on versions between MINIMUM_PHP and MINIMUM_SUPPORTED_PHP will see the following warning:

They can then advance to the next screen of the installer by scrolling to the end of the page and click a small "continue anyway" link.

API changes

As per title.

Data model changes

N/A

Release notes snippet

The installer will now display a warning rather than an error if the PHP version is between \Drupal::MINIMUM_PHP and \Drupal::MINIMUM_SUPPORTED_PHP. No existing sites will be affected by this change since \Drupal::MINIMUM_PHP and \Drupal::MINIMUM_SUPPORTED_PHP have had the same value since Drupal 8.8.0; however, some development or testing workflows from Drupal 8.6 or 8.7 might be affected. (More information.)

Problem/Motivation

#2313917: Core version key in module's .info.yml doesn't respect core semantic versioning introduced logic to throw an exception when modules try to indicate pre-8.7.7 specific version compatibility - this is to mitigate against modules creating havoc on a pre-8.7.7 site that upgrades a contrib module without upgrading core.

Once we hit Drupal 9.2.0, Drupal 8 will be end of life (and the vast majority of modules will have correctly updated for Drupal 9 compatibility), so we could remove that code. This is not an API change as such, it's just removing some internal logic.

Drupal\Core\Extension\InfoParserDynamic

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Media in CKEditor4 has an edit media which let's user choose the view mode. This is not yet available in CKEditor 5.

This will allow us to port:

1. \Drupal\Tests\ckeditor5\FunctionalJavascript\MediaTest::testViewMode()
2. \Drupal\Tests\ckeditor5\FunctionalJavascript\MediaTest::testDialogAccess()

Note that ideally, we would not use a Drupal dialog for this, and instead implement it on the client side, much like #3246385: [drupalMedia] Support captions on <drupal-media> for captioning and alignment.

Proposed resolution

TBD

Remaining tasks

User interface changes

API changes

Data model changes

composer require fails with Composer 2

Steps to reproduce

comp require --update-no-dev --update-with-dependencies --no-plugins drupal/entity drupal/smtp drupal/spambot drupal/webform:^6.0 wikimedia/composer-merge-plugin

> Drupal\Core\Composer\Composer::vendorTestCodeCleanup

Fatal error: Uncaught Error: Call to undefined method Composer\DependencyResolver\Operation\UpdateOperation::getJobType() in /home/stelnews/public_html/core/lib/Drupal/Core/Composer/Composer.php:170
Stack trace:
#0 phar:///home/stelnews/public_html/composer/src/Composer/EventDispatcher/EventDispatcher.php(319): Drupal\Core\Composer\Composer::vendorTestCodeCleanup(Object(Composer\Installer\PackageEvent))
#1 phar:///home/stelnews/public_html/composer/src/Composer/EventDispatcher/EventDispatcher.php(216): Composer\EventDispatcher\EventDispatcher->executeEventPhpScript('Drupal\\Core\\Com...', 'vendorTestCodeC...', Object(Composer\Installer\PackageEvent))
#2 phar:///home/stelnews/public_html/composer/src/Composer/EventDispatcher/EventDispatcher.php(123): Composer\EventDispatcher\EventDispatcher->doDispatch(Object(Composer\Installer\PackageEvent))
#3 phar:///home/stelnews/public_html/composer/src/Composer/Installer/InstallationManager.php(386): Composer\EventDispatcher\EventDispatcher->dispatchPackageEvent('post-package-up...', in /home/stelnews/public_html/core/lib/Drupal/Core/Composer/Composer.php on line 170

Proposed resolution

Downgrade to composer 1. But that fails with same error!

Remaining tasks

Fix composer2

User interface changes

API changes

Data model changes

Release notes snippet

An incompatibility with Composer 2, which affects a minority of sites when trying to update certain packages, has been fixed in Drupal 9.2.N, 9.3.N, and later. This incompatibility may cause fatal errors similar to:

> Drupal\Core\Composer\Composer::vendorTestCodeCleanup

Fatal error: Uncaught Error: Call to undefined method Composer\DependencyResolver\Operation\UpdateOperation::getJobType()

This problem can be fixed permanently by running these commands on any version of Drupal 9:

composer config --unset scripts.post-package-install
composer config --unset scripts.post-package-update
composer require drupal/core-vendor-hardening:^9

Other workarounds require updating Drupal to 9.2.N, 9.3.N, or later, and are documented at https://www.drupal.org/node/3267857.

The Media Library form for uploading a new referemced media item are currently filtered for only published media. This means that contrib modules which manipulate the upload (such as in the Scheduler module) by setting status to false for later publishing at a specified date cannot use this upload method. The scheduled media are not shown after upload, so the insert fails.

The views can expose the 'publish status' filter to allow unpublished media to be displayed, like it is for the main media overview page at admin/content/media.

Problem/Motivation

QA testing of Olivero across browser - Samsung Internet. Please test the latest major version.

This particular issue is more of a visual style against a lot of supported browsers that we might not use on a day-to-day basis

Breaking up the parent issue: QA testing of Olivero across multiple browsers #3173877: [meta] QA testing of Olivero across multiple browsers. This was discussed in Slack on April 26.

Testing script: https://docs.google.com/document/d/10UVObMlSMQHpFPwOvrFWDtXP2kzl1ZEx6PlU...

Steps to complete

1. Read testing script above
2. See example video and issue at #3210745: QA testing of Olivero - Desktop browser: Google Chrome
3. Test browser and record video
4. Post video

Problem/Motivation

Use case: As a user I want to be able to have editors work in an interface language of their choice on a content-monolingual site.

This issue is collects a series of issues that are related to how language fallbacks are configured out of the box. Potentially this will lead to updating existing issues or splitting out separate issues but I'm starting with a single issue as I think that maybe there is a single consistent solution available.

Problem 1: Broken URL aliases

1. Install Thunder 6.3.3 or the Standard profile on 9.3.x in English
2. Login as user 1
3. Ensure the locale module is installed
4. Visit admin/config/regional/language and add the German language
5. Set German to be the default language and press save configuration
6. Visit admin/config/regional/language/detection and:
   • check the User detection checkbox
   • uncheck the Url detection checkbox
   • click save settings
7. Your user interface language should still be english because user 1 was created during installation.
8. Visit node/add/article and create an article with a URL alias.
9. When you press save the URL alias will not work.
10. If you change user 1's language to German and visit the alias it will work.

Analysis of why the URL alias is broken when the user's language is English

When resolving aliases the inbound url is processed by the path_alias.path_processor service. It hands off to \Drupal\path_alias\AliasManager::getPathByAlias(). This resolves the langcode by getting the "The type of language used for URLs". This ends up calling the \Drupal\language\Plugin\LanguageNegotiation\LanguageNegotiationUrlFallback as we're not using path based language detection at all. Rather surprisingly this class will load up the language.negotiation configuration and use it to determine the language. Because we've changed the default language after installing the configuration looks like this:

  prefixes:
    de: 'de'
    en: 'en'

There is no default empty prefix configuration. When we added the German language the system automatically added de: 'de' and when we set German to be the default language the system changed en: '' to en: 'en' and thereby broke this. Given the URL language checkbox is not checked on the detection and selection page it feels very counterintuitive that this the page the configure button leads to should be so important.

Potential fixes

1. Do nothing - this is fixable via the UI. The problem with this is that it feels wrong and the whole situation is very hard to grok. Yes there is a warning on the page where you can change the default language. It says: "The site default language can also be set. It is not recommended to change the default language on a working site."
2. Add a message with a warning on the detection and selection screen if there is no langcode mapped to an empty prefix. In the message link to the screen where this can be fixed.
3. If the language URL method is unchecked reveal a hidden section that allows you to configure the URL language type fallback.
4. Fallback to content type language negotiation as per #3067007: LanguageNegotiationUrlFallback should use content language for TYPE_URL fallback - this will not fix the issue until we address the next part of the problems

Problem 2: Language content type falling back to UI negotiation

Steps to reproduce:

1. Do steps problem 1 but on Thunder 6.3.3 - we need the Metatag module installed and configured to reproduce this
2. Fix the URL alias problem by visiting admin/config/regional/language/detection/url and removing the prefix for the German language.
3. Confirm that the URL alias works regardless of the user's selected language
4. When user 1's language is set to English again visit the node and view the page source.
5. The canonical URL in the header, eg:
   will not be aliased.
6. Change user 1's language to German and visit node and view the source again
7. The canonical URL in the header, eg:
   will be aliased.

Analysis of why the canonical is not aliased when the user's language is English

In Thunder the Metatag module is used to control these link tags. When using standard the canonical URLs are correct. The problem is caused by how Drupal\metatag\MetatagManager::generateRawElements() determines $langcode. It does:

    // Get the current language code.
    $langcode = \Drupal::languageManager()
      ->getCurrentLanguage(LanguageInterface::TYPE_CONTENT)
      ->getId();

At this point the Content Translation module is not installed or configured. What happens in this case is that core will use the \Drupal\language\Plugin\LanguageNegotiation\LanguageNegotiationUI() as a fallback to determine the content language. Given we've set up the user interface translation to use the user's preference this will result in a determination of English even though the site's default language (and therefore all content and URL aliases) is German.

Potential fixes

• Install the Content Translation module. This will allow you to configure content translation detection and selection to not fallback to the UI. However, this "fix" feels really odd because as the use-case says the site is content-monolingual. They don't want to create content in any language other than German at this point and therefore the site should not need the content_translation module.
• Change how content type language negotiation works. It should not be possible for content type language negotiation to fallback to a language that an entity cannot possibly have. It also feels really odd that it falls back in a different way to URL type language detection. We could change the negotiation so that, if UI negotiation results in a possible language use that, if not fallback to the default language.
• Or is the problem in the Metatag module? Is #3077442: Metatags' current language through the language manager doesn't work (Decoupled Drupal) the correct fix OR should the code only use content type language negotiation if the content_translation module is installed other it should use the default language.

Remaining tasks

Decide what to fix.

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Release notes snippet

TBD

Problem/Motivation

I have a view with pager exposed and allowing to show All items. When selecting 'All' on PHP 8 it crashes with the following error:

The website encountered an unexpected error. Please try again later.
TypeError: Unsupported operand types: int * string in Drupal\views\Plugin\views\pager\SqlBase->query() (line 279 of core/modules/views/src/Plugin/views/pager/SqlBase.php).

Looks like that this code behaves different on php 8 than on php 7:

$items_per_page = $query->get('items_per_page');
if ($items_per_page > 0) {
  $this->options['items_per_page'] = $items_per_page;
}
elseif ($items_per_page == 'All'&& $this->options['expose']['items_per_page_options_all']) {
  $this->options['items_per_page'] = 0;
}

When $items_per_page is set to 'All' the condition if ($items_per_page > 0) is true for php 8 and false on php 7. Ref https://wiki.php.net/rfc/string_to_number_comparison

So the offset calculation on line 279 crashes.

Steps to reproduce

Expose pager on a view, allow to select All items, try to show All items.

Proposed resolution

Fix this for php 8.
Maybe flipping if condition is enough.

The session language detection method is responsible of several open bugs in the language system queue:

#815526: Session language switcher prevents pages from being cached
#815544: Duplicate page cache entries when using the session language switch links
#768240: Session language switcher links do not report the active status correctly

Moreover it has been defined a really bad idea from one major D7 contributor.

As the current language system maintainer and being the one who actually coded it, I think it can safely be moved in contrib as the main reason it was introduced was allowing to set interface language and content language separately. This functionality has already been moved in contrib so there should be no harm in moving the session language detection method in contrib too. This would give us also the time to refine it and make it more solid.

A positive side effect would be that we would have only the original language detection methods available in the language detection and selection page, thus reducing the gap from the D6 UI.

Updated: Comment #16

Problem/Motivation

The original poster, Dave Cohen, reported this problem running D6:

I get Page not Found errors with pathauto when locale is enabled. The aliases get associated with "English" and never work. If I manually edit an alias, changing it to "All languages", then it works. Not sure whether this is bug or my configuration, would appreciate help either way.

The problem was simplified (the Pathauto module is not required) and reproduced in D7 and D8. The configuration quirks in the original poster's site do not seem to be relevant.

Steps to reproduce (from #11 and #13)

Using Drupal core 7.21 and Pathauto 7.x-dev: Elaborating on the steps to reproduce in D7 and D8 (based on the thread above):

1. Configure Drupal:
   • D7: enable the core Locale and Content Translation modules.
   • D8: enable the core Language and Content Translation modules
2. D7/D8: visit admin/config/regional/language, press "Add language" and select "Spanish" from the drop-down
3. D7/D8: press the "Detection and Selection" tab aka as admin/config/regional/language/configure
4. D7/D8 In the column of tick boxes make sure that Detection Method URL is unticked while Detection Method Session is ticked; leave the remaining tickboxes set to what they are
5. Configure Content Types:
   • D7: on the content type settings page for Article admin/structure/types/manage/article tick the Publishing options tab and then the Enabled radio button under "Multilingual support."
   • D8: visit /admin/config/regional/content-language and tick the Content box (Custom Language Settings) as well as the Article box in the Translatable column.
6. D7/D8: add content: node/add/article, specify an alias under "URL path settings" and in the Language drop-down select "English". Save
7. D7/D8: Verify that you can View the page via the URL alias
8. D7/D8: Edit the page, changing the language selector to Spanish. Save.
9. You can now no longer View the page via its URL alias, although node/... still works.

Is this the problem or a feature?? It's a problem, at the very least it s counterintitutive and not clearly documented…

Proposed resolution

In #8 SiliconMind proposed an explanation of the problem:

I think that this happens because drupal_lookup_path from path.inc uses global $language_url variable to get current language. But the problem is that $language_url is set to default language if language was not set via url. This is wrong because language could be selected through user preferences or browser language.

The real problem is that url alias should work always regardless of selected language!

Workaround for this is to alter drupal_lookup_path queries to search url_alias table for entries that match provided alias but not necessarily match language that is provided by $language_url variable. The goal is to always return alias source if it exists regardless of selected language.

Remaining tasks

1. Finish charactarizing the problem and determine if we have one issue or several.
2. Decide what the desired behavior is.
3. Create a patch.
4. Design tests.
5. Update documentation
6. Backport to D7.

User interface changes

(New or changed features/functionality in the user interface, modules added or removed, changes to URL paths, changes to user interface text.)

There will clearly be some…

Once this is sorted out it would be very good to document the behavior and make it easily accessible from the language configuration pages.

Another nice change would be to include the language of a page in the content listing on multi-lingual sites (although this should probably be a separate issue).

API changes

At the moment there do not appear to be any.

Original report by Dave Cohen

Rather than "hijack"#320710: Pathauto URL Alias leading to Page Not Found, submitting new issue. I find I get Page not Found errors with pathauto when locale is enabled. The aliases get associated with "English" and never work. If I manually edit an alias, changing it to "All languages", then it works. Not sure whether this is bug or my configuration, would appreciate help either way. More about the problem: Drupal is unilaterally modifying paths specified by the content author, without notifying the content author.

Proposed resolution

1. Do not modify user-supplied paths.
2. If it's absolutely necessary to modify user-supplied paths, at least inform the user.
3. Avoid 404'ing user-supplied paths -- make them redirect to the changed path, maybe?

Beta phase evaluation

Problem/Motivation

CKEditor 5 currently supports inline <code>…< /code> thanks to:

ckeditor5_code:
  ckeditor5:
    plugins: [basicStyles.Code]
  drupal:
    label: Code
    library: core/ckeditor5.basic
    admin_library: ckeditor5/admin.basic
    toolbar_items:
      code:
        label: Code
    elements:
      - <code>

But we do not yet have support for code blocks: <pre><code>…< /code></pre>. That's where https://ckeditor.com/docs/ckeditor5/latest/features/code-blocks.html comes in.

We did support this in CKEditor 4 too, thanks to the Format dropdown:

The full list of tags supported by that:

• <p>
• <h1>
• <h2>
• <h3>
• <h4>
• <h5>
• <h6>
• <pre>

All of those are already supported (thanks to ckeditor5_paragraph and ckeditor5_heading), with the exception of the last one: <pre>.

For that, we need this additional plugin. Right now, you're forced to use "view source" to create such content, which is a regression compared to CKEditor 4.

Steps to reproduce

N/A

Proposed resolution

Add https://ckeditor.com/docs/ckeditor5/latest/features/code-blocks.html to provide an equivalent UX in CKEditor 5.

Remaining tasks

1. Add package to core/package.json and build the JS.
2. Add definition to core/modules/ckeditor5.ckeditor5.yml.
3. Expand update path test coverage in \Drupal\Tests\ckeditor5\Kernel\SmartDefaultSettingsTest
4. Expand update path for Format button in \Drupal\ckeditor5\Plugin\CKEditor4To5Upgrade\Core::mapCKEditor4ToolbarButtonToCKEditor5ToolbarItem(). Note that this is tricky because Format now needs to be mapped to multiple toolbar buttons if<pre> is allowed in the text format. This is not yet supported by CKEditor4To5UpgradePluginInterface and will likely require an API addition.

User interface changes

Better UX for

API changes

TBD

Data model changes

None.

Release notes snippet

TBD

Blocked behind #3053887: Add test coverage and document why inline blocks require a new revision to be created when modified, regardless of whether a new revision of the parent has been created

Problem/Motivation

When reverting a parent entity revision, the parent/child relationship looks like:

 +------------+   +------------+   +------------+
 |Host Entity |   |Host Entity |   |Revert VID 1|
 |VID: 1      |   |VID: 2      |   |VID: 3      |
 |Timestamp: 1|   |Timestamp: 2|   |Timestamp: 3|
 +------------+   +------------+   +------------+
       |                |                |
       v                v                |
 +------------+   +------------+         |
 |Block Entity|   |Block Entity|         |
 |VID: 1      |   |VID: 2      |         |
 |Timestamp: 1|   |Timestamp: 2|         |
 +------------+   +------------+         |
       ^                                 |
       +---------------------------------+

 Custom block entity form
 +-----------------------------+
 |$saved_entity change time: 2 |
 |$new_entity change time: 1   |
 |Validator throws error       |
 +-----------------------------+

When block entity VID 1 is loaded into the custom block form, the validator compares it against VID 2 as the "saved entity". The validator sees that a new revision has been created since VID 1 and throws an error.

Node handles this by updating the changed timestamp in \Drupal\node\Form\NodeRevisionRevertForm::submitForm when a node is reverted, but there isn't currently a process to create new entity revisions of custom blocks when a host entity is reverted.

Steps to reproduce

1. Create a node and add a basic block to it via LB
2. Create a new revision, and edit the block
3. Revert to the first revision via the Revisions screen
4. Try to edit the block again, on save you will trigger the constraint and get the error message "The content has either been modified by another user, or you have already submitted modifications. As a result, your changes cannot be saved."

Proposed resolution

Preferred solution: Create a modified version of EntityChangedConstraint for BlockContent entities that skips the constraint validation for non-reusable (also known as "inline") block entities. This validation constraint is not necessary for inline block entities because Layout Builder is already creating new revisions of blocks when the layout is saved (see \Drupal\layout_builder\InlineBlockEntityOperations::handlePreSave). There's no danger of losing content.

Alternate solution: Prematurely update the 'changed' timestamp of the block content entity in the validate function of the inline block form so it tricks the existing entity validator to passing. This seems harmless (as the 'changed' timestamp will be updated anyway when the layout is saved), but it seems better to skip validation entirely as described above.

Remaining tasks

Sam's #6 comment may need to be addressed?

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

TBD

Problem/Motivation

While working on #3260615-11: Remove deprecated schema.inc the reference was found, the function deprecated in https://www.drupal.org/node/2467521

Proposed resolution

clean-up mention

Remaining tasks

review/commit

User interface changes

no

API changes

no

Data model changes

no

Release notes snippet

no

Hi all.
I enabled the “Require email verification when a visitor creates an account” flag to validate email address as part of registration process.
I also enabled “RESTful Web Services” module enabled to trigger registration flow in my headless Drupal ContentaCMS installation through the /user/register endpoint.

Issue description
I found the following issue:
- when a user is created via /user/register?_format=json REST endpoint, the status after creation is “Blocked”
- the onetime password is generated and the email with the one time link is correctly sent to the user
- BUT, after clicking on the link sent via email, the user is getting 403 Access Denied pageI went through the code and I found this ‘if’ in the getResetPassForm(Request $request, $uid) in User.Controller.php

    if ($user === NULL || !$user->isActive()) {
      // Blocked or invalid user ID, so deny access. The parameters will be in
      // the watchdog's URL for the administrator to check.
      throw new AccessDeniedHttpException();
    }

It looks like Blocked user cannot execute password reset (which makes perfectly sense to me).

I checked the same scenario by creating a user through standard Drupal login page (no REST).
After the creation, the user status is set to Active and the email verification process can be completed without issues.

Conclusion
- only user created via /user/register?_format=json cannot finalize the email verification, since their account is blocked.

Workaround
To overcome this issue I enabled Rules module to trigger the following rule
- event: After Saving a new User
- action: unBlock User
This rule is executed every time a new user is created and moves the status from Blocked -> Active

Problem/Motivation

There's functions deprecated for removal in core 10

Proposed resolution

remove the usage, make sure no mentions left

Remaining tasks

review/commit

User interface changes

no

API changes

no

Data model changes

no

Release notes snippet

Problem/Motivation

Both FieldItemListInterface and FieldItemInterface have a magic method __get().
Typically this returns NULL if the field is empty, and non-null if the field is not empty.
However, this is not properly documented.
https://git.drupalcode.org/project/drupal/-/blob/9.4.x/core/lib/Drupal/C...
https://git.drupalcode.org/project/drupal/-/blob/9.4.x/core/lib/Drupal/C...

In our team, we are discussing if we need to always call ->isEmpty() before accessing field values.

Technically it seems that magic __get() (e.g. $entity->get($field_name)->value) makes the ->isEmpty() call obsolete, because it will return NULL for empty fields. But can we count on this?
Or, another option, we could call ->first(), and if that is NULL we consider the field to be empty. But is this equivalent with calling !->isEmpty()?

E.g.
Are there cases where ->isEmpty() returns false, but ->first() or ->__get('value') return NULL?
(I think yes, if 'value' is not a required value key for this field type)
Are there cases where ->isEmpty() returns true, but ->first() or ->__get('value') return something other than NULL?

Steps to reproduce

--

Proposed resolution

Decide and document when the magic __get() returns NULL.
Verify if this is the case for all field items.

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. #3268306: [upstream] Full HTML <drupal-media> elements are removed if embed media is disabled
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. #3222756: Allow using images from external source
   2. #3228691: [PP-1] Restrict allowed additional attributes to prevent self XSS
   3. #3260869: Resolve mismatch between <$block> interpretation by CKEditor 5 and Drupal
   4. #3261599: Use CKEditor 5's native <ol start> support (and also support <ol reversed>)
4. Ensure CKE5 functionality matches that of Drupal core's CKE4:
   1. #3222797: [upstream] Upgrade path from CKEditor 4's StylesCombo
   2. #3230230: [upstream] Enable table captions; override CKE5's default downcast to generate <table><caption></table> instead of <figure><table><figcaption></figure>
   3. #3245720: [drupalMedia] Support choosing a view mode for <drupal-media>
   4. #3247634: [upstream] Unlinking linked inline images while GHS is enabled: wrapping <a> is impossible to remove
   5. #3263384: [PP-1] Add ckeditor5-code-block package and CodeBlock plugin
   6. #3268318: [upstream] [drupalMedia|drupalImage] <a> with GHS allowed attributes downcast wraps data-caption with <a>
   7. #3268311: [upstream] [drupalMedia] GHS-enabled markup in data-caption crashes CKEditor 5
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. #3222757: [drupalImage] Make image alt text required or strongly encouraged
   2. #3239423: Toolbar UI accessibility review: round 2
8. Test coverage, reliability and maintainability matching or exceeding CKEditor 4's:
   1. #3228580: Follow-up for #3222852: additional test coverage for real-time validation race conditions
   2. #3229078: Unit tests for all @CKEditor5Plugin plugin classes
   3. #3231328: SmartDefaultSettings should select the CKE5 plugin that minimizes creation of HTML restriction supersets
   4. #3231334: Add validation for attributes allowed or forbidden on all elements
   5. #3231336: Add validation for HTML restrictor filters that only set forbidden_tags
   6. #3231337: [drupalMedia] Remove manual dataDowncast from DrupalMediaEditing
   7. #3247683: [PP-1] Disable CKEditor 5's automatic link decorators (in Drupal filters should be used instead) + explicitly test manual link decorators
   8. #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. #3225033: Make image upload plugin depend on editor_file_reference filter + ensure good UX for this
    2. #3227948: Hide incompatible filters
    3. #3245967: Messages upon switching to CKEditor 5 are overwhelming
    4. #3261943: Confusing behavior after pressing "Apply changes to allowed tags" with invalid value
    5. #3261585: Remove IE11 warning for CKEditor 5 in Drupal 10, since Drupal 10 does not support IE anyway
    6. #3260857: Expand SourceEditingRedundantTagsConstraintValidator to also check attributes and attribute values
    7. #3259443: Plugin settings do not appear when a configurable plugin is added AFTER removing all buttons
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: Remove 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

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
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
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
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
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
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
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
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

Problem/Motivation

QA testing of Olivero across browser - Mobile Safari. Please test the latest major version.

This particular issue is more of a visual style against a lot of supported browsers that we might not use on a day-to-day basis

Breaking up the parent issue: QA testing of Olivero across multiple browsers #3173877: [meta] QA testing of Olivero across multiple browsers. This was discussed in Slack on April 26.

Testing script: https://docs.google.com/document/d/10UVObMlSMQHpFPwOvrFWDtXP2kzl1ZEx6PlU...

Steps to complete

1. Read testing script above
2. See example video and issue at #3210745: QA testing of Olivero - Desktop browser: Google Chrome
3. Test browser and record video
4. Post video

Problem/Motivation

In system_theme_suggestions_maintenance_page(), a template suggestion is provided for maintenance-page--offline.html.twig:

if ($offline) {
  $suggestions[] = 'maintenance_page__offline';
}

However, this template is not picked up when the system is offline. This results in a generic, unstyled exception page (i.e. a WSOD), creating a poor user experience. This is functionality that did exist and work in Drupal 7, and an attempt was made to have this functionality ported to Drupal 8, but appears to not have been completed/successful.

This is a major issue because it has no workaround and is a regression from Drupal 7.

Cause a significant admin- or developer-facing bug with no workaround.

Steps to reproduce

Scenario A (when core/includes/errors.inc is used):

1. Set correct database credentials in settings.php
2. Clear cache: drush cr
3. Set $config['system.logging']['error_level'] = 'hide' in settings.php
4. Set $settings['maintenance_theme'] = 'bartik' in settings.php
5. Set incorrect database credentials in settings.php (for example invalid username)
6. Refresh the page.
7. There is a plain text message: "The website encountered an unexpected error. Please try again later."

Scenario B (when \Drupal\Core\EventSubscriber\FinalExceptionSubscriber is used):

1. Make sure that $settings['hash_salt'] in set in settings.php
2. Clear cache: drush cr
3. Set $config['system.logging']['error_level'] = 'hide' in settings.php
4. Set $settings['maintenance_theme'] = 'bartik' in settings.php
5. Comment out $settings['hash_salt'] in settings file
6. Refresh the page.
7. There is a plain text message: "The website encountered an unexpected error. Please try again later."

Proposed resolution

Adds a way to render a template when in a fatal error context first by trying to get the maintenance theme in settings and then by the slower extension discovery if the that fails. Finally it falls back to a WSOD like fatal message.

Scenario A is addressed by calling the new static method in errors.inc.
Scenario B is addressed by calling the new static method in FinalExceptionSubscriber.

These scenarios are addressed in a new browser test.

Remaining tasks

• Manually test the merge request
• Review the merge request

User interface changes

Fatal errors will be attempted to be rendered using the maintenance theme "offline" template. This would cause previously displaying a WSOD to potentially show a themed page instead.

API changes

• New public method Drupal\Core\Utility\Error::renderFatalError

Data model changes

N/A

Release notes snippet

This is a patch (bugfix) for a regression due to incomplete porting of functionality from Drupal 7 to Drupal 8 (and now Drupal 9). Drupal 7 allowed for the implementation of maintenance-page--offline.tpl.php, a template that to be shown when the site was offline and unable to connect to the database. The porting of this functionality to Drupal 8 and 9 was incomplete, and the equivalent Twig template, maintenance-page--ofline.html.twig, was not picked up, resulting in a generic, unstyled exception page (i.e. a WSOD) with a poor user experience. This but has now been fixed, and site themers can implement maintenance-page--ofline.html.twig on Drupal 8 and 9 sites.

Who this affects

This bugfix affects Drupal theme developers. Theme developers will now be able to create a template page to be displayed when Drupal is unable to reach the database, providing an improved user experience.

How to Implement

1. Copy core/modules/system/templates/maintenance-page.html.twig to the theme to be used when your site is offline.
2. (Optional) Edit the template to provide the HTML you would like visitors to see when the site is offline
3. Edit settings.php, uncomment the line $settings['maintenance_theme'] = 'bartik';, and change the value from bartik to the machine name of the theme you chose in step one above.
4. Clear your registry

How to test the template

After performing the steps above, the way to test that the template is working is to force a fatal error on your site. Warning: it is strongly advised to not test this on a production server. Fatal errors can be forced as follows:

1. Set $config['system.logging']['error_level'] = 'hide'; in settings.php
2. Set incorrect database credentials in settings.php (for example invalid username)
3. Refresh the page
4. Confirm that the template has been picked up