Problem/Motivation

Disclaimer: Not sure that is the right project to post this.

1. Add a module as dist (using a stable, beta, alpha version) in your composer.json.
2. Create a patch that fixes the .info.yml file.
3. Add the patch in composer.json and update.

In most of the cases the paching will fail because the content of the dist .info.yml contains also the packager script lines. The patch is build every time using the source, where those lines doesn't exist.

Proposed resolution

The .info.yml file is part of the codebase, it should not be altered by any script.

Long term solution

Move these package info in their own file that should be added by the the packager script, as LICENSE.txt is added.

Quick fix

Before the line # Information added by Drupal.org packaging script on ... add enough empty lines, so that the changed hunk doesn't interfere. Will still be a problem with the .info.yml files of sub-modules being deleted.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A

I got he following error when trying to install config_translation in 8.4

The website encountered an unexpected error. Please try again later.
Recoverable fatal error: Argument 1 passed to Drupal\config_translation\ConfigEntityMapper::setEntity() must implement interface Drupal\Core\Config\Entity\ConfigEntityInterface, null given, called in /var/www/drupal8/core/modules/config_translation/src/ConfigEntityMapper.php on line 110 and defined in Drupal\config_translation\ConfigEntityMapper->setEntity() (line 138 of core/modules/config_translation/src/ConfigEntityMapper.php).
Drupal\config_translation\ConfigEntityMapper->setEntity(NULL) (Line: 110)
Drupal\config_translation\ConfigEntityMapper->populateFromRouteMatch(Object) (Line: 85)
Drupal\config_translation\Access\ConfigTranslationOverviewAccess->getMapperFromRouteMatch(Object) (Line: 58)
Drupal\config_translation\Access\ConfigTranslationOverviewAccess->access(Object, Object)
call_user_func_array(Array, Array) (Line: 159)
Drupal\Core\Access\AccessManager->performCheck('config_translation.access.overview', Object) (Line: 135)
Drupal\Core\Access\AccessManager->check(Object, Object, NULL, 1) (Line: 92)
Drupal\Core\Access\AccessManager->checkNamedRoute('entity.contact_form.config_translation_overview', Array, Object, 1) (Line: 327)
Drupal\Core\Menu\LocalTaskManager->getTasksBuild('entity.contact_form.edit_form', Object) (Line: 358)
Drupal\Core\Menu\LocalTaskManager->getLocalTasks('entity.contact_form.edit_form', 0) (Line: 574)
admin_toolbar_tools_menu_links_discovered_alter(Array, NULL, NULL) (Line: 501)
Drupal\Core\Extension\ModuleHandler->alter('menu_links_discovered', Array) (Line: 168)
Drupal\Core\Menu\MenuLinkManager->getDefinitions() (Line: 191)
Drupal\Core\Menu\MenuLinkManager->rebuild() (Line: 61)
Drupal\Core\EventSubscriber\MenuRouterRebuildSubscriber->menuLinksRebuild() (Line: 49)
Drupal\Core\EventSubscriber\MenuRouterRebuildSubscriber->onRouterRebuild(Object, 'routing.route_finished', Object) (Line: 108)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('routing.route_finished', Object) (Line: 192)
Drupal\Core\Routing\RouteBuilder->rebuild() (Line: 83)
Drupal\Core\ProxyClass\Routing\RouteBuilder->rebuild() (Line: 302)
Drupal\Core\Extension\ModuleInstaller->install(Array, 1) (Line: 83)
Drupal\Core\ProxyClass\Extension\ModuleInstaller->install(Array) (Line: 448)
Drupal\system\Form\ModulesListForm->submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 585)
Drupal\Core\Form\FormBuilder->processForm('system_modules', Array, Object) (Line: 314)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 74)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
call_user_func_array(Object, Array) (Line: 153)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 656)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Problem/Motivation

Currently, Drupal.org and various communication channels inform site owners of when the next important (and possibly more difficult) minor version update is scheduled, but this information is not available within Drupal itself.

In #2909665: [plan] Extend security support to cover the previous minor version of Drupal, we want to extended security coverage for the pervious minor version of Drupal for an extra release, so that if (e.g.) 8.6.2 is created with a security advisory in October, the security fixes in the advisory will be backported to (e.g.) 8.5.7, so that the site owner has more time to test minor updates while still keeping their site secure.

So for example the Drupal core minor 9.0.x would be supported until 9.2.0 is released and 9.1.x is supported until 9.3.x. This information is not available inside Drupal.

For Drupal releases before a new Drupal major this will different. For example 8.8.x will be supported until December 2, 2020 and 8.9.x, the LTS release will be supported until November 2021. This information also not available until inside Drupal

Related: This issue has some similarities to #2766491: Update status should indicate whether installed contributed projects receive security coverage, but it is not the same. That issue is about whether or not the whole contributed project has opted into security team support; this issue is about which minor versions of core currently have security team support.

Proposed resolution

Indicate to the site owner when:

1. The site's minor version of Drupal core will have security coverage until a specific version of Drupal is released. This will be 2 minor releases. For instance if 9.0.2 is installed the will have security coverage until 9.2.0 is released
2. The site receives security coverage but when the next minor version of Drupal is release their coverage will end. For example they are on 9.0.10 and 9.1.17 is the latest release. When 9.2.0 is released
   9.0.x will no longer receive security coverage.
3. The site does not receive any support and they should update as soon as possible to have security coverage. They are on 9.0.10 and 9.2.0 has already been released.

Special logic for the minor releases 8.8.x and 8.9.x.

1. 8.8.x will have security coverage until 2020-12-02. Sites on 8.8.x should be warned that they should update as soon as possible on 2020-6-02(this is that same as if they had 1 minor release to update)
2. 8.9.x is the LTS release for Drupal. It will receive coverage until 2021-11-01. Sites on 8.9.x will not receive a update as soon as possible warning 6 months before the LTS term ends

Completed tasks

1. Followup regarding the last minor of a release and/or the next major release (might be noted on #2608062: [META] Requirements for tagging Drupal 9.0.0-alpha1): #2998287: Provide accurate information on the security coverage of the 8.x final minor and LTS, and recommend updating to the next major version when appropriate
2. Followup for potentially including minor coverage info/dates in the d.o XML data, rather than relying solely on the "supported minors" constant and handbook page: #2998285: Add information on later releases to updates.drupal.org
3. Followup to discuss whether this should also add anything to the "General system information" header at the top: #2998289: Make security coverage more prominent on the Status Report
4. Followup to discuss email notifications of being out of security coverage: #2998292: Send email when installed version no longer receives security coverage
5. Followup #3107378: Remove hard-coded dates from update logic for the status report
6. Followup #3110182: Provide localized date formatting in message about security coverage for the site's installed final 8.x or LTS releases
7. Followup #3110186: Simplify the wording of messages on the status report about security coverage for the site's installed minor version

Remaining tasks

• Port the patch to 8.8.x-dev (easy reroll)

User interface changes

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

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

Minor 8.0 is unsupported. 8.2 has come out

Minor 8.8 supported based on date, no warning

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

Minor 8.8 , not supported based on date,

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

Minor 8.9, support over

API changes

None

Data model changes

None

Currently you are able to allow a user to select from multiple view modes when embedding media; however, this list when embedding is not respecting if a view mode is enabled for that particular type.

For example: I have an Image media type and a Video media type, both have "Embedded" displays but only Image has a "Thumbnail" Display. Both displays are allowed in my CKEditor profile. When adding a video, it allows me to select "Thumbnail" which is not enabled, causing the Video to fallback to the "Default" display.

This is not intuitive and confusing for users.

Problem/Motivation

TestSiteInstallCommand does not yet provide the property but it's not tested with deprecation messages so we never got to see that warning.

Proposed resolution

Default to stark. I think my patch might be too simple though as it won't trigger the install profile logic anymore.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Removes various simple BC layers in various places in Drupal\Core. More or less covering everything that doesn't have a dedicated issue yet although a few still need an issue as they seemed a bit too tricky to touch. Likely makes sense to keep this until the others are done.

Related issue for D6 and D7 here:

#1211264: Set the view title to term name when filter argument is term id

In D8, the issue seems to continue. I am actually trying to override term pages for Products (Commerce). So, the Product entity doesnt have the usual "Has Taxonomy Term" filter. Instead I am using term field. When I try to override title, i am using twig as:

{{ arguments.field_kategori_target_id }}

I also do validation with Term ID and select "One or more IDs separated by , or +"

The title shows term ID instead of term NAME.

The ultimate goal of this issue is to remove \Drupal\Core\Messenger\LegacyMessenger entirely (which is deprecated and scheduled for removal prior to 9.0.0) and solely rely on the Messenger service.

If possible, 3rd party code should use the Messenger service or find alternative solutions that don't involve using this deprecated class.

If there is any 3rd party code that provides a legitimate use case for keeping this around, we may have to re-think how messages work (highly unlikely, but currently a complete unknown).

This is partially due to the fact that the drupal_set_message() and drupal_get_messages() proceedural functions have been around for over 14 years and usage of these functions was heavy throughout core, contrib and 3rd party code alike.

Thus, this issue also serves as a way to track usage of this deprecated class.

Use cases:

• Drush - Used when creating a new site and the container is not yet initialized. Unclear if this is a hard dependency or its code can be fixed, needs research

Problem/Motivation

#2156401: Write install_profile value to configuration and only to settings.php if it is writeable added a BC layer to read the install profile from settings.php instead of configuration. This can be removed in 9.x.

Proposed resolution

Remove

    else {
      // If system_update_8300() has not yet run fallback to using settings.
      $install_profile = Settings::get('install_profile');
    }

And simplify code.

Remaining tasks

User interface changes

API changes

None

Data model changes

None

After updading a Drupal site from 8.6.16 to 8.7.1 (PostgreSQL 9.6.13 , Nginx) I get this error in almost every operation (creating a view , installing a module, importing feeds, ....) with diferent plugins

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "{whatever}" plugin does not exist.
Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, any, float, string, boolean, timespan,[...]
in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 de /"
"/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

I use the drupal-project composer template so my update process was:

composer update --with-dependencies webflo/drupal-core-require-dev drupal/* "symfony/*" -d /<path/to/site> --no-interaction ;
cd /<path/to/site>
drush updb
drush cron
drush cr

It was not successfull, so I do this:

rm -rf vendor/*
composer update

and run again previous commands which It worked.

I though that I could be a problem with PHP version so I update from PHP 7.0 to PHP 7.3, but the error still remains.
I also thought that it could be related with a feeds module installation so delete all feeds content, feeds types, etc .. and unistall and reinstall the module several times (also run drush devel-entity-updates because drupal status report warned of a feeds field that needed to be deleted)

After see that the problem was related with multiples plugins I start looking for a more generic issue (config?, permissions?, ...) but I don't find cause/solution.

EDIT 1

Looking for a stack trace I try using drupal console:

drupal site:mode dev -v

and get this:

In DiscoveryTrait.php line 53:

  [Drupal\Component\Plugin\Exception\PluginNotFoundException]                                                                                                                                               
  The "system.performance" plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, any, float, string, boolean, timespan, language_reference, language, map  
  , binary, timestamp, list, datetime_iso8601, uri, integer, duration_iso8601, email, field_item:comment, field_item:datetime, field_item:daterange, field_item:file_uri, field_item:file, field_item:font  
  awesome_icon, field_item:image, field_item:link, field_item:list_integer, field_item:list_float, field_item:list_string, field_item:path, field_item:telephone, field_item:text, field_item:text_long, f  
  ield_item:text_with_summary, field_item:time_range, field_item:time, field_item:webform, field_item:email, field_item:uri, field_item:entity_reference, field_item:uuid, field_item:timestamp, field_ite  
  m:string_long, field_item:language, field_item:password, field_item:changed, field_item:float, field_item:decimal, field_item:map, field_item:boolean, field_item:integer, field_item:created, field_ite  
  m:string, entity, entity:block, entity:block_content_type, entity:block_content, entity:block_content:basic, entity:captcha_point, entity:comment, entity:comment:comment_forum, entity:comment_type, en  
  tity:contact_form, entity:contact_message, entity:contact_message:feedback, entity:contact_message:personal, entity:editor, entity:field_config, entity:field_storage_config, entity:file, entity:filter  
  _format, entity:image_style, entity:imce_profile, entity:language_content_settings, entity:configurable_language, entity:media_type, entity:media, entity:media:audio, entity:media:file, entity:media:i  
  mage, entity:media:remote_video, entity:media:video, entity:node_type, entity:node,[...], entity:node:page, entity:node:position, entity:rdf_mapping, entity:responsive_image_style, entity:rest_resource_config, entity:rules_reaction_rule, entity:rules_component, entity:s  
  earch_page, entity:shortcut_set, entity:shortcut, entity:shortcut:default, entity:action, entity:menu, entity:taxonomy_vocabulary, entity:taxonomy_term, entity:taxonomy_term:badge_type, entity:taxonom  
  y_term:categories, entity:taxonomy_term:forums, entity:taxonomy_term:materials, entity:taxonomy_term:nivel, entity:taxonomy_term:tags, entity:toolbar_menu_element, entity:tour, entity:user, entity:use  
  r_role, entity:webform_options, entity:webform, entity:webform_submission, [..], entity:menu_link_content, entity:pathauto_pattern, entity  
  :view, entity:base_field_override, entity:entity_view_mode, entity:entity_view_display, entity:entity_form_mode, entity:entity_form_display, entity:date_format, entity_reference

Exception trace:
 () at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php:53
 Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryCachedTrait.php:25
 Drupal\Core\Plugin\DefaultPluginManager->getDefinition() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/TypedData/DataDefinition.php:195
 Drupal\Core\TypedData\DataDefinition->getClass() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/TypedData/TypedDataManager.php:86
 Drupal\Core\TypedData\TypedDataManager->createInstance() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/TypedData/TypedDataManager.php:103
 Drupal\Core\TypedData\TypedDataManager->create() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/TypedConfigManager.php:394
 Drupal\Core\Config\TypedConfigManager->createFromNameAndData() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/StorableConfigBase.php:134
 Drupal\Core\Config\StorableConfigBase->getSchemaWrapper() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/StorableConfigBase.php:179
 Drupal\Core\Config\StorableConfigBase->castValue() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/Config.php:212
 Drupal\Core\Config\Config->save() at /home/"<user>"/www/"<site>"/vendor/drupal/console/src/Command/Site/ModeCommand.php:150
 Drupal\Console\Command\Site\ModeCommand->overrideConfigurations() at /home/"<user>"/www/"<site>"/vendor/drupal/console/src/Command/Site/ModeCommand.php:87
 Drupal\Console\Command\Site\ModeCommand->execute() at /home/"<user>"/www/"<site>"/vendor/symfony/console/Command/Command.php:255
 Symfony\Component\Console\Command\Command->run() at /home/"<user>"/www/"<site>"/vendor/symfony/console/Application.php:987
 Symfony\Component\Console\Application->doRunCommand() at /home/"<user>"/www/"<site>"/vendor/symfony/console/Application.php:255
 Symfony\Component\Console\Application->doRun() at /home/"<user>"/www/"<site>"/vendor/drupal/console-core/src/Application.php:184

EDIT 2

looking at the database I found two tables from feeds module (supposed to be uninstalled)

feeds_feed feeds_subscription

running drupal console commnand drupal debug:module feeds appears as the only module uninstalled with a schema version defined

ID     Name   Package  version      schema version  status      origin
...
feeds  Feeds  Feeds  8.x-3.0-alpha5    8001         Uninstalled no core
...

EDIT 3

After enable debugging (https://drupal.stackexchange.com/questions/127182/how-do-i-enable-develo...)

I got new clues about the error ( trying to create a view) but my lack of drupal core knowledge stops me from understanding where final cause is:

</br></br><em class="placeholder">Drupal\Component\Plugin\Exception\PluginNotFoundException</em>: The &quot;views.view.*&quot; plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, any, float, string, boolean, timespan, [...], entity:entity_form_display, entity:date_format, entity_reference in <em class="placeholder">Drupal\Core\Plugin\DefaultPluginManager-&gt;doGetDefinition()</em> (line <em class="placeholder">53</em> of <em class="placeholder">core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php</em>). <pre class="backtrace">Drupal\Core\Plugin\DefaultPluginManager-&gt;getDefinition(&#039;views.view.*&#039;) (Line: 195)
Drupal\Core\TypedData\DataDefinition-&gt;getClass() (Line: 86)
Drupal\Core\TypedData\TypedDataManager-&gt;createInstance(&#039;views.view.*&#039;, Array) (Line: 103)
Drupal\Core\TypedData\TypedDataManager-&gt;create(Object, Array) (Line: 394)
Drupal\Core\Config\TypedConfigManager-&gt;createFromNameAndData(&#039;views.view.test2&#039;, Array) (Line: 134)
Drupal\Core\Config\StorableConfigBase-&gt;getSchemaWrapper() (Line: 179)
Drupal\Core\Config\StorableConfigBase-&gt;castValue(&#039;uuid&#039;, &#039;c2f6326b-a77f-4f1e-9698-cb96154252cb&#039;) (Line: 212)
Drupal\Core\Config\Config-&gt;save() (Line: 284)
Drupal\Core\Config\Entity\ConfigEntityStorage-&gt;doSave(&#039;test2&#039;, Object) (Line: 449)
Drupal\Core\Entity\EntityStorageBase-&gt;save(Object) (Line: 263)
Drupal\Core\Config\Entity\ConfigEntityStorage-&gt;save(Object) (Line: 394)
Drupal\Core\Entity\EntityBase-&gt;save() (Line: 613)
Drupal\Core\Config\Entity\ConfigEntityBase-&gt;save() (Line: 993)
Drupal\views_ui\ViewUI-&gt;save() (Line: 191)
Drupal\views_ui\ViewAddForm-&gt;submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter-&gt;executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter-&gt;doSubmitForm(Array, Object) (Line: 590)
Drupal\Core\Form\FormBuilder-&gt;processForm(&#039;view_add_form&#039;, Array, Object) (Line: 319)
Drupal\Core\Form\FormBuilder-&gt;buildForm(Object, Object) (Line: 93)
Drupal\Core\Controller\FormController-&gt;getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer-&gt;executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel-&gt;handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel-&gt;handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle-&gt;handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache-&gt;pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware-&gt;handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware-&gt;handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel-&gt;handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel-&gt;handle(Object) (Line: 19)
</pre>

grep -nri "deprecated" core/modules/filter/
core/modules/filter//tests/src/Kernel/Migrate/d6/FilterFormatPermissionTest.php:37:   * @expectedDeprecation Passing a migration process plugin as the fourth argument to Drupal\filter\Plugin\migrate\process\d6\FilterFormatPermission::__construct is deprecated in drupal:8.8.0 and will throw an error in drupal:9.0.0. Pass the migrate.lookup service instead. See https://www.drupal.org/node/3047268
core/modules/filter//tests/src/Kernel/FilterLegacyTest.php:23:   * @expectedDeprecation filter_form_access_denied() is deprecated in Drupal 8.8.0 and will be removed before Drupal 9.0.0. Use \Drupal\filter\Element\TextFormat::accessDeniedCallback() instead. See https://www.drupal.org/node/2966725
core/modules/filter//filter.module:310: * @deprecated in drupal:8.8.0 and is removed from drupal:9.0.0. Use
core/modules/filter//filter.module:316:  @trigger_error('filter_form_access_denied() is deprecated in Drupal 8.8.0 and will be removed before Drupal 9.0.0. Use \Drupal\filter\Element\TextFormat::accessDeniedCallback() instead. See https://www.drupal.org/node/2966725', E_USER_DEPRECATED);
core/modules/filter//src/Plugin/migrate/process/d6/FilterFormatPermission.php:29:   * @deprecated in drupal:8.8.x and is removed from drupal:9.0.0. Use
core/modules/filter//src/Plugin/migrate/process/d6/FilterFormatPermission.php:61:      @trigger_error('Passing a migration process plugin as the fourth argument to ' . __METHOD__ . ' is deprecated in drupal:8.8.0 and will throw an error in drupal:9.0.0. Pass the migrate.lookup service instead. See https://www.drupal.org/node/3047268', E_USER_DEPRECATED);

Problem/Motivation

Entity token implementations do not consider that base fields may be translatable. node.tokens.inc only considers body and summary to be multilingual, not title, author, changed or created. (URLs are generated appropriate for the language though). taxonomy.tokens.inc does not consider any of the fields translatable, eg. title, description, URL, etc. are not displayed in the appropriate language.

Proposed resolution

1. Compile a list of affected tokens.
2. Load the appropriate translation like node.tokens.inc for body and summary.
3. Tests.

Remaining tasks

Review all tokens. Fix. Tests.

User interface changes

None.

API changes

None.

Data model changes

None.

Follow-up to #2225775: Migrate Drupal 6 core node translation to Drupal 8

Problem/Motivation

In D8, a node revision has data for all languages. In D6 and D7, each node revision has data for just one language. This means currently D6 -> D8 and D7 -> D8 migrations yield a revision history where each node revision has only one language present, even if previous revisions had translations. This is strange and likely to confuse users.

Priority is given to the D7 migration because the D6 one might be effected by the term node migrations.

This is for migrating core translation revisions, migrating revisions for entity translation is now being done in #3076447: Migrate D7 entity translation revision translations to D8. It is intended that this issue is completed first and then the approach used here is also used for entity translations.

Meeting notes

Things to consider, taken from notes of meeting with alexpott, Gábor Hojtsy, heddn, mikelutz and quiteone

1. Migration dependencies
   • Possible: easy to do
   • BC concerns: none
   • BC what about contrib? Commerce / metatag
   • Possible incompatible
2. How do we figure out you need the new complex master migration?
   • Possible: moderate to do
   • BC concerns: none
   • Don’t effect expose new d*_node_master unless explicitly enabled to existing sites
   • This handles incremental, no UI option available to enable
   • For new installs, give an option to upgraders to enable disable the new d*_node_master migration and use the old method.
3. What about migration lookups on dn_node etc.
   • Possible: easy to do
   • BC concerns: none
4. What about incremental migrations that have already begun
   • Not allowed. You can only use the new approach on a site that has not run migrations. So we need some of flag where existing installs use the old migrations.
5. Contrib/Custom
6. Does it make sense to use d*_node_master instead of d*_node migrations?

Proposed resolution

The current focus is to get the D7 version working and then move those changes to D6.

Using the existing method where the final revision is migrated first doesn't work instead the revisions need to be migrated in order. The first proof of concept patch to show this is in #121, thanks to mikelutz. This new approach is called Master and the migrations and files use that name.

"Removing it [the classic node migrations] will break the whole ecosystem. Deprecating it means that it’s not used anymore which in and of itself will break the eco system, and for what benefit? To remove it in Drupal 10, a year after D7 is EOL? At that point we are looking at deprecating the entire D7 upgrade path anyway (Probably for removal in 11, not 10) We really don’t want to break the migration ecosystem right now at this critical time when we are trying to get everyone off of D7 in the next 18-20 months". by mikelutz in #migration on Drupal Slack). See #3109819: [PP-2] Deprecate classic node migration plugin in Drupal 9 for removal in Drupal 10 for discussion of when deprecation of classic node migrations would happen.

Run master or classic node migrations
However, the Master approach doesn't integrate with the current migrations, now being called Classic, that is the one either runs the existing node migrations or the new master one, not both. Choosing between the two methods is done at run time by checking the node migration map tables in MigrationConfigurationTrait() and migrate_drupal_migration_plugins_alter(). In the trait the classic method is selected if any of the classic node migrate_map tables has data (using processedCount) and in the plugins_alter it is selected if any classic node migrate_map exists and there are no master node migrate_maps.

The selection of node migration method also allows tests to decide which method to use. The test does this by adding either 'node_migrate_classic' or 'node_migrate_master' to $modules.

Altered migrations
There are several migrations that use migration_lookup on the node migration. The processes and dependencies for these are alter when the master node migration is being run. That change includes new processes to convert the 3 destination ids returned by master node to the correct 1 destination id expected when using the classic migration.
The migrations altered are: d6_term_node, d6_term_node_revision, d6_term_node_translation, d6_comment, d6_url_alias,d7_comment, d7_url_alias, statistics_node_counter, node_translation_menu_links

Incremental migrations
Because the node migration method is selected at run time it will continue to use the existing migration type for future incrementals.

From the original IS
D6 and D7 node revisions do not directly indicate which other translated node revisions they are associated with. But we can attempt to guess this, based on the order of revisions.

Remaining tasks

Fix tests, add comments
Review

For Reviewers

• All level of code reviews welcome.
• There are BC issues raised in meeting notes, above

For Testers

1. Use the lastest patch patch in this issue.
2. There are instructions in the Issue summary of the META issue #2208401: [META] Stabilise Migrate Drupal Multilingual module

From #55

For developers

1. Make this work with a multilingual source and a non multilingual source
2. Discuss and document implications for drush, especially drush migrate-upgrade --all
3. Make sure the d6 and d7 tests includes testing a fields on each revision
4. Handle the case where the vid of the first revision is higher the vid of a later revision. This is true for both d6 and d7.
5. Make sure that the use of migration_tag 'translation' is documented. It is used in
   • d6_node_translation.yml
   • d7_node_entity_translation.yml
   • d7_node_translation.yml
   • d7_node_revision_translation.yml
   • d7_user_entity_translation.yml
   • d7_taxonomy_term_entity_translation.yml/li>
   • d7_comment_entity_translation.yml
   • d6_node_revision_translation.yml
6. Make sure that the source plugin 'translation' property is documented
7. Make sure that the destination plugin 'translations' property is documented

Content Moderation module adds a Moderated content view, which is showing error message

No valid values found on filter: Content revision: Moderation state.

This is because of the misconfiguration of the second unexposed moderation state filter.

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

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

For more informations, see the change record.

Right now the users are allowed to set their own time zone - this lead to several issues with international editorial teams - untick permission on /admin/config/regional/settings

As of January 30th, Drupal Infrastructure deployed the official method for building all of the tarballs for drupal 8.8 and higher using composer create-project to leverage the templates that instead of using git-archive.

As a side effect of this, we realized that we had introduced a subtle change to the way that "development tarballs" are produced.

The subtle change is that the -dev versions of the tarballs are not getting "locked" versions of the core -dev dependencies, and are allowed to float to the most recent version of the dev deps.

Those affected are users who are both
A. Using the development version of the tarballs for 8.8.x-dev/8.9.x-dev/9.0.x-dev and
B. Using any of the "dev" functions of core, like running phpunit etc.

The impact of this is that the users may end up with results that differ from core has in their development process.

We have a few choices on how to mitigate this issue:

• A. Leave it this way, tell people that -dev dependencies will no longer be 'pinned' to what core tested against, and let the deps float. (Zero Work)
• B. Change the drupal/legacy-template to use the drupal/core-dev-pinned metapackage, which would pin the development version to the exact version that core ships with. The disadvantage is that anybody using composer to start on a dev version of core, using the 'legacy-template', they will have difficulties/complexities upgrading to a newer version of core that contains updates to the development dependencies.
• C. Change the subtree splitter that generates the lockfiles for drupal/legacy-template so that it gets the pinned versions of the dev dependencies that ship with core. (This implies that composer users starting with -dev versions will have to include --no-dev if they do not want development versions)
• D. Stop providing the require-dev dependencies into the -dev tarballs. (See: #3086489: Exclude development libraries from templates' composer.json by default)

A cursory analysis of the analytics (users using browsers, downloading tarballs from drupal.org) shows that 8.8.x-dev has only had ~ 600 total downloads since march. (I didnt pull the actual web logs as they're in glacier, and that costs money to retrieve to analyze)

We don't have any evidence or known use cases of users showing that the development dependencies in the dev tarballs are necessary to their workflow. We only really know that they are there now, so its plausible that somebody, somewhere, has a workflow that needs it. (https://xkcd.com/1172/)

11qaz

Release note

As of February 1, 2020, this development tarball may contain versions of Composer development dependencies (like PHPUnit and Coder) updated from the particular versions specified Drupal core's composer.lock file. This only affects sites installing the development tarball and then using the included development tools. Development tarballs are not recommended for use on production sites as development tools may not meet security requirements.

Problem/Motivation

There are various problems with the update xml in core/modules/update/tests/modules/update_test

These problem don't make the test fail but should be fixed

For example

1. aaa_update_test.8.x-1.2.xml should not have version_* tags
2. aaa_update_test.1_2-alpha1.xml has a release with both <tag>DRUPAL-8--1-1-alpha1</tag> and <version>8.x-1.2-alpha1</version>

There are probably others.

The doc for this feed is https://www.drupal.org/drupalorg/docs/apis/update-status-xml

Proposed resolution

Identify all problems and fix

Remaining tasks

Patch

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

None

Problem/Motivation

#3096078: Display core compatibility ranges for available module updates was committed before a usability review.

It adds a lot of (mostly duplicate) text to the available updates report:

We should try to improve the UX of this info because it's:

a) Important.
b) Likely to grow larger and more complex over time.

Proposed resolution

• Make "not compatible" a details that replaces download link
• Add a details under download link for compatible releases

Remaining tasks

1. UX review.
2. Brainstorm solutions.
3. Implement them. Initial prototype in #26
4. Improve implementation, remove @todo's, etc.
5. Update / fix failing tests.
6. Adding new tests?
7. Fix styling.
8. Reviews:
   • UX
   • Code / implementation
9. RTBC.
10. Commit.
11. Followup for the 9.0 Usability review of the major version update
12. Followup to do a UX review of the update status report once other semver work is implemented in core and on Drupal.org as a part of #3110198: [META] Beta targets following Drupal 9.0.0-beta1

User interface changes

Initial, ugly prototype from #26 (screenshots from Seven):

Compatible

Initial

Open

Incompatible

Initial

Open

API changes

Probably nothing public. Some changes to @internal API of some update classes (esp ProjectCoreCompatibility).

Data model changes

N/A

Release notes snippet

TBD. Probably not needed since this is just cleaning up another feature that hasn't yet been released.

Problem/Motivation

In #3087644: Remove Drupal 8 updates up to and including 88**, we noticed that using that hook_update_last_removed() is not actually that strictly enforced (it requires to have an update function), doesn't actually show what's going on and just displays a warning message, together with a success message:

Proposed resolution

Add something to system_requirements() that checks for that explicitly, for all modules implementing such a hook. Display an error with clear infos and don't allow users to continue in that case.

Remaining tasks

• Update the wording after #48: "Updating to Drupal 9 is only supported from Drupal version 8.8.0 or higher. If you are trying to update from an older version, first update to the latest version of Drupal 8." Consider making "latest version" or "latest version of Drupal 8" a link, as discussed in #51, #53.
• Update the "after" screenshot.
• Add a screenshot for the error message from a non-core module. Consider changing "earlier" to "intermediate".

User interface changes

(copied from #40)

Before:

you only get a warning that doesn't prevent you from doing the update and that warning only shows up on a later step when the updates are listed:

After:

Update.php stops on the requirements page and displays an error that doesn't allow you to continue:

API changes

Data model changes

Release notes snippet