In core/lib/Drupal/Core/StreamWrapper/StreamWrapperInterface.php, there is a typo. The comments state the following:

 * Provides a Drupal interface and classes to implement PHP stream wrappers for
 * public, private, and temporary files. Extends the StreamWrapperInterface
 * with methods expected by Drupal stream wrapper classes.

However, the class extends PhpStreamWrapperInterface, not StreamWrapperInterface as is stated in the comment.

interface StreamWrapperInterface extends PhpStreamWrapperInterface {

Problem/Motivation

Updating Drupal core currently requires manually uploading core files or a complex environment such as Drush. Drupal's competitors, Wordpress and Joomla, allow core updates within the web UI. We should provide this, so novice users can easily keep their site secure and up-to-date.

Proposed resolution

Allow core updates to be installed the same way contrib updates are installed.

Remaining tasks

#538660: Move update manager upgrade process into new authorize.php file (and make it actually work)
#22336: Move all core Drupal files under a /core folder to improve usability and upgrades
#606190: Fix handling of database schema updates in update manager workflow
#509010: Build a Package signing system for d.o. so that people can securely and simply download and verify packages

User interface changes

None

API changes

None

Data model changes

None

Original report by dww

Update manager is now in core (#538660: Move update manager upgrade process into new authorize.php file (and make it actually work)), meaning end-users can upgrade missing updates (and install new code) via the web UI. Yay!

Unfortunately, making it able to upgrade Drupal core was just too complicated for the initial patch, and threatened to derail the entire effort getting into D7. Sadly, I think this is going to have to be punted to D8, but I'm opening an issue about it for discussion and so we have a stake in the ground for this effort in the future.

coming from #2048309: Views UI Preview - navigation is broken, see comment #1 point 3 .

if a contextual filter is specified in the preview textbox, this input gets lost when navigating to a different page on the preview.

Steps to reproduce:

1. Devel create 50 nodes of type 'article' and 'basic page'
2. Clone the 'frontpage' view
3. Change display format to e.g. table, selecting 'title' and 'type' fields as columns in the table
4. Add a contextual filter to the cloned view, for the 'type' field
5. Type 'page' in the textbox ifor the contextual filter preview
6. Click 'Update preview'
7. You get a table of only 'basic page' nodes
8. Click any page link in the pager

Expected result:
A second page of 'basic page' nodes

Actual result:
A mix of 'basic page' and 'article' nodes, and the contextual filter textbox is void.

Per #31:

Looks like we may not need to push/pop the request in ViewUI::renderPreview anymore. I think that was relevant when that method was calling drupal_render() so that the pager could use a different 'current' request to build its links. But now, since #2412805: View preview does not attach assets provided by plugins, ViewUI::renderPreview returns a render array, so if we push a request and then pop it within the same method this ends up as a no-op, since the rendering occurs at a later stage.

We can clean up some old stale code to get the expected result.

Follow-up to #2752961-157: No reliable method exists for clearing the Twig cache

Problem/Motivation

@Fabianx' post:

I am still of the opinion this should have used cache tags instead.

However cache tags could be used in addition as the main thing is the addition of the invalidate method.

e.g. my proposal for a follow-up:

- Inject cache_tags.checksum

- Use 'twig-templates' cache tag

- Calculate the checksum

- Use the checksum as "cs[NUM]-" prefix before the actual uniqid prefix

- Use Cache::invalidateTags(['twig-templates']); as invalidation method instead of deletion of the state

- Hosting providers can just watch for the invalidation of 'twig-templates' cache tag and do a clean-up job for the previous checksum

- Hosting providers can check if the checksum is valid during garbage collection

- Even without monitoring garbage-collection is dead-easy as checksums for an individual cache tag will currently be always increasing

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

A developer is unable to use custom markup for the throbber element (e.g. when integrating existing solution that already has styles and JavaScript code).

Proposed resolution

Move HTML code for the element to Drupal.theme function and use Drupal theming mechanism for JavaScript code.

Problem/Motivation

While working on #2225681: Migrate D6 i18n blocks translated strings I made some changes to the Drupal6 database dump via the UI as required by that issue. One of the changes was unnecessary, just left over from me learning how to recreate the problem over there. Later, that change was causing failures and since it was not needed I removed it. This issue is to investigate the failure caused by that data.

The data was added in comment 176. It was all related to this entry in i18n_blocks and the relevant menu entries.
4 | menu | menu-fr-secondary-links | 0 | fr

MariaDB [dev2_dump]> select * from i18n_blocks;
+------+--------+-------------------------+------+----------+
| ibid | module | delta                   | type | language |
+------+--------+-------------------------+------+----------+
|    4 | menu   | menu-fr-secondary-links |    0 | fr       | migrated
+------+--------+-------------------------+------+----------+
4 rows in set (0.00 sec)

The error was reported in the full migration test, https://www.drupal.org/pift-ci-job/946662

1) Drupal\Tests\migrate_drupal_ui\Functional\d6\MigrateUpgrade6Test::testMigrateUpgradeExecute
Exception: Warning: array_walk() expects parameter 1 to be array, string given
Drupal\Core\Utility\LinkGenerator->generate()() (Line: 119)

The first task is to reproduce the error.

A better title would be good too.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Block visibility settings allow to show a block "per page path" OR "per content type" only.

Example: "Recent blog posts" - a pure blog related block.
If "Pages" is set to "All pages" AND "Content types" to "Blog entry" it will show up ONLY on blog posts but not on Blogs page.
If "Only the listed pages" is set to "blog" it will show up ONLY on Blogs page but not on any of blog posts.
If "Only the listed pages" is set to "blog" AND "Content types" is set to "Blog entry" it will not be shown at all. Nowhere.
Isn't it logical to allow it to be visible at Blogs page AND Blog posts?

The same goes for any other block, not only "recent blog posts".

(There are snippets like this one http://drupal.org/node/134425 but they require the PHP module.)

Problem/Motivation

InstallUninstallTest seems to take longer than it should.

Proposed resolution

Find and eliminate the reasons for the delay.

InstallUninstallTest in seconds:

See also #2659940-162: Extension System, Part III: ThemeExtensionList and ThemeEngineExtensionList.

Remaining tasks

User interface changes

none

API changes

none

Data model changes

none

This is a follow-up to

https://www.drupal.org/project/drupal/issues/2869903#comment-12629702

I introduced a typo while fixing something.

the protected property should be:

protected $renderer;

instead of:

protected $render;

After uninstall migration modules the tables created not removed and still exist and can not be reasonable to deploy without remove that tables.

Problem:
The 3 modules Migrate, Migrate_drupal, Migrate_drupal_ui didn't implement Hook_uninstall() to remove these tables or other data related to migration and have no use after complete migration.

Motivation:
List all tables prefixed with migrate_ in hook_install.
Implement hook_uninstall to remove all tables prefixed with migrate_ except those listed when install the same prefix.

Solution
The migrate core module must list all tables prefixed with migrate_ during installl.
The migrate module must remove all tables prefixed with migrate_ during uninstall.

Kindly reveal the wrong suppositions I made here and the best practice to achieve.

Problem/Motivation

As decided in #2745619: [policy, no patch] Which core entities get revisions?, taxonomy terms should be converted to be revisionable and publishable.

Proposed resolution

Do it.

Remaining tasks

Decide how we want to deal with term hierarchies, see #2705389-48: Selected content entities should extend EditorialContentEntityBase or RevisionableContentEntityBase.

User interface changes

None yet, revision support is only enabled at the API level.

API changes

Nope.

Data model changes

Taxonomy terms are now revisionable and publishable.

Problem/Motivation

When importing data using the Migrate module and the concat process plugin (http://cgit.drupalcode.org/drupal/tree/core/modules/migrate/src/Plugin/m...), if the data source has empty values, the delimiter is included anyways.

Example:

If I'd wanted to have a migration that used concat to join value_1 and value_2 I'd have these settings:

my_field:
    plugin: concat
    source:
      - value_1
      - value_2
    delimiter: '& '

Which will result in the following data:

I don't think 2, 3 and 4 are the desired result.

Proposed resolution

Add an array filter to strip out empty values when concat'ing. I don't see a use case of wanting these empty values, but this could be optional.

Problem/Motivation

The 7.x Date module allowed the field to specify which parts of the date to collect (Year, Month, Day, Hour, Minute, and Second):

For parts of the date that are not collected, those are stored as 00. For instance, if one choses to not collect seconds, then the date is stored as 2016-04-03 12:15:00.

Proposed resolution

Add this functionality to the date form widgets.

Remaining tasks

User interface changes

API changes

Data model changes

This shouldn't impact field storage, but would add an option to the field definition config.

Problem/Motivation

The EntityReferenceAutocompleteWidget will always return a maximum of 10 results, which is caused by the call $entity_labels = $handler->getReferenceableEntities($string, $match_operator, 10); in Drupal\Core\Entity\EntityAutocompleteMatcher::getMatches().

Proposed resolution

Make the match size limit configurable as is the case with the operator.

Remaining tasks

N/A

User interface changes

N/A

API changes

N/A

Data model changes

N/A

FieldConfigInterface::setDefaultValueCallback() accepts a callback for a base of config field's default value, either as a function or method name.

We get this pattern repeated by entity types over and over again for fields where the default value comes from a service, such as the uid and created fields:

Node entity:

    $fields['uid'] = BaseFieldDefinition::create('entity_reference')
      ->setLabel(t('Authored by'))
      ->setDescription(t('The username of the content author.'))
      ->setRevisionable(TRUE)
      ->setSetting('target_type', 'user')
      ->setDefaultValueCallback('Drupal\node\Entity\Node::getCurrentUserId')

...

  public static function getCurrentUserId() {
    return [\Drupal::currentUser()->id()];
  }

Media entity:

    $fields['uid'] = BaseFieldDefinition::create('entity_reference')
      ->setLabel(t('Authored by'))
      ->setDescription(t('The user ID of the author.'))
      ->setRevisionable(TRUE)
      ->setDefaultValueCallback(static::class . '::getCurrentUserId')
...

    $fields['created'] = BaseFieldDefinition::create('created')
      ->setLabel(t('Authored on'))
      ->setDescription(t('The time the media item was created.'))
      ->setTranslatable(TRUE)
      ->setRevisionable(TRUE)
      ->setDefaultValueCallback(static::class . '::getRequestTime')

...

  public static function getCurrentUserId() {
    return [\Drupal::currentUser()->id()];
  }

  public static function getRequestTime() {
    return \Drupal::time()->getRequestTime();
  }

We could remove these wrapper method and save on repeated code and improve DX if we allow setDefaultValueCallback() to accept a callback in service notation the same way that route controllers do, that is, 'service_name:method'.

Live site on shared hosting, with Drupal 8.5.3, PHP 7.2, in Safari, Firefox, and Chrome the above-mentioned error appears when users try to register and/or try to reset their password, and/or try to login.

Users do receive a confirmation email, but after clicking on link in email the above mentioned error appears again.

I changed PHP to version 5.6, as well as version 7.1, but error stays.

In Chrome registered user after refreshing page has logged in.
In Firefox refreshing page does not help. Same error appears.

----------------------------------------------------

The recent log messages shows the following:
Type: php
Date: Thursday, 24 mei 2018
User: Visitor
Locatie: http://sjulleksounds.nl/user/password
Doorverwijzer: http://sjulleksounds.nl/user/password

In the log is the following message:

Message User error: Redirects to external URLs are not allowed by default, use \Drupal\Core\Routing\TrustedRedirectResponse for it. in Drupal\Core\EventSubscriber\RedirectResponseSubscriber->checkRedirectUrl() (regel 85 van /home/sjulleksounds.nl/public_html/sjulleksounds.nl/core/lib/Drupal/Core/EventSubscriber/RedirectResponseSubscriber.php) #0 /home/sjulleksounds.nl/public_html/sjulleksounds.nl/core/includes/bootstrap.inc(582): _drupal_error_handler_real(256, 'Redirects to ex...', '/home/sjullekso...', 85, Array) #1 [internal function]: _drupal_error_handler(256, 'Redirects to ex...', '/home/sjullekso...', 85, Array) #2 /home/sjulleksounds.nl/public_html/sjulleksounds.nl/core/lib/Drupal/Core/EventSubscriber/RedirectResponseSubscriber.php(85): trigger_error('Redirects to ex...', 256) #3 [internal function]: Drupal\Core\EventSubscriber\RedirectResponseSubscriber->checkRedirectUrl(Object(Symfony\Component\HttpKernel\Event\FilterResponseEvent), 'kernel.response', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher)) #4 /home/sjulleksounds.nl/public_html/sjulleksounds.nl/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\FilterResponseEvent), 'kernel.response', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher)) #5 /home/sjulleksounds.nl/public_html/sjulleksounds.nl/vendor/symfony/http-kernel/HttpKernel.php(191): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.response', Object(Symfony\Component\HttpKernel\Event\FilterResponseEvent)) #6 /home/sjulleksounds.nl/public_html/sjulleksounds.nl/vendor/symfony/http-kernel/HttpKernel.php(260): Symfony\Component\HttpKernel\HttpKernel->filterResponse(Object(Drupal\Core\Form\EnforcedResponse), Object(Symfony\Component\HttpFoundation\Request), 1) #7 /home/sjulleksounds.nl/public_html/sjulleksounds.nl/vendor/symfony/http-kernel/HttpKernel.php(79): Symfony\Component\HttpKernel\HttpKernel->handleException(Object(Drupal\Core\Form\EnforcedResponseException), Object(Symfony\Component\HttpFoundation\Request), 1) #8 /home/sjulleksounds.nl/public_html/sjulleksounds.nl/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #9 /home/sjulleksounds.nl/public_html/sjulleksounds.nl/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #10 /home/sjulleksounds.nl/public_html/sjulleksounds.nl/core/modules/page_cache/src/StackMiddleware/PageCache.php(99): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #11 /home/sjulleksounds.nl/public_html/sjulleksounds.nl/core/modules/page_cache/src/StackMiddleware/PageCache.php(78): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true) #12 /home/sjulleksounds.nl/public_html/sjulleksounds.nl/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #13 /home/sjulleksounds.nl/public_html/sjulleksounds.nl/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(50): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #14 /home/sjulleksounds.nl/public_html/sjulleksounds.nl/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #15 /home/sjulleksounds.nl/public_html/sjulleksounds.nl/core/lib/Drupal/Core/DrupalKernel.php(664): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #16 /home/sjulleksounds.nl/public_html/sjulleksounds.nl/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #17 {main}.

Problem/Motivation

Migrate multilingual data from D6 and D7.

Proposed resolution

D6 migration and much of D7 is working so use those migrations, and their plugins as models for these migrations. It is preferred to improve the existing destination plugins instead of creating new ones.

Remaining tasks

Because D6 is nearing end of life, the D6 multilingual migrations are the highest priority as shown in the list below.

Top Priority

• Experimental migrate_drupal_i18n module: #2953360: Experimental migrate_drupal_i18n module

Drupal 6 nodes and configuration settings to support nodes.

• Languages: #2130307: Variable to config: language.negotiation [d7] and #2166875: Migrate D6 languages.
• Language negotiation settings: #2225293: Migrate D6 and D7 language negotiation settings
• Content type translation settings: #2225271: Migrate content type language settings from Drupal 6 & 7
• D6 Nodes: #2225775: Migrate Drupal 6 core node translation to Drupal 8
• Update D6 dump file: #2670170: Add i18n string & variable data to d6_dump

High priority - remaining content migrations

• D7 entity translation: #2073467: Migrate Drupal 7 Entity Translation data to Drupal 8
• D7 title: #2863437: Migrate Drupal 7 title data to Drupal 8
• Translations of taxonomy: #2886609: Migrate D6 i18n translations of taxonomy vocabulary/terms
• User Entity translations: #2669984: Migrate D7 User entity field translations

Medium Priority

• i18n variables: #2225477: Add migrate sources and destinations for D6 i18n variables
• i18n menu: #2225587: Migrate D6 i18n menu links
• i18n block: #2225681: Migrate D6 i18n blocks translated strings
• i18n custom block: #2909444: Migrate D6 i18n custom blocks (boxes)
• i18n custom CCK: #2959410: Migrate D6 i18n CCK fields label and description
• Taxonomy vocabularies: #2225781: Migrate D6 i18n taxonomy vocabularies
• Taxonomy terms: #2784371: Migrate D6 i18n taxonomy term language (but not yet translations)
• Taxonomy vocabulary i18n settings: #2975509: Migrate i18ntaxonomy vocabulary settings
• Taxonomy fields on translations of nodes: #2859297: Migrate d6 translated nodes with translated taxonomy
• Update D7 dump file: #2670846: Add i18n data to d7_dump
• Data related to old translated node IDs #2746527: [META] Handle data related to Drupal 6 and 7 node translations with different IDs

Low Priority

• Node revisions: #2746541: Migrate D6 and D7 node revision translations to D8
• User Profile: #2225717: Add config translation support to migrations and implement for Drupal 6 user profile fields
• D6 User profile field value option translations: #2845975: Migrate Drupal 6 user profile field value option translations
• D7 Nodes: #2669964: Migrate Drupal 7 core node translations to Drupal 8
• Deriving translation migrations: #2746517: Automatically derive auxiliary migrations
• D6 node translation source: #2746293: Migrate content_translation_source when migrating node translations
• D6 synchronized fields: #2754493: D6 synchronized fields aren't migrated properly
• D7: i18n variable: #2970845: Add migrate sources and destinations for D7 i18n variables
• D7: system site settings #2970847: i18n Variable to config: system site settings [d7]
• D7: site offline message #2970848: i18n Variable to config: site offline message [d7]
• D7: user settings #2970849: i18n Variable to config: user settings [d7]
• D7: user mail #2970850: i18n Variable to config: user mail [d7]

Problem/Motivation

On #2886609: Migrate D6 i18n translations of taxonomy vocabulary/terms, we found that vocabulary i18n settings from the i18ntaxonomy module were not being migrated.

On a D6 site with this module enabled, the Vocabulary page has a "Multilingual options" section of the settings that looks like this:

On my D6 site, as you can see from the screenshot, the Language setting is empty, and the vocabulary is set to the "Localize terms" option. Currently, when I migrate this site to D8, that setting is not coming through -- the vocabulary is being set to English language with no term translation.

Proposed resolution

Migrate the vocabulary settings. I looked into how this is stored in D6. There's a form alter method in i18ntaxonomy.module around line 366 that adds this to the vocabulary form:

      $form['i18n'] = array(
        '#type' => 'fieldset',
        '#title' => t('Multilingual options'),
        '#collapsible' => TRUE,
        '#weight' => 0,
      );
      $form['i18n']['i18nmode'] = array(
        '#type' => 'radios',
        '#title' => t('Translation mode'),
        '#options' => _i18ntaxonomy_vocabulary_options(),
        '#default_value' => $mode,
        '#description' => t('For localizable vocabularies, to have all terms available for translation visit the <a href="@locale-refresh">translation refresh</a> page.', array('@locale-refresh' => url('admin/build/translate/refresh'))),
      );

This data is then saved in variable i18ntaxonomy_vocabulary<code>. It looks like the structure is just an associative array of <code>$vid => $mode and here are the mode options and constant values:

  // this is i18ntaxonomy_vocabulary_options():
  return array(
    I18N_TAXONOMY_NONE => t('None. No multilingual options for this vocabulary.'),
    I18N_TAXONOMY_LOCALIZE => t('Localize terms. Terms are common for all languages, but their name and description may be localized.'),
    I18N_TAXONOMY_TRANSLATE => t('Per language terms. Different terms will be allowed for each language and they can be translated.'),
    I18N_TAXONOMY_LANGUAGE => t('Set language to vocabulary. The vocabulary will have a global language and it will only show up for pages in that language.'),
  );

  // and the constants are defined as:

// No multilingual options
define('I18N_TAXONOMY_NONE', 0);
// Run through the localization system
define('I18N_TAXONOMY_LOCALIZE', 1);
// Predefined language for all terms
define('I18N_TAXONOMY_LANGUAGE', 2);
// Multilingual terms, translatable
define('I18N_TAXONOMY_TRANSLATE', 3);

So, in my case, variable i18ntaxonomy_vocabulary would have a value

array(5 => 1)

for vid 5, value I18N_TAXONOMY_LOCALIZE.

I think this is the only settings option we need to worry about for this issue.

Remaining tasks

a) Make a patch with tests.
b) Test manually.

User interface changes

Vocabulary i18n settings will be migrated.

API changes

Probably not.

Data model changes

Probably not.

Problem/Motivation

During the Managing Drupal sites with Composer BoF at DrupalCon Baltimore 2017, the topic of contributed module front-end library management came up.

Here's the current problem:

• Webform (and other similar contrib projects) requires a 3rd party front-end library.
• Modules can't rely upon libraries being available inside [drupal-docroot]/vendor/[library/here], because the project vendor directory isn't guaranteed to be in the docroot.
• Current practices seem to indicate that a libraries folder in the docroot is the best place for 3rd party front-end libraries.
• It's hard to get contributed module dependencies to be installed to [drupal-docroot]/libraries/[library/here] instead of the vendor directory. Especially if the library doesn't care about Drupal and doesn't have a custom type of drupal-library

There are ways to hack around this:

• Add a custom and project-specific repository for every 3rd party library in your composer.json file.
• Use the composer-installers-extender library to allow the specification of the install path per-library.
• Ditch Composer and just download and commit all the 3rd party libraries into the [drupal-docroot]/libraries folder.

Proposed resolution

It would be really helpful if Drupal core could enable contributed modules to do things like specify a specific path into which a 3rd party dependency will be placed.

One solution we discussed would be adding code that responded to a Composer hook and moved a downloaded dependency into a specified path (which could be indicated via the project's composer.json file).

So a contributed module maintainer (e.g. Webform, Font Awesome Iconpicker, etc.) would add something like (pseudocode):

"extra": {
        "drupal-install-library-path": "libraries"
    }

And then when you composer require that contributed module, something in Drupal core's composer configuration would pick up that path and place the libraries for the 3rd party module into the specified path.

This is totally open to change (in terms of implementation), but the general idea is: everyone is solving this problem in a different way, and it would be nice if core could provide an official mechanism for doing this 'the Composer way'.

Or, at a minimum, we should document a recommended solution.

Remaining tasks

• Choose an approach (custom Composer hook? Add another library to help? Use/recommend Robo?)
• Implement the approach (this part's easy, right?)
• Document / announce the change so Contrib modules and themes can use this new approach

User interface changes

N/A

API changes

There may be some additional API functionality, but probably not.

Data model changes

N/A

Problem/Motivation

On #2886609-50: Migrate D6 i18n translations of taxonomy vocabulary/terms, I tested migrating a D6 site into D8, as follows:

a) Downloaded latest drupal 8.6.x dev tgz file from drupal.org (easier than git for me for Drupal core at the moment).
b) Installed Drupal from the UI, using the Minimal install profile, and configured site without Update module.
c) Turned on Seven/Bartik themes, and a bunch of core modules: Migrate, Migrate Drupal *UI, Migrate Drupal UI; all 4 multilingual modules; Toolbar; plus some my migrated d6 site would need: Taxonomy, Views, a bunch of field modules, custom blocks and custom menu items. Note at this point there are no content types or vocabularies in my D8 database, and no node or term data.
d) Went to /upgrade, clicked Continue, and entered the site database/files information from a D6 site that I wanted to migrate. This site has 2 languages, and some translated nodes and taxonomy terms in it.
e) Got this warning on the next page:

Problems with this:

• The warning says "WARNING: Content may be overwritten on your new site", but I have no content to be overwritten.
• In order to continue, I have to click a button saying "I acknowledge I may lose data. Continue anyway". This sounds like a legal disclaimer, and again, I have no data in my site to lose.
• (minor) The more information link text says "Upgrade handbook" but we don't really use the word "handbook" to refer to community documentation pages any more. Or at least, we shouldn't. The page title is "Known issues when upgrading from Drupal 6 or 7 to Drupal 8" anyway, and it's in a Guide that is called "Upgrading to Drupal 8". So the link title should probably be something more descriptive, like "known issues with migrations page".
• The page it takes me to https://www.drupal.org/docs/8/upgrade/known-issues-when-upgrading-from-d... does not have current information, as it refers to work in progress on an issue that is actually marked Closed (fixed). Anyway, it tells me "If you are executing a complete upgrade at once and you are performing the upgrade to an empty Drupal 8 site, everything should be OK.". Yes, it should - I don't have any data to conflict with.

So, this warning is totally unnecessary, and is incorrect.

Proposed resolution

Don't warn the user about ID conflicts if there is no data to conflict with in the database.

Remaining tasks

Make a patch and test it.

User interface changes

No warning about data loss if there is no data to lose.

API changes

Probably not.

Data model changes

Probably not.