Problem/Motivation

There has been some discussion about what the future of migrate is once Drupal 7 marketshare is sufficiently reduced and it no longer makes sense to maintain the Drupal 6/7 migrations in core.

I don’t actually believe that d7 marketshare will be low enough by Drupal 10 to remove the migrate_drupal module, but it will happen eventually. One of the thresholds we’ve used as to whether a feature goes in contrib or in core is whether it directly supports the core mission of providing Drupal 6/7 migrations into drupal 8, so what happens once that system is no longer needed?

Proposed resolution

Discuss the future of migrate in Drupal Core in a post Drupal 7 world

Problem/Motivation

In #2991207: [PP-3] Drupal core should inform the user of the security coverage for the site's installed minor version including final 8.x LTS releases, the status messages explaining the security coverage for the installed versions are kind of wordy. Let's see if we can simplify the wording for better UX.

Proposed resolution

Improve the wording of the messages.

Remaining tasks

• Propose new wordings.
• Ensure that all usecases are covered.
• UX review.

User interface changes

String changes (screenshots needed / see #2991207: [PP-3] Drupal core should inform the user of the security coverage for the site's installed minor version including final 8.x LTS releases for "before" screeenshots).

Message screenshots

Minor 8.2. is supported, no warning. Next minor has not come out.

Before:

After: todo

Minor 8.1 is supported, warning. Next minor 8.2 has come out

Before:

After: todo

Minor 8.0 is unsupported. 8.2 has come out

Before:

After: todo

Minor 8.8 supported based on date, no warning

Before:

After: todo

Minor 8.8 , supported based on date, warning because within 6 months of support being over

Before:

After: todo

Minor 8.8 , not supported based on date,

Before:

After: todo

Minor 8.9 supported based on date, no warning. No warning will show based on nearness of support being over

Before:

After: todo

Minor 8.9, support over

Before:

After: todo

API changes

N/A; string change only

Data model changes

N/A; string change only

Release notes snippet

N/A; string change only

When you are on a node page (for example node/10) and you submit a comment and get a validation error, you are taken to a different url (for example comment/reply/50).

A lot of things rely on the path, and because you are on a node page but the path is comment/reply/[nid] things break.
For example, you no longer have some classes that were based on the path, and themes relying on this class will break.

The BC layer for revision metadata keys has been a source of dozens of lost hours and frustration for Entity API maintainers...

Problem/Motivation

To increase the ease of use and utility of the Field List report (at /admin/resports/fields), we should consider adding a filter to the report. Site administrators can benefit from improvements to the report to help them more quickly locate fields by name, entity type, field type, and usages.

Proposed resolution

Following the pattern in the Views list at /admin/structure/views (part of the Views UI module), implement a filter to the Field LIst report.

Remaining tasks

Create a patch which implements the filter onto the report.

User interface changes

Adds a field which accepts input from the user to filter the report.

API changes

None.

Data model changes

None.

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the filter, ckeditor, editor module(s).

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
   

     switch ($route_name) {
       case 'help.page.contact':
   

   And ends either at the end of the function, or where you find another case 'something': line.

3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
4. See if some of these tasks are already documented in existing topics. Currently, all topics are in core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix).
6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig (and "MODULENAME" can be "core" as discussed above).
7. Make a patch file that adds/updates the Twig templates. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

1. Apply the patch.
2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/help_topics/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
4. Review the topic text that you can see on the page, making sure of the following aspects:
   • The text is written in clear, simple, straightforward language
   • No grammar/punctuation errors
   • Valid HTML -- you can use http://validator.w3.org/ to check
   • Links within the text work
   • Instructions for tasks work
   • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

As you can see from below the H3 tag which is generated from using grouping (@ Format: Unformatted list | Settings:Grouping field) has no divs around it like the regular fields. In my case I would like to wrap some HTML around it but I can't see where. On the fields it's easy, just override the output with what you want but on this generated group title I haven't found how to do this so any help will be much appreciated.

<div class="view-content">
    <h3><a href="/blogs/83" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Internet Department</a></h3>
    <div class="views-row views-row-1 views-row-odd views-row-first views-row-last">
      <div class="views-field views-field-picture">
        <div class="field-content">

Problem/Motivation

When custom content blocks are placed at page by Layout Builder, there are no contextual links on this block. This is about viewing page, not editing. I dug deeper into the problem and noticed, that some of blocks still has contextual links, e.g. views-blocks and blocks with webforms. But custom content blocks (provided by core module 'block_content') hasn't any contextual links when rendered by layout builder. This also applies to some contrib modules, e.g. Config Pages blocks also has no contextual links with Layout Builder, but when I placed {{ title_suffix }} into config-pages.html.twig, contextual links appeared ar config pages blocks.

Also I found out, that contextual links appears only in those modules, that contains some additional or specific logic of contextual links generation.

Proposed resolution

Do something to attach contextual links to blocks, rendered by Layout Builder.

Remaining tasks

TBA

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

\Drupal\Core\Validation\Plugin\Validation\Constraint\EmailConstraint has code to bridge SF3 to SF4 we don't need that in D9 anymore. This issue could also investigate if there was other bridge code added that can be removed.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

You can add routes to a link field by using route:{$route_name}. However, if you save an entity with a link field that has a route and attempt to edit and re-save the node or menu item without changing the route in the link field, the route will fail validation.

Steps to reproduce:
- Build a new Drupal site on 8.9.x
- Go to /admin/structure/menu/manage/main/add
- Add a menu link to the frontpage view using its route. Enter anything for the title. The path should be route:view.frontpage.page_1. Save your link.
- Edit the menu link that you just created. Change the title. Note that the path is now view.frontpage.page_1 instead of route:view.frontpage.page_1. Attempt to save. Note a validation error: Manually entered paths should start with one of the following characters: / ? #

It looks like the code that makes routes fail validation was added to handle display of route:<nolink>:
https://github.com/drupal/drupal/blob/8.9.x/core/modules/link/src/Plugin...

However, route:<nolink> is handled later in the link widget code and other routes are not:
https://github.com/drupal/drupal/blob/8.9.x/core/modules/link/src/Plugin...

Luckily, there is an easy workaround for this bug. Each time you edit an entity with a link field that has a route, simply re-add the route: portion to your link.

Problem/Motivation

A View page created with an exposed filter field which has required input does not consistently display the form validation/required message.

Proposed resolution

When a view page is displayed with a required filter and no value is provided for the filter, display the form validation error message.

Remaining tasks

Create patch to solve.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

None

Original report by [mlncn]

When investigating the original issue created here, this validation message issue was discovered. This issue is now to resolve the error message not consistently displaying.

issue #3076117: In View, Keyword Search filter's "On empty input" setting appears to have no effect. was created in Search issue queue to address the originally-reported problem.

Original issue:

1. Create a content search
2. Add filter criterion Search
3. Checkmark "Expose this filter to visitors, to allow them to change it"
4. For "On empty input", select the radio button "Show None"

Then weep in despair as the view proceeds to show every node on the site whenever no keywords are provided, no matter what you fiddle with.

Problem/Motivation

When Drupal integrated CKEditor 4 into Core it was the best available solution at that moment in time.

Since then the editor landscape has shifted dramatically.

Therefore we - as a Community - need to select a new editor for Drupal 9, so that we can deprecate CKEditor 4.

We (at Tag1) recently did a larger survey of available editors in the space and there is more than just CKEditor 5.

As there is no upgrade path for CKEditor 4 to 5, there is no reason that we need to just update to the next version.

We (at Tag1) published a blog post about our detailed findings soon, which could become a starting document for this issue:

https://tag1consulting.com/blog/modern-rich-text-editors-how-evaluate-ev...

For now we talked about the editors and challenges in integrating them with Drupal 8 here:
https://tag1consulting.com/blog/deep-dive-rich-text-editors-tagteamtalk-002

The list of editors we evaluated are:

- CKEditor 5 (https://ckeditor.com/ckeditor-5/)
- Prosemirror (https://prosemirror.net/) (used by New York Times, Evernote, Atlassian (JIRA, Confluence))
- QuillJS (https://quilljs.com/) (LinkedIn, Slack)
- DraftJS (https://draftjs.org/) (Facebook)
- SlateJS (https://www.slatejs.org/)
- Gutenberg editor (https://www.drupal.org/project/gutenberg)

All of those are using an internal JSON based model (some tree based, some differential based).

All of those support real-time collaborative editing ala Google Docs / Etherpad (except Draft?) in general, which could become more and more important in the future.

Proposed resolution

- Create list of criteria: e.g.

- Audit the DX and UX of the editors (How easy is it to write a plugin? How easy are complex plugins?)
- Audit the Community and Support of the editors (Is it maintained well? Is it a good OSS project?)
- Audit Accessibility
- ...

and find the best solution for what Drupal 9 needs.

Remaining tasks

- Discuss
- Create child issues
- Start implementing and testing

Problem/Motivation

One major piece of functionality from the D7 Entity Reference module was left out entirely in #1801304: Add Entity reference field: the ability to render exposed views filters as a select list or autocomplete of available entities.

Proposed resolution

Create a new Views Entity Reference filter plugin to be available for all entity reference fields and migrate the existing taxonomy filters to be based on the new generic filter plugin.

How to use

1. Add on an entity type / bundle an entity reference field, ex field_test_reference.
2. Create a view displaying this entity type.
3. Add a filter on the view for field_test_reference.
4. Configure the entity selection mode and the widget display mode.
5. Configure the filter behavior (ex: required, multiple, etc.)
6. Finally use the filter field for filtering the results based on the selected entity from the autocomplete or select list.

Remaining tasks

• ☑ support for content entity reference
• ☑ support for configuration entity reference
• ☑ support for content with and without bundles
• ☑ taxonomy filter rebased on generic entity reference
• ☑ settings forms to configure the filter
• ☑ display widget in select or autocomplete
• ☑ filter values based on reference view
• ☑ filter values based on bundles
• ☑ maximum filter values in select list for performance concerns
• ☑ sort for filter values when in bundle selection handler mode
• ☑ argument support for when view selection handler is used
• ☑ views configuration schema update
• ☐ existing configuration migration (no longer needed if we create a new filter only)
• ☐ fix select option (#208, #215)
• ☑ tests
• ☐ get framework manager approval
• ☐ write change record

Post tasks

• ☐ follow-up task to have TaxonomyIndexTid use this entity reference plugin
• ☐ conversion of the "authored by" filter to use the entity reference filter
• ☐ extract selection handler form logic in separate plugins that will specialize for rendering and validating the filter selection config form
• ☐ caching of the value form?
• ☐ documentation updates

User interface

Known issues

• CANNOT REPRODUCE ATM sometimes when switching between widget it gets stuck on the previous selected one
• FIXED when switching between the widget types the previous value is left in the exposed form and it's incompatible with the other widget type
• FIXED triggering ajax requests on the extra options form right after adding the filter brings you back to the add handler form fixed

API changes

None.

Problem/Motivation

REQUEST_TIME constant is marked as deprecated and a time service was added to 8.3.x in #2717207: Add a time service to provide consistent interaction with time()/microtime() and superglobals.
See parent issue #2902895: [meta] replace uses of REQUEST_TIME and time() with time service for full description.
Here is the change record also.

Proposed resolution

All occurrence in code should be updated to remove deprecated uses of REQUEST_TIME, time() and microtime().

Remaining tasks

None

User interface changes

None

API changes

None

Data model changes

None

on line 1077 of the file .module it has this
\Drupal::messenger()->addError(t('The file %source could not be uploaded because a file by that name already exists in the destination %directory.', ['%source' => $form_field_name, '%directory' => $destination]));

it should be this :
\Drupal::messenger()->addError(t('The file %source could not be uploaded because a file by that name already exists in the destination %directory.', ['%source' => $file->getFilename(), '%directory' => $destination]));

if not it does not identify the name of the file correctly

Prerequisite
Install Drupal core on standard profile.

Problem
In View, Keyword Search filter's "On empty input" setting appears to have no effect.
This is discovered in issue https://www.drupal.org/project/drupal/issues/2733293#comment-11260399 by @jhodgdon. I am moving it to a new issue so it can be fixed properly

Steps to reproduce
a) Installed with Standard profile.
b) Created two Basic Page content items, with title/body "My first item" and "My second item".
c) Went to admin/config/system/cron and clicked Run cron (to make sure search index is updated).
c) Created a new view showing Content, with a Page display.
d) Added a filter to the view, added a Search Keywords filter. Chose "On empty input" -> "Show none". [This seems to be specific to just Search filters.] Did not check Required.
e) Cloned the page, and checked Required for the filters.
f) Saved the view.
g) Visit the pages:

1) Search filter / not required. all content is shown, no error message, when I first visit the page. If I enter nothing and click Apply for the filter, still all content is shown.

2) Search filter / required. when I visit the page, the filter field is outlined in red, with no error message. No nodes are shown. If I attempt to submit the form without entering something in the field, I get an error box under the field that says "Please fill out the field".

Expected behavior
The Search filter's "On empty input" setting appears to have no effect. I think this setting is just misleading and should be removed. Empty input is never recognized by Views filters -- the filter won't be invoked at all, as far as I can tell.

Problem/Motivation

Follow-up to #3087644: Remove Drupal 8 updates up to and including 88**.

Blocks Drupal 9 beta.

If we decide to keep the update and re-add tests for it, that will be easiest once #3095333: Extend filled database dump with new stable modules and content for them is in core.

If we decide to remove the update, we may want special messaging for workspaces module following #3098475: Add more strict checking of hook_update_last_removed() and better explanation to explicitly point out that people need to update to 8.8.2 first if they hit this condition.

Proposed resolution

1. Remove the update and post update

2. Add a workspace-specific message in #3098475: Add more strict checking of hook_update_last_removed() and better explanation to inform any workspaces 8.8.0 users trying to go direct to 9.0.0, that they need to update to 8.8.2 or higher first.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

A time service was added to 8.3.x in #2717207: Add a time service to provide consistent interaction with time()/microtime() and superglobals.

Core code should be updated to remove deprecated uses of REQUEST_TIME and time() and others.

For more informations, see the change record.

Problem/Motivation

The link (https://www.drupal.org/modules/help_topics) provided in the help_topics module in hook_help() is not available in drupal.org.

Proposed resolution

Point link to https://www.drupal.org/documentation/modules/help_topics

Remaining tasks

commit

User interface changes

link points to stub page for the module

API changes

no

Data model changes

no

Release notes snippet

n/a

When adding an external link to a menu, dots in query parameter names are converted to underscores, even though dots are allowed in query parameter names. This seems to be because Symfony uses parse_str() to convert parameters to PHP safe variable names. See https://github.com/symfony/symfony/issues/25541

To reproduce:
Spin up a new site
Add an external link to the main menu (https://www.drupal.org?first.name=Aaron&last.name=Wolfe)
The url in the menu linkshould be https://www.drupal.org?first.name=Aaron&last.name=Wolfe
Instead, the menu item links to https://www.drupal.org?first_name=Aaron&last_name=Wolfe

This also happens with redirects, and I imagine any other place that prepares URLs with query strings.