We are running our Drupal on Postgres and have a view with 2 relations (joines tables). The Preview SQL is attached below.
Due to the table names and field names, Views2 is generating a field alias, which is longer than 63 chars. In the SQL below, it's the alias "node_node_data_field_parent_node_node_data_field_pbcontent_year_field_pbcontent_year_value", causing Postgres not to throw an error, but truncation the name in the resultset. Postgres will only return "node_node_data_field_parent_node_node_data_field_pbcontent_year" as the column name in the resultset, which causes Views2 to break, as there is no data in the expected field "node_node_data_field_parent_node_node_data_field_pbcontent_year_field_pbcontent_year_value".

SELECT node_node_data_field_parent_node_node_data_field_pbcontent_year.field_pbcontent_year_value AS node_node_data_field_parent_node_node_data_field_pbcontent_year_field_pbcontent_year_value,
   COUNT(DISTINCT(node.nid)) AS num_records
 FROM node node 
 LEFT JOIN content_type_video node_data_field_video_gallery ON node.vid = node_data_field_video_gallery.vid
 INNER JOIN node node_node_data_field_video_gallery ON node_data_field_video_gallery.field_video_gallery_nid = node_node_data_field_video_gallery.nid
 LEFT JOIN content_type_video_gallery node_node_data_field_video_gallery_node_data_field_parent_node ON node_node_data_field_video_gallery.vid = node_node_data_field_video_gallery_node_data_field_parent_node.vid
 INNER JOIN node node_node_data_field_parent_node ON node_node_data_field_video_gallery_node_data_field_parent_node.field_parent_node_nid = node_node_data_field_parent_node.nid
 LEFT JOIN content_type_pbcontent node_node_data_field_parent_node_node_data_field_pbcontent_year ON node_node_data_field_parent_node.vid = node_node_data_field_parent_node_node_data_field_pbcontent_year.vid
 WHERE (node.status <> 0) AND (node.type in ('video'))
 GROUP BY node_node_data_field_parent_node_node_data_field_pbcontent_year_field_pbcontent_year_value
  ORDER BY node_node_data_field_parent_node_node_data_field_pbcontent_year_field_pbcontent_year_value DESC

Could anyone provide me with a workaround? Renaming the base fields and thus getting an shorter alias for the column name would work, but is not an option at the moment.
I tried to rewrite the SQL with hook_views_query_alter(), replacing all aliases in $query->fields with an generic one, if the alias is longer than 63 chars. The query then runs fine, but Views2 continues to search for the long columnames in the resultset. Any way I can tell Views2 that it shouldn't expect the data in field "node_node_data_field_parent_node_node_data_field_pbcontent_year_field_pbcontent_year_value" but for example in "generic_1"?

I have created a View in Table format of a custom content type, displayed as a Page, and I've exposed the Search filter to allow keyword searching. The first unexpected thing about it is the filter displays on the page without my having to go to Place Block on the Blocks admin page. The other, more serious issue, is that when I perform a keyword search I get a "The website has encountered an error. Please try again later" error page. This error gets logged:

Uncaught PHP Exception Drupal\\Core\\Database\\DatabaseExceptionWrapper: "Exception in Database listing[database_listing]: SQLSTATE[42000]: Syntax error or access violation: 1055 Expression #1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column 'library.node__field_resource_title.field_resource_title_value' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by: SELECT node_field_data.langcode AS node_field_data_langcode, node_field_data.nid AS nid, SUM(node_search_index.score * search_total.count) AS score, MIN(node_field_data.nid) AS nid_1\nFROM \n{node_field_data} node_field_data\nLEFT JOIN {search_index} node_search_index ON node_field_data.nid = node_search_index.sid AND (node_search_index.type = 'node_search' AND node_search_index.langcode = node_field_data.langcode)\nLEFT JOIN {search_total} search_total ON node_search_index.word = search_total.word\nINNER JOIN {search_dataset} node_search_dataset ON node_search_index.sid = node_search_dataset.sid AND (node_search_index.type = node_search_dataset.type AND node_search_index.langcode = node_search_dataset.langcode)\nLEFT JOIN {node__field_resource_title} node__field_resource_title ON node_field_data.nid = node__field_resource_title.entity_id AND node__field_resource_title.deleted = :views_join_condition_0\nWHERE (node_field_data.status = :db_condition_placeholder_1) AND (node_field_data.type IN (:db_condition_placeholder_2)) AND ((node_search_index.type = :db_condition_placeholder_3) AND (node_search_dataset.data LIKE :db_condition_placeholder_4 ESCAPE '\\\\') AND (node_search_index.word = :db_condition_placeholder_5))\nGROUP BY node_search_index.sid, node_field_data_langcode, node_field_data.nid\nHAVING (COUNT(*) >= :node_search_index_keys)\nORDER BY node__field_resource_title.field_resource_title_value ASC; Array\n(\n [:db_condition_placeholder_1] => 1\n [:db_condition_placeholder_2] => databases\n [:db_condition_placeholder_3] => node_search\n [:db_condition_placeholder_4] => % archival %\n [:db_condition_placeholder_5] => archival\n [:node_search_index_keys] => 1\n [:views_join_condition_0] => 0\n)\n" at [webroot]/core/modules/views/src/Plugin/views/query/Sql.php line 1489, referer: my-page-URL

I'm not certain this has been reported elsewhere; apologies if I've duplicated another issue.

Problem/Motivation

#2381277: Make Views use render caching and remove Views' own "output caching" replaces output caching with render caching.
Render caching though is disabled on POST requests, so that ajax requests aren't cacheable.

We need to get #956186: Allow AJAX to use GET requests in, to be able to get render caching done.

Proposed resolution

- Add setting for query type to views pagers
- Make views pager respect that setting so that it uses the correct protocol
- Get render caching to work on views AJAX paging responses

Remaining tasks

- Fix broken tests on 8.3 re-roll.
- Get #956186: Allow AJAX to use GET requests committed
- Verify that we have enough test coverage on this issue
- QA testing to get to RBTC

User interface changes

I added a "pager query type" selector to sql-base pagers which becomes active if you set the view to use AJAX.

API changes

- Added a "getParam" method to ViewAjaxController to make it easier to get parameters off of a request.

How to test

- Install a new site
- Apply most recent patch from this issue (currently: https://www.drupal.org/files/issues/2500313--views-get-paging-support-83...)
- Apply https://www.drupal.org/files/issues/ajax-956186-65_2x_1.patch from #956186: Allow AJAX to use GET requests
- Create at least five articles
- Create two views as follows

View 1
- Add a block display
- Call it "GET pager view"
- List all nodes
- Turn on AJAX for the view
- Use a pager (try them all if you can); 2 per page, set query type to GET

View 2
Same as View 1, except:
- Call it "POST pager view"
- Set query type on the pager settings to POST

Now:
- Place both blocks somewhere on the page
- Start using the pager, and use the network tab (helpful to filter by XHR) to ensure that the views are using the correct protocol for their requests.

Some other things to try:
- Using a table display, ensure that column sorting is respected after paging back and forth.
- Add an exposed filter and make sure paging works after the setting the filter value.
- Test the render caching somehow. Make sure page cache is turned on, and put a breakpoint or something inside a function that runs when rendering a row. The breakpoint should hit a) when the cache is first populated and b) if something invalidates the cache (i.e. that node is updated).

Problem/Motivation

The CKEditor Accessibility Checker, formerly a proprietary plugin, has been released under the GPL.

Proposed resolution

This is a great time to look at bringing this accessibility checker in. Ideally it would be enabled by default in the Standard installation profile. This should help make content editors make their content better.

Remaining tasks

• add Quail.js library to core (MIT license, maintainer is jessebeach).
• add balloonpanel plugin to Drupal's custom CKEditor build.
• add a11ychecker plugin to Drupal's custom CKEditor build.
• add a11ychecker configuration options to Drupal\ckeditor\Plugin\CKEditorPlugin\Internal.
• Write tests

User interface changes

Makes a new CKEditor plugin available - see demo video
Adds options relating to this plugin, for the text format configuration form.

API changes

None expected.

Data model changes

None expected.

Problem/Motivation

As part of phase 2 of #2940731: Automatic Updates Initiative overview and roadmap we need Readiness Checks for automatic updates.

These checks would ensure that a site is ready to have automatic updates applied.

The Automatic Updates contrib module has a readiness check system built on tagged services.

These Readiness checks are particular to the process of Automatic Updates in the contrib module and should also work for the proposed Composer based updates for Drupal core.

Because Drupal core will introduce the Automatic Updates in an experimental module and Readiness Checks will be checking for this yet to be implemented functionality it does not make sense to add the Readiness Checks directly to the existing Update module. For more info on this see this comment on the roadmap issue.

Proposed resolution

Add the Readiness check infrastructure and 1 Readiness Check service from the contrib module to a new experimental module.

Remaining tasks

1. Improve UX when a checker has many, many messages. The contrib module has checkers that produce many messages, like a message for every file that has changed. We may want to only display summary message like "Your site has files changed which may affect auto-updates" on the report page and the admin pages. The have detailed page with the checkers organized with all there messages seperated.

   There also the problem where there is not a way to tell which messages come from which checkers

2. Port initial functionality from the contrib module
3. Determine what changes should be made from the contrib code
4. Ensure that modules that have new Readiness Checkers trigger a recheck.
5. Determine minimum space needed now that we will be using composer. Using 100 MB for now. Follow up #3166416: Determine how many megabytes of free disk space should required for automatic updates using Composer
6. Determine if a larger minimum disk space value could ever cause random failures on Drupal CI. Right now this not happening with the contrib module but it only uses 10mb. If we change this to something like 200mb would this ever fail in DrupalCi and cause a test failure? Confirmed with @mixologic this won't be a problem
7. Use Batch API for running checks for scaling. Do we actually need this? Currently all the contrib checks can take a little as 200 msec
8. Ensure that \Drupal\auto_updates\ReadinessChecker\ReadinessCheckerManager::run() does not throw an exception if it is run for a category that has no checkers or ensure it does not run in this case. Services can be altered so we don't know for sure what the existing checkers will be or which category they will be in. No longer applies
9. Determine if a single checker should be able provide both warnings and messages
10. Change free space checker to factor in that root/vendor/tmp may all be on same are partition or all on different partition.
11. Create a kernel test for ReadinessCheckerManager that test deleting the key/value results works as expected, refreshing, providing checker services dynamically
12. Review

Questions

1. What value should we use for \Drupal\automatic_updates\ReadinessChecker\DiskSpace::MINIMUM_DISK_SPACE?
   10mb was used for the contrib module but that was with patch workflow. Now that we will use composer it will probably be different.
   Using 1 GB follow to confirm #3166416: Determine how many megabytes of free disk space should required for automatic updates using Composer
2. Currently each "checker" tagged service has a "category" tag. This means they can only have messages in 1 category. Should they instead be able to return message in either category?

   For instance the DiskSpace check might return an "error" message "Your disk space is too low" and a "warning" message "Your free disk space is nearing the limit for automatic updates".

Fixes/Questions for the contrib module

1. the way the FileSystemBase is written if produces and error all checkers that extend it will return the same messages.

User interface changes

There will be message on the Status Report page that tells you if your site is ready for Automatic Updates

API changes

TBD

Data model changes

None

Release notes snippet

TBD

Problem/Motivation

Many platforms and development environments use Basic Auth configured on the server to provide a Site Lock. This allows making sites available to select people via the public web without exposing the site to the public in general. For example, https://pantheon.io/docs/lock-environment/.

This might manifest if you are not thinking about it as though the user/login form itself is throwing an access denied, or on further investigation and confirmation of permissions that all pages are mysteriously throwing an access denied.

Per http://drupal.stackexchange.com/a/212800/394 and an examination of the Basic Auth provider code, what's happening is that if you use Basic Auth headers, PHP will pick them up and the Basic Auth module in core will be "triggered' to attempt authentication with those credentials. If it fails, the response will be redirected to access denied. After all, a login attempt just failed.

The frustration level this issue can cause makes it a major DX issue when the stars align, and while I marked it as a bug, you could argue it's a support request.

Proposed resolution

This issue is complicated because it could be considered a feature, not a bug. However, there is a common expectation that a "site lock" can be configured without regard for the application configuration.

One solution could be a simple configuration option that allows checking to see if the user account does not exist, and if not treat it as an anonymous request.

Another possibility would be supporting the Drupal site issuing Basic Auth challenges, allowing the site itself to provide the "lock UI".

Remaining tasks

Decide if this is a problem that should be solved. If not solved, this becomes a documentation problem to explain what's going on and recommended workarounds.

User interface changes

?

API changes

?

Data model changes

?

Problem/Motivation

I am trying to set some custom values on the form_state storage.
Looks like the data is loaded twice and then it uses the storage.
Even though I have a check on the stored value.

Is this by design or it is some kind of bug?

Steps to reproduce

<?php

namespace Drupal\test_module\Form;

use Drupal\Core\Form\FormBase;
use Drupal\Core\Form\FormStateInterface;

class TestForm extends FormBase {

  public function getFormId() {
    return 'test_form';
  }

  public function buildForm(array $form, FormStateInterface $form_state) {
    $form['#prefix'] = '<div id="my-test-form">';
    $form['#suffix'] = '</div>';

    if (!$form_state->has('some_value')) {
      // This code runs twice, it should run once and then use the stored value.
      $form_state->set('some_value', microtime(TRUE));
    }

    $form['debug'] = [
      '#markup' => $form_state->get('some_value'),
      '#prefix' => '<pre>',
      '#suffix' => '</pre>',
    ];

    $form['submit'] = [
      '#type' => 'submit',
      '#value' => t('Submit'),
      '#ajax' => [
        'wrapper' => 'my-test-form',
        'callback' => '::ajaxSubmit',
      ],
    ];

    return $form;
  }

  public function ajaxSubmit(array &$form, FormStateInterface $form_state) {
    return $form;
  }

  public function validateForm(array &$form, FormStateInterface $form_state) {
    $form_state->setRebuild();
  }

  public function submitForm(array &$form, FormStateInterface $form_state) {
  }

}

Proposed resolution

The stored value should be loaded from form_state.
Instead of loading it from scratch again.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Steps required
Create view with display format table add fields.

Expecting behavior
Responsive to tab and mobile

Instead
Going out of the screen.

Please review the attachment which i provided.

Thanks!

Problem/Motivation

When there is an attempt to serialize one of the migration SQL source plugins, we have the following exception:

The database connection is not serializable. This probably means you are serializing an object that has an indirect reference to the database connection. Adjust your code so that is not necessary...

As a result, in the PHPUnit output, we can see this exception instead of the original issue, that caused a test to fail. Here is an example of such failed test: https://www.drupal.org/pift-ci-job/1913812

Before #3129002: Replace usages of deprecated AssertLegacyTrait::assert() was committed the migrate exception message was displayed. See #6

Steps to reproduce

1) Open any SQL source plugin and change something to have an exception;
2) Run appropriate test;

For example,
1) Open core/modules/file/src/Plugin/migrate/source/d7/File.php file and change source_module = "file" to source_module = "file_foo"
2) Run the following test:
exec ./vendor/bin/phpunit core/modules/file/tests/src/Kernel/Migrate/d7/MigrateFileTest.php

Proposed resolution

Remove database connection from the list of serialized properties.

If you are using a private file system and give a image field a default image it will not display (gives the red X) on nodes where no image was uploaded. Since in my case I don't care if the default image is public I've gone into the database and manually changed the file to public, which makes it display.

Problem/Motivation

In #2664830-179: Add search capability to help topics, we discovered that right after standard install, subsequent cron runs were only every 3 hours. So if right after first inttalling Drupal, you then installed the Help Topics (experimental for now) module, it would be 3 hours before the next cron run. It might also take several cron runs until all the topics were indexed for searching, and in the meantime, you'd have a search box but no (or reduced) search results.

Further notes and details on this problem (from comment #23):

1. With core search functionality, if someone enables the Search module + Node [or in our case, Help Topics + Search], they might expect to see search results immediately. However, until they run cron, they won't see any search results. This problem predates Help Topics [by a decade or more].
2. It may take several cron runs to index all the Help Topics (or Nodes for that matter). While that is happening, you may get some results but not all expected results in a search.
3. The Standard profile enables Search, Node, and Automated Cron [and will include Help Topics eventually when it is stable]. This means that upon initial site install, cron will run immediately (on/before first page load), and it will continue to run every few hours by default. So the above is not a long-lasting problem -- if search results don't appear immediately, they will eventually without further action by an admin.
4. Some people may disable Automatic Cron (especially on production sites), but if they do so hopefully they will set up an outside cron process and again, any problems with search results not appearing will eventually vanish.
5. Some people may install Drupal without the Automated Cron module (if they don't use the Standard profile) and may not know they must set up outside cron. They would never get search results from Node or Help Topics and might not understand why.
6. The main problem for this issue: Currently Help Topics are experimental, so if someone starts with Standard and installs Help Topics, they will immediately see the help search box, but it won't show results until cron runs, and possibly won't show all search results until after a few cron runs. This might give them a bad impression of the Experimental module. It will (as the other problems above) go away as soon as cron runs a few times.

Proposed resolution

There are several possible solutions to some or all of these problems (from comment #23, which was partly compiled from previous comments on this issue):

1. Run cron (once) whenever any module is installed (as part of module installation), whether or not Automated Cron is installed. This might not fully solve the problem, though, because it may take several cron runs to fully index for search.
2. Reset the cron timestamp whenever any module is installed, for purposes of Automated Cron module, so it will run on the next page load (some patches on this issue took this approach). This only works at all if Automated Cron is installed, and it may not fully solve the problem, because it may take several cron runs to fully index for search.
3. Check search index status after a search, or perhaps only if the search results are empty, and point the user towards the search status page that tells them the index status and how to fix it by running cron. (see comment 18). This could be expensive. On the other hand, the status could possibly be cached after the cron run so it doesn't have to be recalculated (at the risk of it not being totally accurate)? We could at a minimum cache a Boolean value stating whether, at the last indexing run, the site was or was not 100% indexed, and use that to decide to display that message.
4. To take care of help topics specifically, we could implement hook_install() and hook_modules_installed() in the Help Topics module. In these implementations, if both Help Topics and Search are now installed, run a batch job that indexes help topics search until fully indexed. I think we'd want to run that after every module install, because modules might have their own topics and it would be good to add them to the index. Probably would be good to do after theme installs too, because they can also have topics.

Because this is really concerned with help topics, and we don't really need to solve long-standing problems with the core Search module on this issue, probably only the last proposed solution is a good idea? That would take care of the problem for help topics; other modules providing search could do something similar if they wanted to.

Remaining tasks

Decide what to do and make a new patch.

User interface changes

Once you have Help Topics and Search installed, topics should be searchable.

API changes

None.

Data model changes

None.

Release notes snippet

Not necessary.

Problem/Motivation

The uninstall box for Layout Builder is grayed out with the message

The Layout Section field type is used in the following field: node.layout_builder__layout

The "Manage Fields" page shows the Layout field as locked.
The "Manage Display" page says

You must revert all customized layouts of this display before you can disable this option.

Without individually checking each node, there is no way to determine which must be reverted

Proposed resolution

• A "Revert All" button on Manage Display that works for only that single bundle. This will appear in the "Layout options" fieldset.
• This button is only visible if the layout has overrides
• When this button is visible, the "Use Layout Builder" and "Allow each content item to have its layout customized." fields are grayed out
• This button will first take the user to a confirmation form, to confirm they're OK with all overrides being deleted.
• After confirming, Layout Builder will be disabled for that display and all overrides in that bundle will be removed from the database (including revisions) and remove all tempstore data for overrides in that bundle

Remaining tasks

Review
Write tests.

User interface changes

The Manage Display UI will be slightly different see ^^Proposed Resolution for details.

API changes

N/A

Data model changes

N/A

Problem/Motivation

When I display a custom block using the block layout configuration the block prints using the block.html.twig template. However if I have a custom block view, each row is just the rendered fields, not the whole rendered block. The same problem occurs displaying a rendered block content entity in an ER field or displaying it programmatically like a normal content entity. It causes problems for themers and is inconsistent with similar row formats like "Show: Content" for nodes, and also means that contextual links don't show.

The problem is that block_content entities explicitly have no defined #theme/template because they were expected to always be rendered as a block (core, page_manager, .. doesn't matter, but it has to be a block).

Steps to reproduce:

1. Create a custom block
2. Create a view showing custom blocks
3. For the view format select Show = Custom block

Available workarounds

• Twig Tweak v2 has a Twig tag that lets you render blocks including block content.
• Block content template adds a new template for block content entities and restores contextual links.

Proposed resolution

So the answer to this might simply be that this is on purpose, if you want to display something with views or references or ..., then don't use block_content but either a node type or custom entity type. I'm not sure I see an alternative for keeping it working correctly and efficiently (=no double-render caching of the same content, for example) also within a block. However it's a major DrupalWTF moment when you realize this. It's also a while since D8 was released, there's no documentation about this and there's functionality available in core to trigger this bug.

Problem/Motivation

The term bundle is confusing to users and no longer is descriptive of the way bundles are used. A "bundle"
is a subtype of an entity type, which could be "node", "taxonomy" or "comment". For example, a "node bundle"
would be the equivalent of a Drupal 6 "content type".

Considerations:
A concept called "bundles" is going to be brought in from Symfony, so the Drupal term should be changed.
Effect of renaming Entity Type and Bundle on documentation
- Since a bundle could be a node type, if we rename bundle -> entity type, do we need to rename node type?
Attempting to convey the meaning of Entity subtype without using the word subtype

Proposed resolution

We need to have terms that cover:
a) Entity type (such as Node, Taxonomy, Custom block, Comment, etc.)
b) Bundle (such as content type, taxonomy vocabulary, comment type, block type, etc.)
c) Entity item (individual node, taxonomy term, etc.)

Proposed terms for entity type: Entity type, entity class, entity base type
Proposed terms for bundle: Bundle, entity type, entity sub-type, variant, variety, entity schema
Proposed terms for entity item: Entity item, Entity

Proposed combinations of these terms into a set of terminology:

A:

Entity type -> Entity class
Bundle      -> Entity type
Entity      -> Entity

B:

Entity type -> Entity type
Bundle      -> Entity variant/variety
Entity      -> Entity

C: [We decided on this option]

Entity type -> Entity type
Bundle      -> Entity subtype
Entity      -> Entity

D:

Entity type -> Entity type
Bundle      -> Entity subtype
Entity      -> Entity item

E:

Entity type -> Entity class
Bundle -> Entity family
Entity -> Entity

Notes:
1. Option D is what is currently used in the User Guide and Help Topics, but it may not be the best choice.
2. Within one entity type, we would still use the specific name. E.g., when talking about taxonomy terms, we would use the word "Vocabulary" to refer to a bundle, not the generic "Entity variant" or whatever we choose. This terminology is for the generic text to describe entities in general.
3. MIME types, which are also 2 level, use the terms "type" and "subtype": http://en.wikipedia.org/wiki/Internet_media_type, http://www.iana.org/assignments/media-types/index.html

Remaining tasks

a) [done] Decide on which alternative makes the most sense, hopefully based on usability testing.

==> At #3164615: Drupal Usability Meeting 2020-08-18 we decided on option (C):

Entity type -> Entity type
Bundle      -> Entity subtype
Entity      -> Entity

b) Change the Drupal Core UI text to use this terminology.
[we need a patch for this]

c) Change the help topics to use this terminology on #3121340: Fix up minor problems in help topics
==> Help topics are already using this terminology of "entity type" and "entity subtype"; will want to make sure we are using the term "entity" rather than "entity item".

d) Change the User Guide to use this terminology on #3165909: Make sure entity terminology is consistent in User Guide.

e) Update Entity API documentation to mention the UI terminology, without changing the field/entity code. Things to update:
- https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21...
- Some doc blocks in the Content Entity base interfaces and classes probably?
- Some doc blocks in the Field and Field UI API probably?
[we need a patch for this]

f) [done] Update the UI text standards page with this change
https://www.drupal.org/docs/develop/user-interface-standards/interface-text
Compare revisions: https://www.drupal.org/node/604342/revisions/view/11472253/12184451

User interface changes

Entities will have standardized and better terminology in the UI and in help.

API changes

Probably none.

Original report by webchick

I'd really love to see the word "bundles" done away with. I've yet to meet a human being who can explain this in fewer than 300 words and with a lot of head scratching and glazed-over eyes on behalf of the listener. Witness users trying to figure this out at: http://drupal.org/node/1040330

Per https://www.drupal.org/project/multiupload_filefield_widget this plugin has been added to D8, but the migration is failing and cause a broken site.

The "file_mfw" plugin does not exist. Valid plugin IDs for Drupal\Core\Field\WidgetPluginManager are: comment_default, datetime_datelist, datetime_default, file_generic, image_image, link_default, path, redirect_source, text_textarea, text_textarea_with_summary, text_textfield, datetime_timestamp, boolean_checkbox, email_default, entity_reference_autocomplete_tags, entity_reference_autocomplete, language_select, number, options_buttons, options_select, string_textarea, string_textfield, uri (core\lib\Drupal\Component\Plugin\Discovery\DiscoveryTrait.php:53)

Per https://www.drupal.org/project/multiupload_imagefield_widget this plugin has also been added to D8, but the migration is failing and cause a broken site.

The "image_miw" plugin does not exist. Valid plugin IDs for Drupal\Core\Field\WidgetPluginManager are: comment_default, datetime_datelist, datetime_default, file_generic, image_image, link_default, path, redirect_source, text_textarea, text_textarea_with_summary, text_textfield, datetime_timestamp, boolean_checkbox, email_default, entity_reference_autocomplete_tags, entity_reference_autocomplete, language_select, number, options_buttons, options_select, string_textarea, string_textfield, uri (core\lib\Drupal\Component\Plugin\Discovery\DiscoveryTrait.php:53)

Are there any patches to solve this migration bugs or ongoing tasks to fix this bugs?

Meta for triage credit, please comment and link to issues you triaged and closed.

Meta for triage credit, please comment and link to issues you triaged and closed.

Problem/Motivation

If the Drupal 7 site uses the telephone field module the new migrated Drupal 8 site should also have a telephone field with the same content.
The Drupal 7 module https://www.drupal.org/project/telephone

Problem/Motivation

When running migration Kernel tests, i.e. MigrateNodeComleteTest.php, an error in the source plugin query results in fatal errors from PHPUnit and not a helpful SQL error as expected. The only way to see a useful error message is to use the debugger/

There were 2 errors:
  
1) Drupal\Tests\taxonomy\Kernel\Migrate\d7\MigrateTaxonomyTermTest::testTaxonomyTerms
PHPUnit\Framework\Exception: PHP Fatal error:  Uncaught Exception: Serialization of 'Closure' is not allowed in Standard input code:80
Stack trace:
#0 Standard input code(80): serialize(Array)
#1 Standard input code(112): __phpunit_run_isolated_test()
#2 {main}
  thrown in Standard input code on line 80
Fatal error: Uncaught Exception: Serialization of 'Closure' is not allowed in Standard input code:80
Stack trace:
#0 Standard input code(80): serialize(Array)
#1 Standard input code(112): __phpunit_run_isolated_test()
#2 {main}
  thrown in Standard input code on line 80
  
/var/www/html/vendor/phpunit/phpunit/src/Util/PHP/AbstractPhpProcess.php:254
/var/www/html/vendor/phpunit/phpunit/src/Util/PHP/AbstractPhpProcess.php:171
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestSuite.php:601
/var/www/html/vendor/phpunit/phpunit/src/TextUI/TestRunner.php:633
/var/www/html/vendor/phpunit/phpunit/src/TextUI/Command.php:204
/var/www/html/vendor/phpunit/phpunit/src/TextUI/Command.php:163
  
2) Drupal\Tests\taxonomy\Kernel\Migrate\d7\MigrateTaxonomyTermTest::testTaxonomyTermEntityTranslations
PHPUnit\Framework\Exception: PHP Fatal error:  Uncaught Exception: Serialization of 'Closure' is not allowed in Standard input code:80
Stack trace:
#0 Standard input code(80): serialize(Array)
#1 Standard input code(112): __phpunit_run_isolated_test()
#2 {main}
  thrown in Standard input code on line 80
Fatal error: Uncaught Exception: Serialization of 'Closure' is not allowed in Standard input code:80
Stack trace:
#0 Standard input code(80): serialize(Array)
#1 Standard input code(112): __phpunit_run_isolated_test()
#2 {main}
  thrown in Standard input code on line 80

/var/www/html/vendor/phpunit/phpunit/src/Util/PHP/AbstractPhpProcess.php:254
/var/www/html/vendor/phpunit/phpunit/src/Util/PHP/AbstractPhpProcess.php:171
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestSuite.php:601
/var/www/html/vendor/phpunit/phpunit/src/TextUI/TestRunner.php:633
/var/www/html/vendor/phpunit/phpunit/src/TextUI/Command.php:204
/var/www/html/vendor/phpunit/phpunit/src/TextUI/Command.php:163

--

Steps to reproduce

Change a query in any source plugin and run the relevant migration test.
For example,
In d6\Term.php change ->orderBy('td.tid'); to ->orderBy('td.foo');

Then run the d6 term test.

phpunit -c core --debug -v --colors=always core/modules/taxonomy/tests/src/Kernel/Migrate/d6/MigrateTaxonomyTermTest.php

Proposed resolution

Remaining tasks

Patch
Review
Commit

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The migration system has no support for migrating node reference fields, with their settings and values, from Drupal 7 to Drupal 8.
The source module is https://www.drupal.org/project/references.

Proposed resolution

Add a field plugin to handle Drupal 7 node reference fields. Currently the patch also adds a field plugin to handle Drupal 7 user reference fields.

Add field plugins, migrate_drupal\Plugin\migrate\field\d7\NodeReference and migrate_drupal\Plugin\migrate\field\d7\NodeReference.
Update Kernel tests d7/MigrateNodeCompleteTest.php and d7/MigrateNodeRevisionTest.php, FieldDiscoveryTest.
Update Functional tests d7/MultilingualReviewPageTest.php, d7/NoMultilingualReviewPageTest.php, and d7/UpgradeTest.php.
Update fixture, add a node and user reference field to the test fixture (added to the article content type). Fixture still works via the D7 UI.
Update migrate_drupal migration state file.

Remaining tasks

• Review
• Reroll (Novice task, see #84)
• Commit the patch
• Jump into a ball pit and roll around happily

User interface changes

None.

API changes

None.

Data model changes

None.