Problem/Motivation

We need to build an upgrade path for Drupal 7 to Drupal 8. This issue is for the D7 to D8 migrations which are not multilingual. The multilingual migrations are in #2208401: [META] Remaining multilingual migration paths.

This issue is to track progress of the Drupa7 to Drupal 8/9 migration. All the top, medium and low priority issues are now complete and removed from this issue summary. See the Remaining tasks for the remaining work.

The work on these migration originally took place in the sandbox repository and its issues. Many thanks to everyone who contributed to the work there.

Proposed Resolution

The Migrate API, and the Drupal 6 upgrade path, are stable enough start getting an upgrade path from Drupal 7 into core.

I propose we do this by module. Modules are a clean, understandable way of separating functionality, and I think they'd be a sensible way to group related migrations. There can be a separate issue for each core module that needs an upgrade path.

Remaining tasks

Other

• #2925899: MigrateUpgradeImportBatch does not use source_private_file_path & source_base_path correctly, making it impossible to have public & private files in separate locations
• #2814953: Migrate Drupal 7 node/user reference fields
• #3051252: Plugins file_mfw and image_miw not migrated
• #3005969: Add support for migrate d7 telephone field

API changes

API changes were handled in individual issues.

Problem/Motivation

On multilingual site, cannot save same alias for two content that with different language.

I found two steps to alias processing: CHECK and SAVE.

If i save two content at same language url, the CHECK processing will use same language.

But at SAVE processing, it will use correct language.

Steps to reproduce

1. Add English and Japanese languages on site.
2. Allow language alterable for Basic page.
3. Set url prefix '/en' for English, url prefix '/jp' for Japanese.
4. At '/en/node/add/page', put alias '/demo', select language to English, save success.
5. Then continue at '/en/node/add/page', put alias '/demo', select language to Japanese,
save show error 'The alias /demo is already in use in this language.'

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Discovered an issue in Claro (in Drupal 9.1) when you try to resize a dialog.
The dialog would disappear.
I also tested this on 8.9.10 and there the problem seems not to exist.

Steps to reproduce

1. Go to admin/structure/block/manage/claro_page_title
2. Click on "Browse available tokens."
3. Try to resize dialog

Note: When I override

core/drupal.dialog:
   - claro/claro.drupal.dialog

with

core/drupal.dialog:
    - seven/seven.drupal.dialog

the problem is solved. So needs to happen somewhere in the claro.drupal.dialog

Proposed resolution

Fix dialog resizing in Claro

Remaining tasks

Find & fix bug

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Normal workflow in HEAD without pending revisions:

1. Create a page
2. Open the edit page
3. Open another edit page in another tab to simulate a concurrent edit
4. Change the title and save a new revision
5. Now in the other tab without refreshing the page change the title again and save a new revision
6. Verify a validation error is displayed

Steps to reproduce with Content Moderation in HEAD:

1. Enable the Content Moderation module
2. Enable the Editorial workflow for articles
3. Create an article and save it as draft
4. Open the edit page
5. Open another edit page in another tab to simulate a concurrent edit
6. Change the title and save a draft
7. Now in the other tab without refreshing the page change the title again and save as draft
8. Verify a validation error is displayed
9. Create another article and save it as published
10. Open the edit page
11. Open another edit page in another tab to simulate a concurrent edit
12. Change the title and save a draft
13. Now in the other tab without refreshing the page change the title again and save as draft

Expected result: a validation error is displayed.
Actual result: the second draft "overrides" the first one, although both revisions are correctly stored, so there is no actual data loss.

Proposed resolution

Keep track of the entity revision at the moment the form is built and verify the latest revision matches it when saving the entity via a dedicated constraint validator.

The ultimate goal for this issue is to bring consistency in the entity validation logic when it comes to pending revisions. This solution assumes sequential creation is the default intended behavior for pending revisions, at least for Content Moderation.

Remaining tasks

• Fix the blocking issue: #2926483: Add API methods for determining whether an entity object is the latest (translation-affecting) revision
• Validate the proposed solution
• Update the latest patch
• Reviews

User interface changes

None

API changes

Only additions

Data model changes

None

Hi Team,
Drupal 9.1.2 release notes summary upgrade to Drupal 8.9.12 link will be redirect to 8.9.11. find the attachment below.

https://www.drupal.org/project/drupal/releases/9.1.2

Problem/Motivation

Sometime around Drupal 7, we decided we should not use the word "node" in the UI. It is on our UI text guidelines page:
https://www.drupal.org/docs/develop/user-interface-standards/interface-text
We should be using the terms "content item" and "content type", not "node" or "node type".

However, if you go to localize.drupal.org and search for strings in Drupal core containing "node", you will find about 5 pages of results.

Steps to reproduce

Proposed resolution

Fix all the strings in the UI containing "node" to use the correct terminology.

Remaining tasks

Patch.

User interface changes

We won't be using the very confusing word "node" in core UI text.

API changes

No.

Data model changes

No.

Release notes snippet

No.

Problem/Motivation

Right now there is nothing that tracks what the latest revision ID is for an entity. You can figure this out by querying for and joining the revision table against max(revision_id), but this is far from ideal and doesn't translate into a very useable solution for other subsystems such as content_moderation, views and entity queries.

With the workflow initiative in full swing, the latest revision is becoming a more important concept and as such entity API should become more aware of it.

Proposed resolution

• Add the latest revision ID to the entity data table to enable further work in this area for other subsystems.
• Ensure latest_revision is tracked on the data table to possibly support different languages having different latest revisions in the future.

Follow ups:

#2864995: Allow entity query to query the latest revision
#2865579: Rewrite the 'Latest revision' views filter and remove the revision_tracker table

Remaining tasks

Agree, patch, test, etc.

User interface changes

None.

API changes

Additions only.

Data model changes

Additions only, an additional column on entity tables for revisionable entity types.

Problem/Motivation

In #3167880: [meta] Convert assertions involving use of xpath to WebAssert, where possible we identified that use of $this->xpath() can be dangerous as we aren't always testing what we expect to test. In WebAssert we have more appropriate methods to find and assert HTML elements, so we should use them where possible.

This issue is scoped to find XPath selectors for <select> and <option> and convert those where possible.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

I add some fields to the users profile and want to fill them with content for user 1. But after saving the profile the fields remain empty.

Steps to reproduce

Add some fields to user's profile and fill in some content for user 1. Press save. Check the profile view.

Proposed resolution

For other users than user 1 the fields do what they should. Only user 1 is affected.

Problem/Motivation

I am trying to migrate drupal 7.56 to 8.4.2 using migrate_drupal and migrate_drupal_ui web interface.
The instructions for file path seems to be misleading.

It is asking to enter "Public file directory" and "Private file directory". The variables seems to be interchanged i.e., the Public_file_path value is being used for importing private files. with this, Private files are getting imported.
Public file path is becoming "private_file_path/sites/default/files..." and public file import is being failed.

If both the values are entered, i.e., public_file_directory for public and private_file_directory for private, the values are becoming "file://public_file_path///private_file_path".

Proposed resolution

Change the ReviewForm so that both the source_base_path and the source_private_path are added to the batch configuration.

Then in MigrateUpgradeImportBatch, for all file migrations, set the source_base_path constant of the source plugin. Use the scheme property of the source plugin, $definition['source']['scheme'], to select the public or private base path entered by the user on the CredentialForm.

Add a new functional test, FilePathTest, to confirm the proposed resolution truly works.

Remaining tasks

• Change record
• Release notes snippet

User interface changes

N/A

API changes

Data model changes

Release notes snippet

When Drupal 7-to-Drupal migrations are run through the user interface, the 'Private file directory' is now used correctly as the base source path for the private files.

Problem/Motivation

File validation is omitted by uploading file with "php|pl|py|cgi|asp|js", extensions. For example, a form with file field where allowed extensions is set to "doc xlsx", you would assume no other file type can be uploaded. But a user can upload all files with ""php|pl|py|cgi|asp|js" extensions.

This happens because in _file_save_upload_single() files with those dangerous extensions are renamed to have the .txt extension and .txt is added to the list of allowed extensions. This behaviour is surprising when "txt" has been specifically omitted from the list of allowed extensions.

Proposed resolution

Change logic to only rename if .txt is an allowed extension. If txt is not an allowed extension do not allow the file to be uploaded.

Remaining tasks

1. UX review.
2. Final code reviews/RTBC.
3. Commit.

User interface changes

1. Do not allow uploads of files with dangerous file extensions if txt is not an allowed extension. In this case, end-users would see:

The file %filename could not be uploaded because the extension is insecure.

If txt is an allowed extension, end-users would continue to see (as they have for years):

For security reasons, your upload has been renamed to %filename.

2. Changes to the file field settings page when configuring allowed extensions to detect if "insecure" extensions are being allowed without .txt and throwing an error message about it. This is the "This is mandated when configuring file field through the user interface." part of the release note snippet below. In this case, site builder admins would see:

The extension %extension is insecure. In order to allow files with this extension to be uploaded add the %txt_extension extension as well.

(where %txt_extension is an untranslatable "txt").

API changes

None

Data model changes

None

Release notes snippet

If you limit allowed extensions and want dangerous files to be uploaded and renamed you must explicitly allow txt file upload. This is mandated when configuring file field through the user interface.

Problem/Motivation

I've created a view with an exposed filter in drupal 9.1.2 with the path "/products"
The exposed block is added to the sidebar.

When i go to the the page "www.mydomein.com/products" and i use the exposed filter from the sidebar block, everything works fine, the path is:

www.mydomain.com/products?filter=test

But when i go to the homepage and then use the exposed filter, the path "/products" is not added to the path of the filter, so the path is:

www.mydomain.com/?filter=test

With ofcourse no results from the view.

Steps to reproduce

Install Drupal 9.1.2, make a view that lists al the pages, make an exposed filter for example "title", put the exposed block in de sidebar, go to the homepage and search for some page. The view is not working in the website, only on the views path.

Proposed resolution

The path of the view is added to the path of the filter.

Problem/Motivation

When CSS aggregation is enabled and SVG is imported in css with a fragment URL i.e. # or %23 eg: background: url(#SVGID_1_);

Here, url(#SVGID_1_) gets converted to url(http://domain.com/path/path/#SVGID_1_1) resulting in a broken SVG.

Steps to reproduce

Enable CSS aggregation from /admin/config/development/performance

Use an SVG with a fragment URL. eg: background: url(#SVGID_1_);

Proposed resolution

Ignore fragment URL when building and returning the path of the aggregated stylesheets.

Remaining tasks

Review

Commit

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

None

Extra space is there after header in mobile view , I have added screenshots for the reference.
You can go to /admin/content or /structure/types/manage/article/fields to reproduce this issue

Before patch:

After patch in #31:

Problem/motivation

Currently there is a overflow/scrollbar for the entire page, if the page is viewed on a mobile device and the page contains a table. Even with the responsive tables feature.

Proposal

Instead of hiding columns, display all columns and introduce a mobile-friendly horizontal scroll on large tables.

Currently discussing if we should let claro override the responsive table feature with this new behavior, or introduce a dedicated #scrollable property to all tables to trigger this behavior when necessary. So one could have a responsive table that scrolls if too large.

Problem/Motivation

As a site builder, I would like to remove options from the UI so users are discouraged from using them, while avoiding the "Allowed values list: some values are being removed while currently in use." or "A list field with existing data cannot have its keys changed." errors.

Steps to reproduce

Add a field with options
Add a node that uses the field and an option
Try to remove the option from the allowed values list in the field

Proposed resolution

Allow options values to be deprecated so they can still be used but are no longer visible in the UI (unless currently selected?)

Remaining tasks

Decide if this is a good idea.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In order to add new media items to a node via media library users are always able to see and use existing media items. If we want to let unprivileged users add media items without them being able to see and use other existing media, we're out of luck.

Steps to reproduce

What I tried

1. Select media library as field widget
2. As user without "View media" permission add media item to field
3. See ajax/log error (below) "The 'view media' permission is required." with the "Add files" dialog does not proceed to save the file

Technically of course I would want that the media library only shows the just uploaded file instead of disallowing access altogether.

Proposed resolution

Not sure. Either allow adding media items without having access to the media library or add another permission check for seeing media library items.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Error from steps to reproduce step 3

Path: /en/media-library?media_library_opener_id=media_library.opener.field_widget&media_library_allowed_types%5Bmedia_image%5D=media_image&media_library_selected_type=media_image&media_library_remaining=-1&media_library_opener_parameters%5Bfield_widget_id%5D=field_h4c_multi_media&media_library_opener_parameters%5Bentity_type_id%5D=node&media_library_opener_parameters%5Bbundle%5D=organisation&media_library_opener_parameters%5Bfield_name%5D=field_h4c_multi_media&media_library_opener_parameters%5Bentity_id%5D=185&hash=0eMIP6B1oA59Q_f4yxfAnvuUThTiR47MpEn8BpARoDY&ajax_form=1&_wrapper_format=drupal_ajax. Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException: The 'view media' permission is required. in Drupal\Core\Routing\AccessAwareRouter->checkAccess() (line 120 of /var/www/html/web/core/lib/Drupal/Core/Routing/AccessAwareRouter.php).

Problem/Motivation

Currently importing of .po files for projects could take unacceptable about of time.

Proposed resolution

I have found that problem related to implementation of locale_translation_status_save();
This could be solved by this changes:

 function locale_translation_status_save($project, $langcode, $type, $data) {
   // Load the translation status or build it if not already available.
   module_load_include('translation.inc', 'locale');
-  $status = locale_translation_get_status();
+  $status = locale_translation_get_status([$project]);
   if (empty($status)) {
     $projects = locale_translation_get_projects([$project]);
     if (isset($projects[$project])) {

Remaining tasks

Don't see for now.

User interface changes

No changes

API changes

Data model changes

Release notes snippet

I'd like to request new core functionality to allow site administrator the ability to grant users of certain roles access to another users email address.

Currently access to a user email addresses is restricted to Admin accounts only. IE if a users email address is output in a view it will not show for users other than Admins.

Example for a use case is an Intranet, were one user may want to contact another user via an email link.

It seems like the migrate_lookup migration process plugin doesn't correctly handle D7 entityreference fields that point to nodes.

I have a D7 site with a "location" field that allows values from one of two different other content types, "location" and "room". The mapping is set up like this:

  field_location:
    plugin: migration_lookup
    migration:
      - mysite_node_location
      - mysite_node_room
    source: field_location

However, when it processes that field it logs this error:

Extra unknown items for map migrate_map_mysite_node_room in source IDs: array ( 'target_id' => '123', )

I searched the migrate_map_mysite_node_room table and it has a record with sourceid1 of 123, and that has a destid1 value which is the ID of a node in the site which loads & works correctly.

The problem is that in Drupal\migrate\Plugin\migrate\id_map\Sql::lookupDestinationIds() it doesn't match it, so logs the above error. When it gets to that point if you look at $this->sourceIdFields() it just has this:

array(
  'nid' => 'sourceid1',
)

Note that it shows "nid" as the key it is looking for in the source array, not "target_id".