Problem/Motivation

Modules need a way to declare their migration status and give a short description on the Migrate Upgrade review page, /upgrade. The short description can have a link to a documentation page for example for known issues.

The Review form lists all modules on the source site in either a 'will be upgraded' or 'will not be upgraded' list. However, determining which section to add a module too is not robust. If the module has migrations, it will be displayed in the 'will be upgraded' list, even if it only has one migration and needs more than one to be complete. We need a mechanism that can explain this situation in the UI.

The mechanism needs to be flexible to accommodate the many scenarios possible. See #71 and #72 for details.

This work here is to only create and implement such a system, to make the first step, for what is a complicated problem. Changes may be made to the UI but are expected to be minimal. However, a UX review is planned. When that feedback is given it needs to be decided what can be done in this issue and what must be moved to followups.

Note: in #2914974: Migrate UI - handle sources that do not need an upgrade we defined a list of modules that do not need any migrations (e.g. Overlay, Help) or the contrib functionality has moved into core and there is not a D8 core module with the same name. These modules are listed in ReviewForm::$noUpgradePaths

In a migrate meeting, using a hook or an event was discussed. A possible solution, using hook_form_alter, was implemented in #2914974: Migrate UI - handle sources that do not need an upgrade and removed after a review #176. That review asked some questions, listed below, which should be resolved here.

1. The CR is titled Provide a Method to Intentionally Mark Modules, Themes and Profiles as not Upgradable but we're not really providing a method.
2. Did we give consideration to a dedicated API? E.g. we could put entries in .info.yml or we could put .migrate.info.yml files in modules.
3. How likely is it that contrib modules will need to make this change?

Proposed resolution

After framework manager review the status information moved from .info.yml to module.migrate.yml, the format stays the same. And later it moved to migrate_drupal.yml since this is only for drupal sources.
Add the following to migate_drupal.yml to any module providing or needing migrations, include field migrations.

finished:
  6:
    source_module_A: destination_module_A, destination_module_C
    source_module_B: destination_module_B
  7:
    source_module_A: destination_module_A
    source_module_B: destination_module_B
not_finished:
  6:
    source_module_C: destination_module_D, destination_module_E

In 'finished' is a list of all source module/destination module pairs for migrations that are complete in the module. If migrations are found in the module it will be assumed that the migrations are not finished. In 'not_finished' is a list of all the migrations this module intends to provide but either do not exist or are incomplete for any reason. The 'not_finished' is needed when more than one module will have migrations for a source module and at least one of the modules uses the 'finished' key. The 'not_finished' one will ensure that the source module is listed in the 'will not be upgraded' list. Say Module A and Module B provide migrations for Module C. Module A is finished and uses 'finished'. Then, if Module B has no migrations, it needs to use 'not_finished'.

All the logic to determine whether a source module will be upgraded or not is now in a service (See suggestion in #137.9, migrate_drupal.migration_state.

See the full details in #72 and #77

Screen shots

Now, for the screen shots which need some attention. The difference between the before and after is that on the after screenshots the modules in the Drupal 8 column are listed in a single line separated by commas whereas in the before screenshots they are on separate lines. That's all.

But the screens should provide some information or direction to the user on what to do about the modules in the 'will not be upgraded' section. After all, if a module they need is listed here they need a next step right on this page. How best to inform them of what to do? A single help text somewhere on the page or something else? The user also needs support on what to do about the other modules that will not be upgraded. See #87

Also, the idea of allowing modules to add text to the page via a hook, in a possible followup, has been discussed by the team. Any decision here should be aware of that.

To navigate to the Review page you need a D6 or D7 Database Then install Migrate Drupal UI and go to /upgrade.

Before
Full page
Module that will not be upgraded section
Modules that will be upgraded

After
Modules that will not be upgraded section
Modules that will be upgraded section
The checklist referred to is https://www.drupal.org/docs/8/upgrade/upgrade-using-web-browser#pre-upgr...

History

The first proposal which came from a migrate meeting was to add the migrate status of the module and a description string to be displayed on the Review Page to info.yml . This was tweaked a few times. See #7 and #8. See #10. Eventually, the description was removed as to difficult to maintain an html string in .info but the version key remained.

Remaining tasks

• Decide on the format of the new 'migrate' key and values in .info.yml. Suggested formats are in #11 and #15. Those have been abandoned in favor of 'migrations_finished' and 'migrations_not_finished'.
• Decide on the allowed values for status. Suggestions are in #7, #9. Currently proposed values are 'complete', 'incomplete' and 'n/a'. The UI impact with a screenshot is in #28.
• Decide if adding a key for source version is ok.As pointed out in #10, the status needs to be declared by source version.
• Review
• UX Review - See #106 - #11
• Update change record</li>
• Update handbook documentation
• Commit

In Drupal 7, thanks to the implementation of l(), an "active" class was automatically added when generating node listing with views, and when the linked entity's URI was the same as the one listed.

With #1979468: ".active" from linkGenerator(), l() and theme_links() forces an upper limit of per-page caching for all content containing links, this is not the case anymore and it seem's not easily alterable (I can't my way through).

Is there a way to change this behaviour. Are we missing something in core to let us alter that ?

Problem/Motivation

Currently when you have a lot of nodes with the same title, it's hard to distinguish which node you want to link to in the link field autocomplete.

A possible solution is to group the nodes by bundle like the linkit module does for ckeditor: https://www.drupal.org/files/project-images/linkit-drupal-8.png

Problem/Motivation

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Original Report

Core 8.4.3 and Bartik theme. When i open a custom entity form in a modal the date popup calendar opens (in the DOM) but it is not visible inside the modal. If i open the same form outside of the modal, it displays fine.

Anyone seen this issue?

When upgrading from Drupal 8.2.x to 8.3 one of the steps I did was to remove my old settings.php file, copying the new 8.3 version, and copying in my database settings.

When I ran my localhost version I got the error message:

The website encountered an unexpected error. Please try again later.

I didn't have a clue what the problem was, nor where to look. OK, after reading forum posts I eventually found the error in the Apache logs:

[Mon Apr 17 11:51:08.352887 2017] [:error] [pid 11412:tid 1864] [client ::1:55474] Uncaught PHP Exception RuntimeException: "Missing $settings['hash_salt'] in settings.php." at C:\\xampp\\htdocs\\d8lp\\core\\lib\\Drupal\\Core\\Site\\Settings.php line 146

Knowing the error, it was easy to correct.

Wouldn't it be possible to detect this as an expected error which someone could easily make and put out a more user-friendly message to the web browser rather than to the Apache logs?, e.g.

Missing $settings['hash_salt'] in settings.php." at C:\\xampp\\htdocs\\d8lp\\core\\lib\\Drupal\\Core\\Site\\Settings.php line 146

would be nice.

Problem/Motivation

#2842431: [policy] Remove PHP 5.5, 5.6 support in Drupal 8.7 outlined the policy for dropping support for PHP 5.5 and 5.6, but there are some details that were never implemented as part of that issue. This issue aims to resolve those.

Proposed resolution

C&P from @xjm's comment in the original issue:

1. New sites will not be able to install on PHP 5.5 or 5.6.
2. An error will appear on the status report for sites on PHP 5.5 and 5.6.
3. Sites on PHP 5 will still be able to run Drupal updates, but a warning will be presented on the update screen.
4. The 8.8.x branch will not be tested against PHP 5.
5. We will update to PHPUnit 6.
6. If possible, the 8.7.x branch will have one nightly test against PHP 5.6 (with PHPUnit 4).
7. If a commit breaks the 8.7 nightly test on PHP 5.6, it may be reverted, but site owners should expect bugs and fatal errors if they do not update to PHP 7
8. On PHP 5.6 only, the Migrate test suite should be skipped.

Hello,

On a website with content moderation on block contents and with content moderation notifications. I need to send notification to the block content author.

I will upload a patch that add this notion.

Problem/Motivation

Issue split from #2899392: user_hook_toolbar() makes all pages uncacheable.

The shortcut implementation of hook_toolbar has a cache context per user. This causes the Dynamic page cache to stop working, since the cardinality is too high.

Proposed resolution

Implement a lazy builder to add the shortcuts using placeholdering.

Remaining tasks

1. Write a patch
2. Review
3. Commit

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

Unpublished media can not be viewed by owner.

I have just noticed that a Media entity in unpublished state can not be viewed by the owner which is weird. The only exception is when the owner has the "administer media" permission.

Steps to reproduce

1. Create a roll with 'create media' and 'delete own media' and 'update own media' permission
2. Create a user and assign the role created in step 1.
3. Login as the user from step 2
4. Create a media item
5. Try to view the media item

Expected:
See media entity.

Actual:
Access denied.

Proposed resolution

• Allow user with a new 'view own unpublished media' permission to view their unpublished media.

Problem/Motivation

The Entity link field uses the wrong translation of the entity. It always uses the original language which is not always desired.
This applies to both deletion and editing.
You can use the Entity operations field instead but that is not always desired to do so.

To reproduce:

1. I have downloaded latest 8.4.x-dev release
2. I have installed Drupal 8.4 with the Standard profile
3. I have added a new language "Swedish" and then enabled that language for the "Article" content type
4. I have created a new node Article example and then translating it to Swedish Artikel exempel.
5. I have created a new View "Articles" that lists content type articles for both languages
6. I have configured the view to use table format. I add "Link to edit Content" and "Link to delete Content" fields

The exported view:

uuid: b6c259e3-3fbc-46b9-9979-8df90333fff2
langcode: en
status: true
dependencies:
  config:
    - node.type.article
  module:
    - node
    - user
id: articles
label: Articles
module: views
description: ''
tag: ''
base_table: node_field_data
base_field: nid
core: 8.x
display:
  default:
    display_plugin: default
    id: default
    display_title: Master
    position: 0
    display_options:
      access:
        type: perm
        options:
          perm: 'access content'
      cache:
        type: tag
        options: {  }
      query:
        type: views_query
        options:
          disable_sql_rewrite: false
          distinct: false
          replica: false
          query_comment: ''
          query_tags: {  }
      exposed_form:
        type: basic
        options:
          submit_button: Apply
          reset_button: false
          reset_button_label: Reset
          exposed_sorts_label: 'Sort by'
          expose_sort_order: true
          sort_asc_label: Asc
          sort_desc_label: Desc
      pager:
        type: mini
        options:
          items_per_page: 10
          offset: 0
          id: 0
          total_pages: null
          expose:
            items_per_page: false
            items_per_page_label: 'Items per page'
            items_per_page_options: '5, 10, 25, 50'
            items_per_page_options_all: false
            items_per_page_options_all_label: '- All -'
            offset: false
            offset_label: Offset
          tags:
            previous: ‹‹
            next: ››
      style:
        type: table
      row:
        type: fields
      fields:
        title:
          id: title
          table: node_field_data
          field: title
          entity_type: node
          entity_field: title
          alter:
            alter_text: false
            make_link: false
            absolute: false
            trim: false
            word_boundary: false
            ellipsis: false
            strip_tags: false
            html: false
          hide_empty: false
          empty_zero: false
          settings:
            link_to_entity: true
          plugin_id: field
          relationship: none
          group_type: group
          admin_label: ''
          label: Title
          exclude: false
          element_type: ''
          element_class: ''
          element_label_type: ''
          element_label_class: ''
          element_label_colon: true
          element_wrapper_type: ''
          element_wrapper_class: ''
          element_default_classes: true
          empty: ''
          hide_alter_empty: true
          click_sort_column: value
          type: string
          group_column: value
          group_columns: {  }
          group_rows: true
          delta_limit: 0
          delta_offset: 0
          delta_reversed: false
          delta_first_last: false
          multi_type: separator
          separator: ', '
          field_api_classes: false
        edit_node:
          id: edit_node
          table: node
          field: edit_node
          relationship: none
          group_type: group
          admin_label: ''
          label: 'Link to edit Content'
          exclude: false
          alter:
            alter_text: false
            text: ''
            make_link: false
            path: ''
            absolute: false
            external: false
            replace_spaces: false
            path_case: none
            trim_whitespace: false
            alt: ''
            rel: ''
            link_class: ''
            prefix: ''
            suffix: ''
            target: ''
            nl2br: false
            max_length: 0
            word_boundary: true
            ellipsis: true
            more_link: false
            more_link_text: ''
            more_link_path: ''
            strip_tags: false
            trim: false
            preserve_tags: ''
            html: false
          element_type: ''
          element_class: ''
          element_label_type: ''
          element_label_class: ''
          element_label_colon: true
          element_wrapper_type: ''
          element_wrapper_class: ''
          element_default_classes: true
          empty: ''
          hide_empty: false
          empty_zero: false
          hide_alter_empty: true
          text: edit
          entity_type: node
          plugin_id: entity_link_edit
        delete_node:
          id: delete_node
          table: node
          field: delete_node
          relationship: none
          group_type: group
          admin_label: ''
          label: 'Link to delete Content'
          exclude: false
          alter:
            alter_text: false
            text: ''
            make_link: false
            path: ''
            absolute: false
            external: false
            replace_spaces: false
            path_case: none
            trim_whitespace: false
            alt: ''
            rel: ''
            link_class: ''
            prefix: ''
            suffix: ''
            target: ''
            nl2br: false
            max_length: 0
            word_boundary: true
            ellipsis: true
            more_link: false
            more_link_text: ''
            more_link_path: ''
            strip_tags: false
            trim: false
            preserve_tags: ''
            html: false
          element_type: ''
          element_class: ''
          element_label_type: ''
          element_label_class: ''
          element_label_colon: true
          element_wrapper_type: ''
          element_wrapper_class: ''
          element_default_classes: true
          empty: ''
          hide_empty: false
          empty_zero: false
          hide_alter_empty: true
          text: delete
          entity_type: node
          plugin_id: entity_link_delete
      filters:
        status:
          value: '1'
          table: node_field_data
          field: status
          plugin_id: boolean
          entity_type: node
          entity_field: status
          id: status
          expose:
            operator: ''
          group: 1
        type:
          id: type
          table: node_field_data
          field: type
          value:
            article: article
          entity_type: node
          entity_field: type
          plugin_id: bundle
      sorts:
        created:
          id: created
          table: node_field_data
          field: created
          order: DESC
          entity_type: node
          entity_field: created
          plugin_id: date
          relationship: none
          group_type: group
          admin_label: ''
          exposed: false
          expose:
            label: ''
          granularity: second
      title: Articles
      header: {  }
      footer: {  }
      empty: {  }
      relationships: {  }
      arguments: {  }
      display_extenders: {  }
    cache_metadata:
      max-age: 0
      contexts:
        - 'languages:language_content'
        - 'languages:language_interface'
        - url.query_args
        - 'user.node_grants:view'
        - user.permissions
      tags: {  }
  page_1:
    display_plugin: page
    id: page_1
    display_title: Page
    position: 1
    display_options:
      display_extenders: {  }
      path: articles
    cache_metadata:
      max-age: 0
      contexts:
        - 'languages:language_content'
        - 'languages:language_interface'
        - url.query_args
        - 'user.node_grants:view'
        - user.permissions
      tags: {  }

Expected behaviour

When clicking on Edit on the Swedish Article exempel node I should be taken to the Edit form for that translation (Swedish)
When clicking on Delete on the Swedish Article exempel node I should be taken to the Delete form for that translation (Swedish)

Current behaviour

I am taken to the edit form for the english (original translation).
I am taken to delete form to delete both translations.

Proposed solution/idea

Use the EntityTranslationRenderTrait trait to properly render entity row links in the right language.
Add Kernel test for the fields to ensure they work as expected.

Proposed follow ups

Use Rendering language in the view configuration for untranslated entities
Fix translations for \Drupal\comment\Plugin\views\field\EntityLink if needed

Problem/Motivation

From #2983179-16: [META] Implement stricter access checking for the media library:

Secondly, as @marcoscano points out, a permission might be too blunt of an instrument for controlling access to the media library, simply because it can potentially be used in a bunch of different places and in different ways. With a permission, a site builder would need to grant at least two permissions to authors in order to allow them to use the media library at all -- they'd need the "view media" permission, and permission to access the media reference field at all. That's a big fat DrupalWTF that we should do our best to avoid. Instead, we will implement some sort of system, probably based on the event system, to ask the opener (i.e., the field or the WYSIWYG editor in question) to allow or deny access to the media library, based on the parameters in the state object. Since the state object is central to computing access this way, we'll need the tamper-proofing in place first.

Proposed resolution

Implement some sort of system, probably based on the event system, to ask the opener (i.e., the field or the WYSIWYG editor in question) to allow or deny access to the media library, based on the parameters in the state object.

Remaining tasks

Write patch
Review
Commit

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Problem/Motivation

Test Drupal\Tests\user\Functional\UserEntityCallbacksTest doesn't make any HTTP request but is a functional test.

Proposed resolution

• Convert it to a kernel test.
• Rename it as UserEntityLabelCallbackTest.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A

Problem/Motivation

UserMailNotifyTest is Kernel test but for some reason wrongly lives under Functional tests namespace.

Proposed resolution

Move UserMailNotifyTest under Kernel tests namespace.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A

Problem/Motivation

Convert the schema.inc functions to a service so it can be injected, unit tested and swapped. Affected functions:

• drupal_get_schema_versions()
• drupal_get_module_schema()
• drupal_schema_get_field_value()

The following functions should fall into the scope of extension services and should be moved in #2908886: Split off SchemaInstaller from schema.inc

• drupal_get_installed_schema_version()
• drupal_set_installed_schema_version()
• drupal_install_schema()
• drupal_uninstall_schema()
• _drupal_schema_initialize()

Already removed in https://www.drupal.org/node/2467521

• drupal_get_schema()
• drupal_get_complete_schema()
• drupal_get_schema_unprocessed()

Proposed resolution

Create a schema service with methods that replace the mentioned functions in schema.inc.

Remaining tasks

Deprecate the functions changed by this issue. https://www.drupal.org/core/deprecation#how-function

Move the extension-related functions into extension services. Follow-up or find child issue here: #2186491: [meta] D8 Extension System: Discovery/Listing/Info

User interface changes

None

API changes

New Schema service with the following methods:

• get
• getComplete
• getVersions
• getInstalledVersion
• setInstalledVersion
• install
• uninstall
• getUnprocessed
• getFieldsSqlgetFieldValue

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

These function need to be moved into an extension module service/helper

drupal_get_installed_schema_version()
drupal_set_installed_schema_version()
drupal_install_schema()
drupal_uninstall_schema()

drupal_get_module_schema()

ToDo:

1. Convert functions
2. Add deprecation messages
3. Replace usage in the core
4. Add legacy tests
5. Update CR

Problem/Motivation

We have \Drupal\node\ContextProvider\NodeRouteContext that can be used in ConditionPlugin(for example).
But we haven't analogs to another entities. Taxonomy term is very essential page/route and this Context can be useful for Drupal DX.

Proposed resolution

Provide new service in taxonomy module.

Remaining tasks

1. Write code
2. Write tests

User interface changes

No.

API changes

New service.

Data model changes

No.

Ignore, testing issue.

Problem/Motivation

Umami has some great ALT for the image content. But I found one image where the ALT text isn't very informative.

See this article: "The real deal for supermarket savvy shopping'

Image alt text: "Products presented on supermarket shelving."

What a sighted user sees: Vegetables. Bags of green leafy salad stuff.

What a blind user is told: "Products".

What kind of products? No idea. It could be in the shampoo aisle, for all we know. Or disposable nappies.

Proposed resolution

Improve the alt text. Say it's the salad stuff, or convey it's the greengrocer's aisle at least.

Remaining tasks

1. Decide what ALT text would be better
2. Write patch for the default content CSV

Followup #2999721: [META] Deprecate the legacy include files

Problem/Motivation

Deprecate legacy errors.inc file functions.

Proposed resolution

Convert all error handler related functions to the methods in the Error class.

Remaining tasks

• Deprecate functions
• Replace usages in the code
• Add legacy tests

User interface changes

-

API changes

• new methods in \Drupal\Core\Utility\Error class
• deprecated error handler related functions

Data model changes

-

Release notes snippet

-

Problem/Motivation

UserDataTest makes no HTTP requests but is a functional test

Proposed resolution

Convert UserDataTest into a Kernel test

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A