Problem/Motivation

We've forked jQuery UI components into core, but for now have left the version numbers unchanged.

See brief discussion at #3087685-43: Remove deprecated jQuery UI components and fork remaining source code into core and #3087685-44: Remove deprecated jQuery UI components and fork remaining source code into core.

Proposed resolution

Keep the jQuery version as 1.12.1 until we introduce a change to the source. Whenever we make a change to the sources, add an extra suffix string to the version:

Add a version string postfix starting with zero (to indicate non-release status), and increment the patch, minor, or major version as appropriate under semver depending on the types of changes needed to jQuery UI. Examples: 1.12.1+0.0.1, 1.12.1+0.1.0

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

URLs that are filled into a link field should be stored as the internal path when possible. Currently this works if the field is used to search for the destination using the autocomplete field, but it doesn't work if the absolute URL for that path is pasted in.

Proposed resolution

If someone fills in a link field with an absolute URL link to a path on the site, the link field should convert the values to the internal paths.

Remaining tasks

• Update the Link field to convert absolute URLs to internal paths.
• Write test coverage.

User interface changes

None?

API changes

TBD.

Data model changes

TBD.

Release notes snippet

TBD.

Problem/Motivation

The media Authored by filter should use the user_name filter plugin OOTB in order to be consistent with Content, and provide a better UX with an autocomplete field.

Proposed resolution

Add this one liner to MediaViewsData

$data['media_field_data']['uid']['filter']['id'] = 'user_name';

How to test

1. Enable the media module.
2. Create a view for media content.
3. Add an media author filter to a view and make it an exposed filter.
4. Notice it's a simple text field and takes the uid as a value.
5. Remove the filter and apply the patch, clearing caches just to be sure.
6. Add the filter again, notice it's now an autocomplete field taking usernames as the values.

Problem/Motivation

If you visit update.php (tested from 8.8.x to 9.0.x), and make it to the "Overview" page, you see:

2. Put your site into maintenance mode.

The link is broken, and is relative to update.php, not index.php. So you get links like:

http://localhost/drupal-8_8/update.php/admin/config/development/maintenance

If you click on that, you get a WSOD with the following:

The website encountered an unexpected error. Please try again later.
TypeError: Argument 1 passed to Drupal\Core\ProxyClass\Render\BareHtmlPageRenderer::renderBarePage() must be of the type array, bool given, called in /.../drupal-8_8/core/modules/system/src/Controller/DbUpdateController.php on line 195 in Drupal\Core\ProxyClass\Render\BareHtmlPageRenderer->renderBarePage() (line 73 of core/lib/Drupal/Core/ProxyClass/Render/BareHtmlPageRenderer.php).

Proposed resolution

Fix the broken link so that it goes to admin/config/development/maintenance not update.php/admin/config/development/maintenance.

Remaining tasks

1. Add test coverage.
2. Find/fix the bug.
3. Reviews/improvements.
4. RTBC.
5. Commit.

User interface changes

Fixes a broken link on update.php to "Put your site into maintenance mode".

API changes

N/A

Data model changes

N/A

Release notes snippet

TBD.

Original report A

I am received this error while using site/update.php, may I know how to fix this issue, Recoverable fatal error: Argument 1 passed to Drupal\Core\ProxyClass\Render\BareHtmlPageRenderer::renderBarePage() must be of the type array, boolean given, called in /var/www/html/mystore/web/core/modules/system/src/Controller/DbUpdateController.php on line 201 and defined in Drupal\Core\ProxyClass\Render\BareHtmlPageRenderer->renderBarePage() (line 77 of /var/www/html/mystore/web/core/lib/Drupal/Core/ProxyClass/Render/BareHtmlPageRenderer.php)

Original report B

The link to maintenance mode on overview section (/update.php) is wrong. When drupal generate the url a file name is added on URL broken the link. For example this link is:

Actually: http://localhost/drupal/update.php/admin/config/development/maintenance

Correct: http://localhost/drupal/admin/config/development/maintenance

FILE: E:\xampp\htdocs\drupal9test\core\modules\media\media.info.yml
-----------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
-----------------------------------------------------------------------------------------------------------
1 | WARNING | Remove "version" from the info file, it will be added by drupal.org packaging automatically
-----------------------------------------------------------------------------------------------------------

FILE: E:\xampp\htdocs\drupal9test\core\modules\media\media.module
----------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
----------------------------------------------------------------------
344 | ERROR | Type hint "array" missing for $allowed_bundles
----------------------------------------------------------------------

FILE: E:\xampp\htdocs\drupal9test\core\modules\media\src\Annotation\MediaSource.php
-----------------------------------------------------------------------------------
FOUND 2 ERRORS AFFECTING 2 LINES
-----------------------------------------------------------------------------------
93 | ERROR | Doc comment short description must start with a capital letter
102 | ERROR | Doc comment short description must start with a capital letter
-----------------------------------------------------------------------------------

Problem/Motivation

Neither EntityFormDisplay nor EntityViewDisplay have a label key, and as such their ::label() method returns NULL.

Proposed resolution

Implement ::label(), returning a string indicating which entity type, bundle, and view mode are represented.

Remaining tasks

Decide on the string to present and then use it in the Field UI.

User interface changes

Steps to check the label with the Layout builder module installed first:

Node:【Structure】->【Content types】->【Article】->【Manage Display】->【Default】/【Teaser】mode ->【 Use Layout Builder】->【Manage Layout】

User:【Configuration】->【Account Settings】->【Manage Display】->【Default】mode ->【 Use Layout Builder】->【Manage Layout】

API changes

Data model changes

Updated: Comment #150

Problem/Motivation

When an array of suggestions is passed to theme(), the twig_debug output doesn't match up.

Proposed resolution

Since the "array of theme hooks" feature has been in core since 6.x and so it's likely to be used (i.e in Views until #2923634: [PP-1] Use hook_theme_suggestions in views is in), this is still technically a bug and needs to be fixed and so we need to display the suggestions that are passed in as an array.
However it should be removed entirely once all deprecated code is removed in the future.

This issue should fix the bug BUT keeping in mind passing an array of theme hooks to #theme should be discouraged.

Remaining tasks

1. Patch
2. Tests
3. Wait for #2923634: [PP-1] Use hook_theme_suggestions in views to be in, in order to fix the only(?) core components using "array of theme hooks" instead of the proper hook_theme_suggestions
4. Wait for #2752443: Incorrect order and duplicate theme hook suggestions to be in, as currently listed suggestions are duplicated and not ordered correctly
5. Wait for #2923506: Deprecate and discourage use of the "array of theme hooks" feature to be in, so the usage of "array of theme hooks" is deprecated
6. Final polishing and reviews
7. Commit
8. Create a follow-up for removing "array of theme hooks"

User interface changes

Twig debug output will display the suggestions passed in as an array.

API changes

None.

Problem/Motivation

Right now, when you complete a Drupal 8 migration, AFAICS in all cases, you get your node/comment titles moved over, but the bodies display as blank:

The data for the fields is in the database, but getting stripped out on the front end.

According to the migrate team, this happens when filter formats not recognized by Drupal 8; they get migrated as filter_null, a filter that simply returns an empty string. However, to an "end user" it just appears that migrations don't work, even for very simple core cases where no fancy non-core input formats were used.

Major/Migrate critical because this represents a pretty significant usability hurdle, and harms user confidence in the system early on.

Proposed resolution

Instead, map mismatched filter formats to fallback_format (defaults to plain text).

The one possible reason not to do this is PHP code filter, where you could inadvertently expose database credentials that would now be exposed in plain text. However, we could probably deal with this case specially. (For example, explicitly setting that one to filter_null to indicate it needs attention.)

Remaining tasks

• Write a patch + tests
• Review it
• Commit it!

User interface changes

By default, migrations will now display at least something for body field content for nodes and comments. (As well as other rich text fields.)

API changes

?

Data model changes

N/A?

Release notes snippet

Migrations now default to the fallback filter format, fixing a problem where rich text fields were not displaying post-migration.

Without status parameters file uploaded with "temporary " status, I want to upload with permanent status and with correct MIME which I passed through API

{
    "_links": {
        "type": {
            "href": "http://ipaas-cms.lndo.site/rest/type/file/image"
        }
    },
    "filename": [
        {
            "value": "virus-image-test-1.jpg"
        }
    ],
    "status": [
        {
            "value": "1"
        }
    ],
    "filemime": [
        {
            "value": "image/jpeg"
        }
    ],
    "type": [
        {
            "value": "file:image",
            "target_id": "image"
        }
    ],
    "filesize": [
        {
            "value": "3190"
        }
    ],
    "data": [
        {
            "value": "/9j/4AAQSkZJRgABAQEAYABgAAD/4QAiRXhpZgAATU0AKgAAAAgAAQESAAMAAAABAA..........."
        }
    ]
}

Problem/Motivation

#3113077: [backport] Replace assertContains() on strings with assertStringContainsString() or assertStringContainsStringIgnoringCase() removes usages of the assertContains() method on string haystacks from core in D9. It might be useful for contrib projects trying to maintain both 8.x and 9.x compatibility to have the new methods available in 8.9.x, or even 8.8.x.

This is a D8 only issue.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

This is a follow-up to #1953568: Make the bundle settings for entity reference fields more visible..

When configuring a field (such as /admin/structure/types/manage/article/fields/node.article.field_tags) there are several form elements used by all field types (Label, Help text, Required checkbox). Some field types, such as Entity reference and Link, have additional settings. We would like to make these additional settings, when present, easier to identify.

Proposed resolution

Whenever a field type adds settings to the configuration form, wrap those settings in a fieldset.

Standardize the fieldset label.

Remaining tasks

• Add screenshots to the issue summary.
• Decide whether the wrapper element should be added by the field-type plugin or by the parent form.
• Decide on the standard label: something like "FIELD_TYPE settings" or "FIELD_TYPE options".

User interface changes

This will change the appearance of the field configuration form.

API changes

Whichever implementation we use, the documentation of the form elements returned by the field-type plugin will have to be updated.

Data model changes

None

Problem/Motivation

We need to support migration of several different types of legacy reference fields to D8:

• Node and user reference, for both D6 and D7
• D7 taxonomy term reference fields
• D7 entity reference fields

Proposed resolution

Create a base class for migrate field plugins that handle all reference-type fields, since they tend to be more similar than they are different. Implement the node and user reference migrations for Drupal 6.

Remaining tasks

Write the patch, tests, docs. Let's pull ReferenceBase out of the patchzilla in #191, clean it up, and turn it into its own patch.

User interface changes

None.

API changes

• The namespace of the internal nodereference MigrateField plugin changes to Drupal\migrate_drupal\Plugin\migrate\field\d6.
• The internal nodereference MigrateField plugin now extends the new Drupal\migrate_drupal\Plugin\migrate\field\ReferenceBase class.

Release notes snippet

TBD

Now that we have serializer support for JSON and XML. The last one it makes sense to implement is YAML. Then we have the most common serialization formats out of the box. Plus, as we already have the YAML component, this is a relatively small amount of code.

This could open out some (possibly crazy) possibilities using rest web services with configuration too.

Here is an initial patch, we have to create the encoder from scratch as symfony doesn't have one, but this could be patched upstream later if possible?

Problem/Motivation

It is impossible to load additional JS libraries in an Ajax response and then call that code through Ajax commands, because Drupal.ajax does not guarantee that the JS library will already have loaded.

See #23 and #31 for details.

Proposed resolution

TBD.

Remaining tasks

TBD.

User interface changes

None.

API changes

TBD

Related Issues

TBD

Original report by [username]

Hi,

Thanks for your module, it works perfect for me.

But I found there one small bug there: if all my .js files are mapped to the external CDN, ajax redirects doesn't execute. After some tests I found that CDN rewrites all js urls, even for ajax. So I attached a small patch that solved this problem for me.

Best regards,
Spleshka.

Problem/Motivation

At the moment there is no testing for the different installer exception. We should have testing for that.

Proposed resolution

Create the tests.

Remaining tasks

TBD

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

TBD

Problem/Motivation

Follow-up from #3120910: Sites with missing schema information can't update to 8.8.3+ - attempts to run all historical updates, which is a second attempt to fix the symptoms of this problem. As yet we've not identified what the cause might be.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

We should deprecate the functions in includes/schema.inc.

Just spinning off a follow up to #2124069: Convert schema.inc to a service

Proposed resolution

Deprecate the following functions from includes/schema.inc and create a new service called "schema_installer" and move the functionality to the new service:
1. drupal_get_installed_schema_version()
2. drupal_set_installed_schema_version()
3. drupal_install_schema()
4. drupal_uninstall_schema()
5. drupal_get_module_schema()
6. _drupal_schema_initialize()

Remaining tasks

TBD

User interface changes

None

API changes

See proposed solution.

Data model changes

None

Release notes snippet

TBD

Problem/Motivation

#3136668: Invalid system.schema key_value entry causes fatal on updating to 8.8.5 discovered that system.schema information sometimes stays in the system after a module has been uninstalled.

In that issue, we added logging for when the site has orphaned system.schema information.

Since we definitely don't have a module, we could probably safely delete the cruft. Opening this against Drupal 10 because we don't know the root cause of the bug yet, and the logging is the most likely way we'll find out. We may want to postpone this on the root cause being identified and fixed too.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

It's not possible to create tables with datetime fields using the schema api if you want to have a default value of now() or current_timestamp. This happens because all strings are escaped with ' before going to the database. Database function calls like now() do not work if escaped. The attached patch allows now() to be used for datetime fields.

Problem/Motivation

This is an add-on to #3089523: Use progressive disclosure to hide Sort options on entity reference fields until bundles are selected and #2900409: [Meta] Improve UI of Reference field settings form.

In the first referenced issue, the progressive disclosure concept was applied to the sort by element. The same concept applies to the sort direction element. The code in Drupal/Core/Entity/Plugin/EntityReferenceSelection/DefaultSelection::buildConfigurationForm() adds the sort direction element only if the sort by element has a non-empty value (not equal to '_none' to be exact). However, if a user sets a value on the sort by element and then unchecks the 'target_bundles' element, the sort by element becomes hidden but the sort direction element remains visible.

Steps to reproduce
Add 1+ bundles to node entity type.
Add entity reference field to one of the node bundles.
Storage settings form: select node (or 'Content')

Expected result
Field settings form:
- check 1+ of the node bundles
- the 'Sort by' select element is shown
- the 'Sort direction' select element is NOT shown

- select item in the 'Sort by' select element
- the 'Sort direction' select element is shown

- uncheck all of the node bundles
- the 'Sort by' select element is NOT shown
- the 'Sort direction' select element is NOT shown

Actual result
Field settings form:
- check 1+ of the node bundles
- the 'Sort by' select element is shown
- the 'Sort direction' select element is NOT shown

- select item in the 'Sort by' select element
- the 'Sort direction' select element is shown

- uncheck all of the node bundles
- the 'Sort by' select element is NOT shown
- the 'Sort direction' select element is shown [the unexpected result]

Proposed resolution

Add a '#states' key to the sort direction element and remove the 'if condition' to its creation.

Remaining tasks

None.

User interface changes

None, except for show-hide elements according to progressive disclosure concept. For screenshots refer to the first referenced issue above.

API changes

None.

Data model changes

None.

Release notes snippet

Not applicable.