Problem/Motivation

Our current transliteration class has a method to remove diacritics from certain Latin characters. It is desirable this to be expanded to other scripts.

The current behavior is custom. It was written to remove diacritics from a range of characters with an eye on how HTML entities are called, not from a Unicode perspective. The commonly suggested way -- utlizied by Libreoffice and Firefox both -- is to use Unicode decomposition rules, remove Unicode major category "M" (aka combining characters) and re-compose them. But our solution is different. For example, it changes o with stroke to just o and as this SO answer notes, Unicode doesn't decompose it and leaves it alone. There's no right or wrong answer whether it should be rewritten: Wikipedia notes this character is treated as a separate letter in Norwegian and Danish and as such it probably shouldn't be rewritten for those but in other languages it perhaps should be.

In other words, currently the word Øresund will be stored as oresund but if we were to follow the standard way above it would be stored literally. And then searching for oresund finds it currently but wouldn't if we were to follow the standard way.

Out of the 323 characters falling within the ranges PhpTransliteration::removeDiacritics() as many as 48 (~15%) exhibit different behavior under the suggested standard route compared to the current one. Six of them are genuine bugs fixed in #3151364: diacritics are not removed from ǢǣǼǽǮǯ .

Proposed resolution

If intl is not enabled we stick to the current behavior. It is certainly possible to generate the NFD and NFC tables from the UCD and https://gist.github.com/hoehrmann/5652435 and the XO_NFD / XO_NFC properties. I doubt the effort is worth it and also the speed, especially for NFC would be abominably slow.

If intl is enabled then we introduce a pair of new classes, similar to the current Php pairs, the Component one does the work, the Core one does the alter. Also pass the langcode from search to removeDiacritics. We add the rules necessary to achieve parity with PhpTransliterator on the range it operates.

Remaining tasks

Immediate: write the test for alter. Possibly separate the component tests for the two classes by moving the classname to a constant, extending the class for intl and skip the test if intl is not enabled.

Either here or followups: give the community some way to supply sensible rules and settings as adequate. A Hungarian site for a Hungarian audience doesn't want to remove the diacritics Hungarian uses at all. However, a site about Hungary for more international audiences? I do not even know.

User interface changes

API changes

TransliterationInterface::removeDiacritics gets a new, optional argument.

Data model changes

Release notes snippet

Original report

when removing diacritics in function search_simplify(), it not considering remove Arabic diacritics. How to test: add this text to any article: "السُّلَّامُ عَلَيْكُمْ وَرَحْمَةُ اللهِ وَبَرَكَاتُهُ" then search for "السلام". learning form this article, I develop an ugly patch to fix it. It may be better to move it to PhpTransliteration.php but I am not sure.

Whenever I am editing a view with a display of page, if I change the path in the page settings, the change is not reflected in the Preview pane despite Auto Preview being checked. A screenshot showing this lack of update is attached.

Problem/Motivation

Our phpunit based functional javascript test will pass even if there are Javascript errors on the page.

While we test JS functionality sometimes a JS error will not break our tests because the core functionality still works but other JS that is the page of a particular site could be broken.

A user ran into this scenario on #3072231: Custom blocks break layout builder module - Quick Edit could not associate the rendered entity field markup

Proposed resolution

if a Javascript error is thrown to during a test fail the test.

Additionally

1. All core tests should fail on Console errors by default. Each class should not need to set a property so that we cannot ignore console errors in core tests by forgetting this property
2. Core tests should be able to set the property protected $failOnJavascriptConsoleErrors = FALSE; to suppress errors for 2 reasons
   1) This will allows use to commit this with known errors such as #3091878: MediaEmbedFilterConfigurationUiTest throws a Javascript Error or any others we find at the time we are able to commit this this issue. Before we commit this at any point we can't be sure how many tests will fail with this patch applied. We could be adding new tests that throw JS console errors with any commit.
   2)After this patch is committed we could have tests start to fail for a number of reasons such as, changes in the chrome driver/browser Drupalci uses or needed updates to our JS dependences. In the example of our JS dependencies these could be security updates that we need ASAP but also cause a small non-important JS console error. In such cases we should be able to commit the dependency updates and do a follow-up to fix the error.
3. Any class that extends \Drupal\FunctionalJavascriptTests\WebDriverTestBaseexcept core test, i.e Contrib and custom test, should have to opt in this behavior by setting protected $failOnJavascriptConsoleErrors = TRUE;. This will ensure a bunch of contrib tests will not start to fail after we commit this patch. We could consider changing this to opt out in Drupal 10
4. Contrib/custom tests should be able to opt in a bunch of classes at once by setting protected $failOnJavascriptConsoleErrors = TRUE; in a base test class like, MyModuleTestBase

Remaining tasks

All

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

TBD

Problem/Motivation

There is no need to use t() in tests, unless we're testing translations, however in core we do not follow this consistently, which does not set a good example for new contributions.

In #3133726: [meta] Remove usage of t() in tests not testing translation we identified there are severals of calls to t() in calls to assertEqual() and assertEquals() and that removing all these in one go seems to be a suitable way of attacking this problem.

Proposed resolution

Identify and remove all calls to t() wrapped in calls to assertEqual() and assertEquals(), except those used by translation-related code (if any).

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

New browser features enable better website integration to users' systems. While working on the progressive web app module I came across a W3C draft for a manifest file. This file is used on mobile devices to allow website authors some control over the way the shortcut and initialization screen looks like.

Proposed resolution

• Add new form fields and reorganize the site information form.
• Add a <link rel="manifest" href="…/manifest.json"> tag in the head and a way to generate that file.
• Generation of a manifest.json file containing at least:
  

  {
    "lang": "en",
    "dir": "ltr",
    "name": "Very good Drupal Website™",
    "short_name": "Drupal Website™",
    "icons": [{
          "src": "my/default/theme/logo.png",
          "sizes": "144x144"
        }],
    "start_url": "/",
    "display": "browser",
    "orientation": "portrait",
    "theme_color": "#ffffff",
    "background_color": "#ffffff"
  }
  

• We need to add a <meta name="theme-color"> tag for branding color to compliment the values set inside manifest.json

User interface changes

Site information form changes. New fields:

• short_name (textfield)
• start_url (textfield) Could be different from the site homepage.
• display (select list/radio)
• orientation (select list/radio)
• theme_color (probably expose that to themes)
• background_color (probably expose that to themes)

API changes

Probably some ways for theme to declare/alter informations in the manifest file.

More details: Web app manifests usher new wave of progressive apps to your homescreen.

Problem/Motivation

In Drupal 8.5 contextual links were introduced for media entities.

See #2775131: Media entities should support contextual links.

For well trained editors this can be a very useful feature. However, after many months of practical usage I have found this can cause problems and confusion for less skilled editors.

The links can be confused for those used by content entities. Misuse can also result in media assets being unintentionally removed from the library.

Proposed resolution

Provide a facility to make contextual links for media entities optional.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Duplicate ID's occur in webforms with rich text field with help enabled. Multiple id were detected using the a11y inspector Axe (browser tool).

The situation

1. CKEditor module includes the label of the editor's parent field into various places. The JavaScript responsible for this, allows HTML to be included.
2. Webform module modifies the readable label (title) of the form-element-label.html.twig template to add a help functionality inside of the label tag. A span with id is appended to the label text.
3. The HTML content of the label is copied by the CKEditor script (ckeditor.js) to 3 other places on the page, including the span's id property.

Steps to reproduce

• Create a webform with a Text format field with help text.
• Analyze the webform with Axe
• Notice the error: "IDs used in ARIA and labels must be unique"

DOM snippets below taken from article body field.

<div class="form-textarea-wrapper">
  ...
  <span id="cke_edit-body-0-value_arialbl" class="cke_voice_label">Rich Text Editor, Body field</span>

<iframe class="cke_wysiwyg_frame" title="Rich Text Editor, Body field">
  <head>
    ...
    <title data-cke-title="Rich Text Editor, Body field">Rich Text Editor, Body field</title>

DOM snippet of field label modified by Webform

<label for="edit-webform-field-value">Webform field
  <span class="tooltip__text js-tooltip" id="webform-element-help">
    Example help text.
  </span>
</label>

Proposed resolution

Let CKEditor only copy the text portion of the label. Not allowing HTML.

Not sure where the right place to solve this, either core and webform are candidates. My first success was with core.

Remaining tasks

t.b.d.

User interface changes

Avoid problems caused by duplicate IDs for non-sighted users.

Problem/Motivation

When using the database log for debugging, sometimes it would be useful to be able to quickly jump to the next or previous record.

Steps to reproduce

Proposed resolution

Add Next/Previous links/buttons somewhere on the /admin/reports/dblog/event/12345 page.

Remaining tasks

Decide on UI
Write patch

User interface changes

New links/buttons on the database log entry pages.

API changes

None

Data model changes

None

Release notes snippet

Problem/Motivation

A bug in libraries-override #2451411: Add libraries-override to themes' *.info.yml makes it difficult to override a library or library asset that has already been overridden. You have to know the theme which last overrode a library and then use the full path to the overriding theme asset. This presents a WTF to themers and makes it difficult to reuse theme code. It also makes the sub-theme dependent on the internal file structure of the base theme.

In normal circumstances overriding an already overridden library would be and edge case, but with the introduction of the Stable base theme, a lot of system libraries have already been overridden. This also implies that possible future changes in the asset file structure of Stable could break sub-themes that override libraries already overridden by Stable.

Workaround

The current workaround is explained in #2642122-4: Overriding already overridden libraries-override requires knowledge of previous libraries-overrides and #2642122-18: Overriding already overridden libraries-override requires knowledge of previous libraries-overrides.

Proposed resolution

1. Fix the bug so that the libraries-override declaration should use the same keys as the libraries declaration in the original libraries.yml file.
2. Maintain a BC layer so that themes that have already used the workaround will not break immediately. Remove the BC layer in D9 (#2852314: Remove BC layer for libraries-override that is already overridden)

Remaining tasks

Reviews
Commit

User interface changes

None

API changes

Method signatures of 3 protected methods in LibraryDiscoveryParser are changed

Data model changes

None.

Problem/Motivation

When trying to set part of an overridden display's configuration, the user ends up with broken configuration.

Steps to reproduce:

1. Create a view with a display (A) with overridden filters
2. Save
3. Edit the view to make A's filters the default filters, e.g. via "Rearrange filters" dialog (ie on the Rearrange Filters dialog, select 'All Displays' in the For option.)
4. Notice that A's filters have changed, instead of the default display's

Expected result:
Display A's filters are set as default. Display A no longer uses overridden filters.

Actual result:
Display A uses the filters of the default display. Display A no longer uses overridden filters.

This means, that upon saving the view, A's filters are lost irreversibly.
If both the default and the overridden display used filters of the same names, this will be hard to spot and lead to confusion and possibly errors later on, as filter values are changed behind the scenes. If A used additional filters, these will all be changed to "Broken handler".

The "Use as default" behavior effectively duplicates the "Revert to default" behavior, with the added bonus of unexpectedly altering the view. This broken behavior has been around for quite a while, and also happened in D7 (see https://www.drupal.org/node/2313791).

Proposed resolution

Upon closer inspection, it seems that views_ui never actually passes the display's configuration to the default display, even though the code comments state it does. So we have to properly implement this de-override behavior.

Remaining tasks

Write tests to reproduce, review suggested patch.

Problem/Motivation

When there's a limited amount of horizontal space, the shortcut action link will move to the next line. This looks awkward especially when only the star icon is visible.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

The addition of more spacing looks great, but on a laptop screen it means that there's no actual content of admin views visible above the fold. I have a 13" MacBook, and as you can see in the screenshot, the admin/people page is completely filled up with the header and the filters and actions.

In order to install drupal with a decent awareness of the choices I make, I would like to receive a confirmation of what I deduced.
Supposing the served website is intended mainly for an Italian audience, I think it's correct to think of Italian as the original language for any published piece of text and English as something that may come after. I have to say, though, when dealing with an administration interface I don't like to rely on translations, and English is my language of choice anytime. If I specify English during the installation, though, it becomes the original language for articles, basic pages, and the like and I cannot set Italian as the original language afterward so Italian has to be the language I specify during installation: is it correct?

Thanks in advance!

Andrea

P.S. Why at the moment I cannot specify versions different from the dev ones for this post? Actually I'm not using a dev version...

Problem/Motivation

\Drupal\jsonapi\JsonApiResource\ResourceIdentifier::toResourceIdentifiers iterates of a EntityReferenceFieldItemListInterface field list and individually loads each referenced entity. This can be improved by loading all referenced entities ahead of time.

Steps to reproduce

Visit a relationship endpoint for an entity.

Proposed resolution

Call referencesEntities before iterating over the field list's values

  public static function toResourceIdentifiers(EntityReferenceFieldItemListInterface $items) {
     // Load all referenced entities ahead of time.
    $items->referencedEntities();
    $relationships = [];
    foreach ($items->filterEmptyItems() as $item) {

Remaining tasks

Before and after profiling?

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

View titles in breadcrumbs are being passed through the TranslationManager service as English strings.
The problem is, view titles aren't even necessarily in English, resulting in incorrectly langcoded strings in the user interface translation set. Even worse, if a view's original language isn't English, its title will be impossible to translate to English in the breadcrumb (because it will be incorrectly langcoded as an English string).
Breadcrumbs should use the view's translated title if available, and not use the TranslationManager service at all in case views are translatable, seeing that views are part of the configuration, not the user interface.

How to reproduce:
1) Clean install Drupal 8.1
2) Enable the Content Translation, Configuration Translation and Language modules, enable one language other than English, enable the translation of views, (menu links) and the basic page content type.
3) Create a node/page based view ('Test view', path: 'test'), translate said view (e.g. 'Testansicht').
4) Create a test page ('Test page', path: 'test/page1'), translate it (e.g. 'Testpage', path: 'test/page1' [or anything matching 'test/*']).

The breadcrumb for the translated page will be something like: 'Startseite > Test view > Testpage' instead of 'Startsite >Testansicht > Testpage' as it properly should be.

Problem/Motivation

Guzzle 7 went into beta this week, and we want to determine if we are compatible with it in case Guzzle 7.0.0 is released before Drupal 9. However, as it stands today we're blocked from updating by a conflicting requirement version constraint on Guzzle from fabpot/goutte:3.x via behat/mink-goutte-driver.

Proposed resolution

We should open an upstream issue with behat/mink-goutte-driver to fix the conflict. In the meantime, we should create a patch that "tricks" Composer into installing the Guzzle beta so we can run tests against it.

Remaining tasks

• Open an issue against behat/mink-goutte-driver. (Done.)
• Monitor said pull request.
• Create a test patch that updates our core/composer.json requirement to the Guzzle 7 beta.
• Investigate any test failures, etc. (None)

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

Needed. TBD.

Problem/Motivation

ResourceTestBase uses assertSame for asserting values. This is breaks comparisons of stringified floats, making the test class hard to use.

assertEquals also returns a generated difference between the values, which assertSame does not. This would improve the DX for comparing JSON:API documents.

See #3128322: Filtering variations over JSON:API is always access false.

Steps to reproduce

Use a decimal field with precision storage of 6. 4.00 will serialize to JSON as 4.0 but return from MySQL as 4.00000

Proposed resolution

Switch from assertSame to assertEquals

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The logout link can only be requested between the time a page was requested and when a session expires. If a user agent has a stale page, such as due to caching or a long lived page, then attempts to logout after the session expires, he will receive a 403 access denied.

Proposed resolution

if an anonymous session attempts to access user/logout, the site will redirect to the front page without fuss.

Behaviour changes

User redirected to <front> route instead of 403

Original report by jim_at_miramontes

I don't think this is a duplicate of any previous issues; I'm encountering this situation with a D7 site: a user:

1. leaves a browser window open on the site,
2. gets timed out on the back end for having been inactive too long,
3. returns to the browser after that long delay, and
4. without refreshing the page, tries to log out via a link on that page to user/logout.

The access callback for user/logout is user_is_logged_in(), which fails in this situation since the user is logged out. As a result, the user gets the results of a 403 error rather than being thrown back to the home page via the drupal_goto() in user_logout().

This is admittedly a minor point, but it wouldn't be hard to address:
Give user_logout() an open access callback so it can run even when the user is logged out, and
Modify user_logout() do only do its work if there is a logged-in $user (and maybe raise an error message via drupal_set_message if the user was already logged out).

(See https://drupal.org/node/2192401 for a bit more discussion of this, btw.)

Currently when configuring a responsive image format for a field, the list of responsive styles are sorted by machine name, not the style label. This can be confusing if the style labels are set so they display in a particular order, just as to map to a size scale.

Also, since the machine name is going to be removed from the styles table list with: https://www.drupal.org/project/drupal/issues/2988905 this will make the formatter list appear unsorted altogether.

Problem/Motivation

Spun-off from #2878119: Whether queued or not, update the media thumbnail and metadata before beginning the entity save database transaction.
On that issue, we identified that in many places it may make sense to let end users trigger / force an immediate update of the asset's metadata.

Proposed resolution

Expose to the UI the possibility of end users with correct permissions to trigger an immediate update of the asset's metadata + thumbnail

Remaining tasks

User interface changes

- New contextual link "Update metadata" is available in the front-end

- New operation dropbutton "Update metadata" is available in the back-end

- New "Update metadata" action is available in media administrative views, as a bulk operation.

API changes

A new public method \Drupal\media\MediaInterface::updateMetadata() is added to the Media interface.

Data model changes

None