Problem/Motivation

If you translate inline blocks (also with tmgmt), layout builder doesn't recognise the translation.

Steps to reproduce

Translate inline blocks with tmgmt and the patch on the related issue.
Go to translated page and the content stills in its original language.

Proposed resolution

Apply the patch on the relates issue to let tmgmt translate inline blocks.
Make layout builder read translated content.

Remaining tasks

For doing this with paragraphs you need to add the "translation" tag on the twig template. You also need twig tweak module to use the translation tag. Doing this without altering twig template will be awesome.
Needs test files.

User interface changes

API changes

Data model changes

Release notes snippet

Instructions for translating layout builder blocks with/o paragraphs and tmgmt:
** These instructions asume you have configured a translation provider
for tmgmt.

1- Apply both patches.

2- Enable layout builder on a specific content type from the manage form
display tab.

3- Add a language to Drupal at /admin/config/regional/language/add

4- Enable the translations for the content type and the required blocks
and paragraphs if needed at /admin/config/regional/content-language.

5- Disable the "Users may translate this field" for each nested paragraph
field for a certain entity type like inline blocks or content entities.
This can be found at /admin/structure/types/manage/my_entity_type/fields.
For more information on this step please visit:
https://www.drupal.org/docs/contributed-modules/paragraphs/multilingual-...

6- Create content of the content type where the layout builder was
enabled.

7- Once the content is created go to the Layout Tab, add a custom or
library block and save the layout.

8- Go to translation tab.

9- Make sure "Add layout blocks to translation job" is checked.

10- Check the desired target language and click "Request translation"
button. You will be redirected to the translation job page.

11- Click "Submit to provider button.

12- Depending on the provider the transltion could require some time.
If you are working with the provider testing environment the translation
can take at least 15 minutes.

13- Go to the translation jobs page at /admin/tmgmt/jobs.

14- Click "Manage" button to the left of the item row.

15- Click the "Auto-import" button. You will be redirected to the
translation jobs page. If the translation is ready you will se and
orange icon next to the translation, otherwise a message will be
displayed to inform there aren't translations to import yet.

16- Once the translation is ready, click again on the "Manage" button.

17- Now its time to review the translaton by clicking the "View" button
next to each item to be translated.

18- If the translated text is correct, click on "Save as completed"
button. Make this for each item to be translated.

19- If the block to translate contains paragraphs you need to modify the
twig template for the required block adding the following tag:
{% set entity = item.entity|translation %}
Then you can render a field with the following grammar:
{{ entity.field_my_custom_paragraph.value }}

20- Visit the translated conntent and now you can see the translated
content.

Problem/Motivation

follow up #3041659: Remove the layout tab from translations because Layout Builder does not support translations yet

Part of #3044386: [META] Make Layout Builder layouts translatable

Right now you are not able to translate layouts at all.

The most common use case is probably translating the block labels and inline blocks but having the actual layouts not change from language to language. For different layout per language: see #3040487: Allow Independent Layout Override Translations

Proposed resolution

1. Provide access to the Layout table on translations
2. On Translations the Layout builder would only allow translating labels and inline blocks
3. Translated settings for block would be stored a new field that would be translatable(the current Layout field would still be untranslatable)
4. Most blocks could only have labels as translated settings
5. Inline blocks could additionally have a block revision ID stored.

Remaining tasks

• Get#3013197: Cloning an implementation of SectionListInterface does not deep clone the Section or SectionComponent objectscommitted.
• Write more tests for Inline blocks. <-- We are here.
• Needs update path test for existing content before this change

User interface changes

API changes

Data model changes

Problem/Motivation

The latest revision views filter produces invalid SQL queries in some cases.

Steps to reproduce

1. Create a view targeting paragraphs
2. Add a reverse entity relationship with a node paragraphs field
3. Add a latest revision filter to that relationship

Example raw SQL query, produced from the view as described above:

SELECT
	paragraph__field_day.field_day_value AS paragraph__field_day_field_day_value,
	paragraphs_item_field_data.id AS id,
	paragraphs_item_field_data.langcode AS paragraphs_item_field_data_langcode,
	field_content_paragraphs_item_field_data.nid AS field_content_paragraphs_item_field_data_nid
FROM
	paragraphs_item_field_data paragraphs_item_field_data
	LEFT JOIN node__field_content node__field_content ON paragraphs_item_field_data.id = node__field_content.field_content_target_id
		AND node__field_content.deleted = '0'
	LEFT JOIN node_field_data field_content_paragraphs_item_field_data ON node__field_content.entity_id = field_content_paragraphs_item_field_data.nid
	# Below it goes wrong, since field_content_paragraphs_item_field_data is a table alias
	LEFT JOIN field_content_paragraphs_item_field_data field_content_paragraphs_item_field_data__field_content_paragraphs_item_field_data ON field_content_paragraphs_item_field_data.nid = field_content_paragraphs_item_field_data__field_content_paragraphs_item_field_data.nid
		AND field_content_paragraphs_item_field_data__field_content_paragraphs_item_field_data.vid > field_content_paragraphs_item_field_data.vid
	LEFT JOIN paragraph__field_day paragraph__field_day ON paragraphs_item_field_data.id = paragraph__field_day.entity_id
		AND(paragraph__field_day.deleted = '0'
			AND paragraph__field_day.langcode = paragraphs_item_field_data.langcode)
WHERE (paragraphs_item_field_data.parent_id = '1868')
AND((paragraphs_item_field_data.status = '1')
AND(paragraphs_item_field_data.type IN('festival_day'))
AND(field_content_paragraphs_item_field_data__field_content_paragraphs_item_field_data.nid IS NULL))
ORDER BY
	paragraph__field_day_field_day_value ASC

Proposed resolution

Use the table name instead of the alias when joining.

Problem/Motivation

More information about text formats

Text format
Filtered HTML

HideIssue summary & relationships
We have broadly three types of issues committed against core:

1. Features, introducing new functionality.
2. Tasks, changing or refactoring existing functionality
3. Bug fixes, fixing a bug with existing functionality, usually but not always without significant changes to behaviour.

For features we always require test coverage, although in general the bigger the feature being added, the harder it can be to determine whether the test coverage is sufficient.

For tasks the amount of new or changed test coverage depends on the kind of change being made. However refactoring that doesn't break tests or requires only minor changes to tests is generally assumed to have coverage.

For bug fixes we assume that if there's a bug, it must always be possible to write a test that fails without the bug fix being applied, so more or less every bug fix requires an accompanying test - there are rare occasions where multiple issues are being worked on at once, and test coverage is added in dependent issues.

While it's not the intention, this means that the test requirements for fixing a bug, are more strict than they are for refactoring or adding new features.

The types of bug we have are obviously very disparate, from single character typos in exception message placeholders to upgrade path data loss and fatal errors.

A test written for a specific bug fix will ensure it doesn't regress over time, and if the code path was otherwise completely untested it may prevent other regressions in the future, but in general it's less likely that a bug fix causes a regression than a task or new feature.

Bug fixes are sometimes complex issues where multiple code paths need testing, but sometimes they're straightforward developer mistakes that weren't caught in review, and we'd never have thought to have added explicit test coverage if they'd been spotted during patch review instead of after commit. See case studies below.

Bug fixes are also often the place where new or irregular core contributors interact with the core queue most, because they're contributing back fixes from client sites (where by definition they're manually testing the bugfixes they contribute, and will often have them applied via composer.patches.json). In general there is a high incentive to make improvements to the bug fix itself, but often neither knowledge nor incentive to write comprehensive test coverage - if you have the patch in composer.patches.json it's already fixed for you and apart from having to re-roll every year or so that might be the last time you think about it. Even if you do 8 re-rolls of the same 1-5 line bugfix, it will take you less time than 8 hours writing an rewriting a 50-line test and responding to reviews - and you might get reviews after you've already moved on from the project that needed the bug fix.

On top of this, it can be very hard to know where to add test coverage in core due to the sheer number of tests that we have, and unclear responsibilities and boundaries for when to add new assertions to an existing test, new methods on an existing test class, new test classes altogether etc. This represents a high barrier to contribution where there is an easy opt-out and quite significant consequences to the rest of the community for those issues not being fixed (possibly not for the specific issue, but in aggregate across hundreds of small bugfixes).

The is a further consequence that often the tests we require for small bugfixes aren't well scoped at all - they're one-off tests for very specific developer mistakes or simulating very specific contrib or custom code path interaction edge cases, not well structured generic tests of functionality (like the JSON:API/REST coverage) or high-impact coverage like upgrade path tests. By being extremely specific, they don't necessarily provide good coverage of the area they're testing, or they might be very tied to implementation and result in maintenance burden over time. This often leaves us with a choice of committing poor quality tests to get the bug fix applied, or ever-expanding the scope of a tiny issue to introduce better test coverage it was never the issue's fault didn't exist in the first place.

And with phpstan, test coverage is sometimes not the best cure anyway - we can look for general types of developer mistakes across core and contrib, vs. testing one specific case of it we already fixed. This is only just starting, but it gives us better options than we had in 2010.

Case study 1

#3223302: Changed Method label() in Taxonomy Terms results in Field/Name Changes is a still open issue, with a one-line bug fix, and ~100 lines of test coverage. The bug was opened in July 2021, a merge request was opened in November 2021, it was marked RTBC in January 2022, it was marked needs work in April 2022 for one change to the bugfix, and to add test coverage, tests were added, it was then marked needs work again for documentation issues with the test coverage.

The test added ensures that the specific developer mistake (calling ::label() in a getEntityLabelFieldValue() method) won't happen again for taxonomy terms. However, it does not add test coverage for other entity types in core - this would be out of scope for that issue, even though they're equally prone to a similar regression being introduced. The bug can't be reproduced with just core, you need contrib or custom code altering the term label to run into it.

Further, it's not even clear that test coverage is the best way to stop this happening again, the most likely cause would be a new entity type copying and pasting this pattern (in contrib or core) and making the same mistake, and for that phpstan seems more appropriate.

So to fix a one-line bug, we're adding a 100-line test that doesn't address the issue for other entity types or stop new entity types making the same mistake, and the bug still isn't fixed in any version of core.

My suggestion in this case would be to open a new issue 'Document and/or add test coverage/code style rules to ensure that entity label field getters don't call ::label()), and just commit the one-liner, but our current policy works against that kind of solution because it would be committing the bugfix 'without tests'.

Case study 2

#2561639: Wrong placeholder for exception shown when new fields are created during module installation fixes a typo in an exception message resulting in a placeholder not being replaced. It was opened in September 2015 with a patch. Marked needs work for tests in November 2015. Tests were written in the same month. It has gone between needs work, needs review, and RTBC for seven years due to various issues with the test coverage. It is still open, and we have neither the bug fix nor the tests in core seven years later. This is for a one character bugfix for an error message.

Heuristics

One risk of adopting this approach is it increases the likelihood of discussions on issues about whether they need test coverage or not, which has the potential to delay commits and burn people out too. To try to prevent this, we can start with a reasonably strict set of heuristics to apply to issues, unless the answer to the majority of these is 'yes' or there is some other specific reason not to include test coverage, we'd require tests by default.

1. Are there clear steps to reproduce on the issue?
2. Is it easy to verify via manual testing that the bug is fixed?
3. Is it a 'trivial' patch with small, easy to understand changes?
4. Is the code being changed in self-contained/@internal code that we don't expect contrib modules to interact with significantly? (plugins, controllers etc.)
5. If the bug was to regress, is this likely to impact sites that were applying the patch or working around the bug in some other way, that would have removed those mitigations once the bug was fixed in core?
6. Is the bug fix achieved without adding new, untested, code paths?
7. To add test coverage, would it need an explicit 'regression' test that mainly prevents us reverting the patch rather than improving coverage in general?
8. If the test coverage was deferrred to a follow-up, would it be easy for someone who didn't work on the original bug report to pick it up?
9. Does the issue expose a general lack of test coverage for the specific subsystem, and if so would it be better to add generic test coverage for that subsystem in a separate issue so that the test coverage can be added in a maintainable way, rather than a regression test?

Original report:
Writing tests is a good approach. It helps to reduce the number of bugs as we add new features. However for patches that do not bring any new functionality but fix bugs in existing features requiring tests is a destructive policy because it slows down the process of fixing bugs in Drupal core.
It is a quite typical case, when a patch for a bug is submitted and even reviewed but then it gets declined by core committer because of lack of tests. After this the issue may get stuck for a very long time (months/years). And there is a great chance the patch will never be commited. Furthermore it also happens that a fix that was already commited is reverted because of this testing policy. Which is kind of crazy because reverting a commit that fixes a bug is like deliberately commiting this bug.

Another point here is that writing tests may require different level of skills and area of expertise than fixing a bug. Drupal testing sub-system is rather complicated. At this moment it consists of 5 (?) different types of tests. On the other hand the patches for many bugs are trivial and could be processed in novice issues.

Proposed resolution

Allow trivial bug reports to be committed without test coverage, when generic test coverage scoped at a wider level, or CS/rector rules would be more appropriate.

For non-trivial or low level bugfixes, continue to require test coverage on the issue since in these cases we need be able to demonstrate the bug is fixed without manual testing.

Remaining tasks

Discuss and get it implemented.

Problem/Motivation

In Drupal 7, when you had an exposed Date filter on a View, and the user selected a start & end time that were both the same day, the View would return all results from that day. That is, the end date was interpreted as 23:59:59 and the start date as 00:00:00 on that day. However, when you do the same thing in Drupal 8, both the min and max filter values are interpreted as 00:00:00, such that only results for precisely midnight are returned.

Steps to reproduce

Create some data with date values, such as nodes with created timestamps. Create a View with an exposed filter on those values, with the operator set to "is between". Set both the min and max filter values to the day of one of the results. Note that the result no longer appears, because the day it occurred is not within the range of the filter.

Proposed resolution

Add a checkbox to the exposed filter configuration allowing the max date to be specified as "inclusive." When that box is checked, change the max value to 23:59:59 on the given date before running the query.

Remaining tasks

Add the checkbox. Rewrite the filter value.

User interface changes

Add the checkbox.

API changes

none.

Data model changes

none.

Release notes snippet

Allow date filters to be inclusive of the specified date.

See #2999721: [META] Deprecate the legacy include files before Drupal 9

Introduce API to handle maintenance mode using the service instance.
Replace MAINTENANCE_MODE constant calls with appropriate API calls.
Properly deprecate or move the functions from the legacy theme.maintenance.inc file.

• _drupal_maintenance_theme()
• template_preprocess_authorize_report()

In Drupal\Core\Render\PlaceholderGenerator::createPlaceholder() we assume that callback passed to #lazy_builder is a string. This is not always a case and in Drupal\Core\Render\Renderer::doRender() we actually allow anything that's callable, ie. strings, arrays, etc.

So now we should either allow arrays in Drupal\Core\Render\PlaceholderGenerator::createPlaceholder() or make Drupal\Core\Render\Renderer::doRender() that it only accepts strings. The latter one can be not easy to achive without breaking BC.

Problem/Motivation

This seems to be a regression of #2644468: Multiple image upload breaks image dimensions.

Steps to reproduce:

A translatable and moderated node type with an image field, that has the image field set to do property synchronization of the file/fid property (which internally includes width and title).

Trying to save a translation then results in "Non-translatable field elements can only be changed when updating the original language." and there is also a php notice: Message Notice: Undefined index: width in Drupal\content_translation\Plugin\Validation\Constraint\ContentTranslationSynchronizedFieldsConstraintValidator->hasSynchronizedPropertyChanges() (line 153...

Apparently width/height aren't set anymore in $items. I didn't yet investigate why that happens exactly, doesn't quite make sense to me yet, as it is a defined property, it should always be set?

Reverting #2644468: Multiple image upload breaks image dimensions fixes the problem.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Drupal's components (in the namespace Drupal\Component) all have composer.json files for #1826054: [Meta] Expose Drupal Components outside of Drupal.

For example, here's the Annotation component's composer.json:

{
  "name": "drupal/core-annotation",
  "description": "Annotation discovery and implementation of plugins.",
  "keywords": ["drupal"],
  "homepage": "https://www.drupal.org/project/drupal",
  "license": "GPL-2.0-or-later",
  "require": {
    "php": ">=7.3.0",
    "doctrine/annotations": "^1.4",
    "drupal/core-file-cache": "^8.8",
    "drupal/core-plugin": "^8.8",
    "drupal/core-utility": "^8.8"
  },
  "autoload": {
    "psr-4": {
      "Drupal\\Component\\Annotation\\": ""
    }
  }
}

There are several problems with this:

1. The PHP version requirement is wrong. Drupal core requires PHP 8.1, so PHP 8.1 syntax may appear in the core components at any time.
2. The constraint for Doctrine is out of date for D10; 10.0.x requires ^1.12.
3. The specified versions of other components are also wrong and/or broken. Very bad things would certainly happen if you tried to install the 8.8.x version of the Plugin component with parts of Drupal 10. I think the most we could guarantee is that they work with each other within the same major version. (Actually, this means they're all incorrect in Drupal 9 too, because they say ^8.8 rather than ^8.8 || 9.)

There is also no set of expectations anywhere that I could find about the support, BC, and ugprade path policies of the theoretical standalone packages that would come from these composer.json files. Nor has anyone reported the D9 components' packages being broken with unresolvable dependencies.

Proposed resolution

Either get rid of these files, or come up with a way to make them maintainable.

• One possibility is to write a script or something that at least updates them automatically for when a new major version is branched.
   

• That's still not a complete solution because they also would potentially need to be updated every time core increases a requirement for an external dependency they have a constraint on, which could happen in any minor or patch release.
   

• Additionally, the external dependencies would need to be updated between releases. For example, doctrine/annotation is going bye-bye in Drupal 10. (TBD whether this component will go along with it, or just be rewritten for the PHP attributes implementation, but other for other components it'd be easy to miss that removing a use statement might also mean needing to update the composer.json file.)

Remaining tasks

TBD

User interface changes

N/A

API changes

TBD

Data model changes

N/A

Release notes snippet

Drupal's Component packages are now semi-automated from drupal/drupal's update script.

The drupal/drupal dev repo now reconciles components' dependencies with those of drupal/core and drupal/drupal during a Composer update command.

This means that dependency constraints declared in the components will always follow the needs of Drupal core.

This step is taken to ease maintainership of these components.

Problem/Motivation

In #3051352: [Plan] Remove unused jQuery UI components and replace with a suite of contrib packages for the continuous upgrade path we deprecated jQuery UI components that core doesn't use.

However, we still need to remove the library definitions from Drupal core.

Some core libraries are still using jquery_ui components directly, like dialog - in these cases, we can't remove the actual files, but we can still remove the library definitions.

We can do this all in one go in this issue I think - should be pure deletion.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

There is no easy way to attach a listener to an element being dragged when a tabledrag widget is being used.

I needed this functionality to have a lightweight listener on an element of a tabledrag being dragged so I added a small patch.

Problem/Motivation

As it turned out in #2500525: Time ago/hence date/time formatting breaks caching; needs appropriate max age and #2686409: Time Ago summary does not render on Manage Display for Timestamp and Datetime fields the TimestampAgoFormatter formatter outputs a string that is very hard to cache. A time difference interval string changes very often making it uncacheable and then the whole page become uncacheable. The big problem here is that we return a string from the server that is refreshes very often. Using a max-age strategy works but it has the drawback of being very bad for the user experience.

Proposed resolution

1. Use the default TimestampFormatter formatter to show also a time difference formatted dates and deprecate TimestampAgoFormatter EDIT: The deprecation is discussed in #2938705: Consider deprecating TimestampAgoFormatter.
2. Add a new "Display as a time difference" option (as checkbox) in TimestampFormatter settings. When this setting is On, a Javascript snippet replaces the current output of the formatter, which is a human readable formatted date/time, with a Display as a time difference string expression. Also the "Display as a time difference" settings will be visible and configurable.
3. The time difference replacement is formatted using a jQuery snippet that converts the actual PHP time difference functionality.

Pros of this solution:

• Assures a dynamic time difference that can be refreshed by JS with an interval that should be configured in the formatter.
• Is cacheable.
• Degrades nice to a normal formatted date/time for non-JS browsers.

Additional improvements:

• Use the <time ...> HTML5 element.
• Add a title (tooltip) to <time ...> so that while displaying a time difference string, the user still can see the exact time by hovering with the mouse. The format of the tooltip should be configurable apart from the main date format because we may want a more detailed format than the main one.
• Allow configuration of time difference string pattern as the actual TimeAgoFormatter does.

Remaining tasks

• Add tests.
• Add a post update script to fix configurations of existing entity view displays that are using the TimestampFormatter.
• Add update path test.
• Open a followup for the datetime.module corresponding formatter.

User interface changes

• For site builders: New options in TimestampFormatter settings.
• For users: "Time difference" dates will be up-to-date (no cached) and will refresh in the client browser on a specific interval.

API changes

Deprecated TimestampAgoFormatter formatter. EDIT: Moved to #2938705: Consider deprecating TimestampAgoFormatter.

Data model changes

New settings for TimestampFormatter formatter.

Manual testing

• Create a Timestamp field
• The formatter is set to "Default". Edit the formatter settings
• Check the "Display as time difference"
• Configure
• Set the refresh interval to a lower value so that you can observe later, in node view, how the field is refreshing
• Save the formatter settings.
• Check the formatter settings summary.
• Create a new node and save.
• See that the field correctly shows the field value as time difference.
• Hover with the mouse and check that a detailed time tooltip pops-up
• Without reloading the page, check that the field is refreshing client side after the refresh interval expires.
• Disable Javascript and reload the page.
• Check that the field degrades to a normal time representation.

Formatter settings form

Formatter settings summary

Javascript shows the timestamp as time difference

The time difference refreshes after the refresh interval expires

Javascript disabled degradation

Release notes snippet

In order to show the date/time as time difference (e.g. '2 hours 23 minutes ago') the timestamp default formatter is exposing a setting "Display as a time difference". When enabled, the date/time is showed as time difference using Javascript, so the page remain cacheable. A refresh interval can be configured so that the time difference is refreshed without any page reload.

The image pattern proposed in #3072660: Allow white transparent pngs to be seen in image-preview and integrated with #3021092: Image field style update needs some design love to make it a bit more subtle.

I am using Drupal 8.9.13, and when click on save this page then getting some error.

Drupal\Core\Entity\EntityStorageException: A translation already exists for the specified language (de-de). in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 846 of /code/docroot/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

Please need help ASAP.

Problem/Motivation

Autocreate a is a great UX option for Entity Reference fields. Currently it is not available if you choose "Views" as the "Reference method", which is necessary if you want to filter the available choices.

Proposed resolution

Offer autocreate. So far this seems to require
- adapting the ViewsSelection EntityReferenceSelection plugin to offer autocomplete.
- removing a (probably unintended) characteristic of the getAutoCreateBundle method of the EntityReferenceAutocompleteWidget that makes it only work with selection handlers that have a target_bundles property, which ViewsSelection does not.

Remaining tasks

Tests needed.

User interface changes

"Autocreate" Checkbox in the entity reference field settings, and a "Store new items in" dropdown if it checked. These are identical to those for the default reference method.

API changes

None.

Data model changes

None.

Problem/Motivation

I do some validation inside of entity validators that isn't possible in field validators, such as comparing field values against one another or checking business logic to determine if the entity is a duplicate (not duplicate UUID, but effectively duplicate content.)

In all cases, if validation fails you get a 422 Unprocessable Entity status code back. This is generally great.

Except if I need to differentiate between invalid fields (the general use case) and the duplicate content case.

I've whipped up the attached MR to very conservatively let violations determine the HTTP status code. If all the violations set a code, and it is the same for all, then use that. Otherwise, default to the current behavior.

This would make json:api a more fluent HTTP API, but totally at the discretion of the developer.

Proposed resolution

Remaining tasks

If this looks like it will actually go into core/be entertained, write tests.

User interface changes

API changes

Potential for changed HTTP status code.

Data model changes

Release notes snippet

Problem/Motivation

When running a non-interactive install (e.g. while running tests with PHPUnit), if there are errors with the database connection, you get an unrelated error of "Undefined index: value" because the requirements array doesn't include the required keys for non-interactive error reporting. Depending on what you're testing the full error will look something like:

1) Drupal\Tests\node\Functional\NodeAccessBaseTableTest::testNodeAccessBasic
Undefined index: value

/path/to/drupal/core/includes/install.core.inc:2293
/path/to/drupal/core/includes/install.core.inc:1079
/path/to/drupal/core/includes/install.core.inc:693
/path/to/drupal/core/includes/install.core.inc:568
/path/to/drupal/core/includes/install.core.inc:118
/path/to/drupal/core/lib/Drupal/Core/Test/FunctionalTestSetupTrait.php:286
/path/to/drupal/core/tests/Drupal/Tests/BrowserTestBase.php:576
/path/to/drupal/core/tests/Drupal/Tests/BrowserTestBase.php:400
/path/to/drupal/core/modules/node/tests/src/Functional/NodeTestBase.php:33
/path/to/drupal/core/modules/node/tests/src/Functional/NodeAccessBaseTableTest.php:69
/path/to/drupal/vendor/phpunit/phpunit/src/Framework/TestResult.php:691

Steps to reproduce

• Setup your phpunit.xml so that tests run properly
• Introduce a typo into your database SIMPLETEST_DB setting
• Run any test that requires a database connection

Proposed resolution

The main issue here is just that the database item in the $requirements array generated by install_check_requirements() isn't structured correctly for how install_display_requirements displays non-interactive installation error messages. All we need to do is format that correctly and the error message will display as it should.

For the most part this is a minor issue, but for people just getting started with phpunit and testing it can be quite confusing at first.

Testing procedure

This issue is only visible when the database connection fails. So apart from a test that is all green, we should also run a test on an incompatible database (MySQL 5.5 for example) and in the test results the following message should be visible: 'Failed to run installer database tasks: The database server version 5.5.44-0ubuntu0.14.04.1 is less than the minimum required version 5.7.8.'

Problem/Motivation

Following the work from #3251709: Define Blue scale for Claro and defined in #3155531: Naming convention of color shades in the Drupal Design System (e.g. for Claro), we are creating a red color scale.
Right now we have 5 reds on the design system, but they are not completely related to each other and do not pass some accessibility tests.

Proposed resolution

Update the current red colors defined on the code and files with the new ones. Color definition can be seen at Figma, where you can copy&paste the color values:

Remaining tasks

• Replace the 6 red colors with the new ones
• Replace any icon color using red with the new ones. This will mean to:
  • Update the color inside the SVG
  • Update icons' directory names (based on their hexadecimal color).
  • Update any reference to that icons in the CSS.
• Accessibility sign-off

Testing steps

Components to test using red:

• Action link
• Button
• Ckeditor
• Fieldset
• Form
• Form password confirm
• Form checkbox/radio
• Form text / textarea
• Messages

User interface changes

All red colors will change their values.

Problem/Motivation

Language list is not correctly sorted when it's localized with accents. Especially if the first letter has an non ASCII letter they are sort to the end.
e.g. this Turkish country list:

Almanya
Birleşik Krallık(İngiltere) 
Fransa
Portekiz
Türkiye
Yunanistan
İspanya
İsviçre
İtalya

should be:

Almanya
Birleşik Krallık(İngiltere) 
Fransa
İspanya
İsviçre
İtalya
Portekiz
Türkiye
Yunanistan

e.g. this German country list:

Belgien
Frankreich
Schweden
<strong>Österreich</strong>

should be:

Belgien
Frankreich
<strong>Österreich</strong>
Schweden

Steps to reproduce

Proposed resolution

natcasesort in CountryManager should be replaced with an uasort with Drupal\Component\Transliteration\PhpTransliteration

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

For instance, in my view's Header I have a Global: Text area.
From the available tokens I cannot choose a token for the value selected by the exposed filter(s).
So each time an exposed filter is added a token should be created for the value of the filter.