Problem/Motivation

In #2916898: Do not use basic_html text format for 'No log messages available.' message the config entity core/modules/dblog/config/optional/views.view.watchdog.yml was wrong updated. The text_area plugin was updated with the configuration of a text_area_custom plugin, but the plugin itself is still the text_area plugin instead of text_area_custom plugin. See #2916898-41: Do not use basic_html text format for 'No log messages available.' message.
This can cause several issues. For example when installing sites in languages different than english, locale_system_set_config_langcodes() function will try to save views.view.watchdog component and will raise an error like:

Placeholders must have a trailing [] if they are to be expanded with an array of values.

Proposed resolution

To have a patch following same approach as dblog_update_8600 did, but changing the plugin type to the proper one.

Remaining tasks

1. Confirm that changing the plugin area type solves the issues. See comment #2998103-15: dblog_update_8600() not working on sites with non-en default language - leads to PHP warning on admin/reports/dblog or #2998103-45: dblog_update_8600() not working on sites with non-en default language - leads to PHP warning on admin/reports/dblog
2. Create a patch, taking in account the commit that introduce this issue. See #2916898-36: Do not use basic_html text format for 'No log messages available.' message

Original report by [quixxel]

We are trying to determinate the causes of this issue.

In case you need an urgent fix. See #29

Hi,
I upgraded four different sites to Drupal 8.6. They all are Thunder installs. Then I updated them to Thunder 2.24 and on all sites I'm getting the following error:

  Warning: Illegal string offset 'value' in Drupal\views\Plugin\views\area\Text->preQuery() (Zeile 50 in .../core/modules/views/src/Plugin/views/area/Text.php)
  #0 .../core/includes/bootstrap.inc(584): _drupal_error_handler_real(2, 'Illegal string ...', '/home/www/doc/3...', 50, Array)
  #1 .../core/modules/views/src/Plugin/views/area/Text.php(50): _drupal_error_handler(2, 'Illegal string ...', '/home/www/doc/3...', 50, Array)
  #2 .../core/modules/views/src/ViewExecutable.php(1011): Drupal\views\Plugin\views\area\Text->preQuery()
  #3 .../core/modules/views/src/ViewExecutable.php(1233): Drupal\views\ViewExecutable->_preQuery()
  #4 .../core/modules/views/src/Plugin/views/display/PathPluginBase.php(390): Drupal\views\ViewExecutable->build()
  #5 .../core/modules/views/src/Plugin/views/display/Page.php(180): Drupal\views\Plugin\views\display\PathPluginBase->execute()
  #6 .../core/modules/views/src/ViewExecutable.php(1630): Drupal\views\Plugin\views\display\Page->execute()
  #7 .../core/modules/views/src/Element/View.php(77): Drupal\views\ViewExecutable->executeDisplay('page', Array)
  #8 [internal function]: Drupal\views\Element\View::preRenderViewElement(Array)
  #9 .../core/lib/Drupal/Core/Render/Renderer.php(378): call_user_func(Array, Array)
  #10 .../core/lib/Drupal/Core/Render/Renderer.php(195): Drupal\Core\Render\Renderer->doRender(Array, false)
  #11 .../core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(226): Drupal\Core\Render\Renderer->render(Array, false)
  #12 .../core/lib/Drupal/Core/Render/Renderer.php(582): Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}()
  #13 .../core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(227): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
  #14 .../core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(117): Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch))
  #15 .../core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php(90): Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch))
  #16 [internal function]: Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
  #17 .../core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
  #18 .../vendor/symfony/http-kernel/HttpKernel.php(156): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent))
  #19 .../vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
  #20 .../core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
  #21 .../core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
  #22 .../core/modules/page_cache/src/StackMiddleware/PageCache.php(99): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
  #23 .../core/modules/page_cache/src/StackMiddleware/PageCache.php(78): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
  #24 .../core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
  #25 .../core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
  #26 .../vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
  #27 .../core/lib/Drupal/Core/DrupalKernel.php(665): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
  #28 .../index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
  #29 {main}.

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
...

For my site I'm having to add more granularity for Language support. So instead of Traditional Chinese we opted to create custom languages for Hong Kong and Taiwan.

It would be nice to create custom languages and allow the custom language to be utilize Drupal's UI translation packs. and keep up to date with UI translations.

From what I see there is currently not a way to associate a custom language to a language pack.

Problem/Motivation

Following #3051352: [Plan] Remove unused jQuery UI components and replace with a suite of contrib packages for the continuous upgrade path we need to actually deprecate all the unused jQuery UI components in core, pointing to a change record which will in turn point to the contrib modules and how to update dependencies.

Proposed resolution

For jQuery UI components that are not used by core, deprecate them entirely in core and move them to contrib. This would be done via a set of contrib projects so that a security issue in one component doesn't require a security release for unrelated components.

Some utilities could be grouped under a main jquery_ui project.

These modules could consist of an info and libraries file and the specific js or css currently in core/assets/vendor/jquery.ui.

example folder structure:

jquery_ui_[component]
 |_jquery.ui
 |  |_ui
 |  |  |_widgets
 |  |    |_[component]-min.js
 |  |
 |  |_themes
 |    |_base
 |      |_[component]-min.css
 |
 |_jquery_ui_[component].info.yml
 |_jquery_ui_[component].libraries.yml

example info file:

name: jQuery UI Droppable
type: module
description: 'Provides jQueryUI Droppable library.'
package: jQuery UI
core: 8.x
dependencies:
    - jquery_ui
    - jquery_ui_draggable        

The libraries file would be identical to what is currently in core.libraries.yml except for updated paths to files and dependent libraries.

Proposed list of modules, starting with the modules that can be currently marked deprecated:

• jquery_ui - this project page already exists but has not had activity since jQuery UI went into core. It would be great if we could use this as the namespace for this new module.
  It could include jQuery "core" files as well as some utilities depended on by the other libraries.
  • jquery.ui
  • jquery.ui.widget (required by nearly all the other libraries)
  • jquery.ui.mouse (required by slider, selectable, draggable)
  • jquery.ui.position (required by selectmenu, tooltip)
• jquery_ui_accordion - jquery.ui.accordion
• jquery_ui_button - jquery.ui.button - not in the deprecated list but required by spinner.
• jquery_ui_checkboxradio - jquery.ui.checkboxradio
• jquery_ui_controlgroup - jquery.ui.controlgroup
• jquery_ui_draggable - jquery.ui.draggable - not in the deprecated list but required by droppable.
• jquery_ui_droppable - jquery.ui.droppable
• jquery_ui_effects - since the individual effects depend on jquery.ui.effects.core it's more convenient to package them together.
  • jquery.ui.effects.core
  • jquery.ui.effects.blind
  • jquery.ui.effects.bounce
  • jquery.ui.effects.clip
  • jquery.ui.effects.drop
  • jquery.ui.effects.explode
  • jquery.ui.effects.fade
  • jquery.ui.effects.fold
  • jquery.ui.effects.highlight
  • jquery.ui.effects.puff
  • jquery.ui.effects.pulsate
  • jquery.ui.effects.scale
  • jquery.ui.effects.shake
  • jquery.ui.effects.size
  • jquery.ui.effects.slide
  • jquery.ui.effects.transfer
• jquery_ui_menu - jquery.ui.menu - not in the deprecated list but required by selectmenu.
• jquery_ui_progressbar - jquery.ui.progressbar
• jquery_ui_selectable - jquery.ui.selectable
• jquery_ui_selectmenu - jquery.ui.selectmenu
• jquery_ui_slider - jquery.ui.slider
• jquery_ui_spinner - jquery.ui.spinner
• jquery_ui_tooltip - jquery.ui.tooltip

Remaining tasks

None.

User interface changes

None.

API changes

A number of jQuery UI asset libraries are deprecated. See the change record and proposed resolution.

Data model changes

None.

Release notes snippet

jQuery UI asset libraries that are not used by Drupal core have been deprecated.

When I try to update Drupal from 8.4.0 to 8.6.1 I got the following error

Module Views
Updating table_display_cache_max_age

Fail: InvalidArgumentException: Placeholders must have a trailing [] if they are to be expanded with an array of values. in Drupal\Core\Database\Connection->expandArguments() (line 729 of /http/xxx/site/core/lib/Drupal/Core/Database/Connection.php).

When I run node data through either the Drupal serializer service...

$thisSerializer = \Drupal::service('serializer');
$serializedData = $thisSerializer->serialize($nodedata, 'xml', ['plugin_id' => 'entity']);

or when I use the Drupal UI to create a REST View, it works really well except for fields which have multiple responses. For example, if I have a field called "dates", it serializes them like this:

<field_dates>
  <value>
    2019-08-24
  </value>
</field_dates>
<field_dates>
  <value>
    2019-09-20
  </value>
</field_dates>
<field_dates>
  <value>
    2019-10-13
  </value>
</field_dates>

I can't imagine any system which parses data like this. Unless you are writing a custom parser for this data, this output would be useless. For a recent project, I was forced to write my own controller to re-configure the array before serializing it.

This is what the output should be:

<field_dates>
  <field_date>
    <value>
      2019-08-24
    </value>
  </field_date>
  <field_date>
    <value>
      2019-09-20
    </value>
  </field_date>
  <field_date>
    <value>
      2019-10-13
    </value>
  </field_date>
</field_dates>

or something similar. It should be noted that figuring out what the child key should be called might not be something left to Drupal to figure out, but defaulting to the singular form of the parent field id isn't a terrible start. If someone is using the Drupal REST View, the child key could be an option when you're building your references in the ui.

Now, I am using `getListBuilder('node')` to build the array, but I've not been able to find any helpful tutorials on how to use the eleven new functions that are replacing it or if those functions have fixed this problem in any way. If there's anything out there, I'd love to hear about it.

Thanks!

Problem/Motivation

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

Proposed resolution

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

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

Remaining tasks

Don't see for now.

User interface changes

No changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

You cannot create a view and try to list rendered entities using relationship.

Steps to reproduce (based on Standard profile):

1. Add an entity reference field named "field_content" to the "page" content type. Allow content > article references.
2. Create and edit a content view.
3. Add a relationship for "Content using field_content." or "Content referenced from field_content."
4. The row style plugin is "Content" by default.
5. Click on "Teaser" in order to change the view mode, nothing happens.
6. You can't choose a view mode even if you don't want to actually use a relationship, just having one on your view triggers this.

The problem is a fatal AJAX error triggered when RowPluginBase::buildOptionsForm() calls RelationshipPluginBase::init() while providing a wrong argument type (Array instead of DisplayPluginBase).

Argument 2 passed to Drupal\views\Plugin\views\relationship\RelationshipPluginBase::init() must be an instance of Drupal\views\Plugin\views\display\DisplayPluginBase, array given, called in /app/web/core/modules/views/src/Plugin/views/row/RowPluginBase.php on line 93

Proposed resolution

Fix it, by passing along the relationship as needed and using it.

Remaining tasks

None.

User interface changes

None

API changes

None

I would like to have json views output with fields in way, that field would be processed with twig. I would like to have views output similar to this:

nid:
node_type:
teaser_view: (template processed view with HTML tags..)
node_view: (template processed view with HTML tags..)

I think in conjunction with the JavaScript this could be very strong functionality. How I understand json views module, it does not work with twig at all? Can I achieve it with some snippet?

Thank you a lot

Problem/Motivation

As a site administrator, I want to exclude certain modules from deployments, in order to not put developer tools on my production environment.
While #3048860: Create Config Environment API and the other issues around the Configuration Environment module aim to substitute Config Split, by making environments config entities and exporting their configuration as collections, it is sometimes just simpler not to share the development modules configuration and instead making sure that development modules are guaranteed from being excluded from the configuration export.

Proposed resolution

Add Config Exclude to core.

Remaining tasks

Agree whether to add the functionality to Config Environment or add a new module.

User interface changes

none

API changes

New setting for modules that are excluded from the configuration export and remain installed on import that doesn't have them.

$settings['config_exclude_modules'] = ['devel', 'stage_file_proxy'];

Data model changes

none

Release notes snippet

A new setting allows development modules to be excluded from the configuration export.

Problem/Motivation

The default action on /admin/content is "Delete selected content". It's really easy to push "Apply" button by mistake, thinking it will apply the filter, because of the button title, and because it's positioned at the bottom of the form, typically where people expect to look for submit buttons. (This actually happened to me today, and I've been using Drupal for 8 years.)

Proposed resolution

• Use the D7 sort order (#3)
• Make the default action something safer (or make the default a no-op).
• Change the "Apply" button back to "Update" (like D7), "Execute", or even something action specific ("Delete").

Proposed alternatives

Alternatives for order of operations. The first operation in a list is the default.

Alternative 1: D7-like

• Publish content
• Unpublish content
• Promote content to front page
• Remove content from front page
• Make content sticky
• Make content unsticky
• Delete content
• Save content

Variation: Unpublish as default, by swapping Publish and Unpublish. This has the same Cons. For consistency the other operation pairs should also be swapped.

Alternative 2: Safe default

• - None -
• Publish content
• Unpublish content
• Delete content
• Save content
• Promote content to front page
• Remove content from front page
• Make content sticky
• Make content unsticky

Variation: Place Delete and Save at the bottom of the list as in D7.

Alternative 3: Safe first

• Make content sticky
• Make content unsticky
• Promote content to front page
• Remove content from front page
• Publish content
• Unpublish content
• Delete content
• Save content

Variation: Use Promote/Demote as first operation pair.

Remaining tasks

• Implement the suggestion in Comment #75
• Fix the failing tests: see Comment #72
• Make follow-up to delete the Save content option

User interface changes

Yes!

API changes

N/A

Problem/Motivation

D7 follow-up for #2859297: Migrate taxonomy term references for D6 Node translations.

This issue is about the references from the migrated Node translations to the terms.

Proposed resolution

Write the migration in the same fashion as we did for D6 in #2859297: Migrate taxonomy term references for D6 Node translations.

The scope of this issue is the reference from the node translation to the taxonomy term.

Test case 1 when using 'Localized' vocabulary together with 'Node translation' concept.

• Have two node entities in Drupal 7, one in English (nid A) and one for example in Finnish (nid B). Associate these as translations of each other.
• Have one taxonomy term in Drupal 7 which is translated in Drupal 7 using the 'Localized' concept.
• Make sure that both English and Finnish versions of the Drupal 7 node have a reference to the term.

Expected result:

• The Finnish language version of the node is migrated as a translation to the English node. In other words, there were 2 nodes in Drupal 7 but there will only be 1 node in Drupal 8.
• Both language versions of the Drupal 8 node must have a reference to the term.

Implementation in D7 fixture: TODO, document here which terms and nodes are used in the fixture tests.

Test case 2 when using 'Translated' vocabulary.

• Have two node entities in Drupal 7, one in English and one for example in Finnish. Associate these as translations of each other.
• Have two taxonomy terms in Drupal 7. The vocabulary must have the 'Translate' multilingual setting. Both taxonomy terms will have their language defined.
• Make sure that the English node has a reference to the English term in Drupal 7.
• Make sure that the Finnish node has a reference to the Finnish term in Drupal 7.

Expected result:

• The Finnish language version of the node is migrated as a translation to the English node. In other words, there were 2 nodes in Drupal 7 but there will only be 1 node in Drupal 8.
• When viewing the English version of the Drupal 8 node (original language of the node), it must have a reference to the English term.
• When viewing the Finnish translation of the Drupal 8 node, it must have a reference to the Finnish term.

Implementation: TODO, document here which term and node are used in the fixture tests for this test case.

Remaining tasks

Patch
Test & Review
Commit

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Problem/Motivation

Follow up to #2949964: Add an EntityOwnerTrait to standardize the base field needed by EntityOwnerInterface.

The EntityTest entity should use EntityOwnerTrait.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

The current way of associating a revision with a workspace has a couple of problems:

- the association history is lost when a workspace is published to Live, because we delete all entries from the workspace_association tables
- when we introduce workspace hierarchies, operations on the workspace_association entities will be either 1) very costly, because we have to update all the associations of a workspace as well as its descendants, or 2) bypass the Entity API completely, which makes the current implementation completely unnecessary overhead :)

Proposed resolution

- track the workspace in which a revision was created in a (revision metadata) base field
- convert the workspace_association entity type to a custom index table

Remaining tasks

Discuss, agree on the proposed resolution, write upgrade path and tests.

User interface changes

Nope.

API changes

The workspace_association will be a service in the container instead of an entity type.

Data model changes

All entity types supported by Workspaces will have an additional revision metadata (reference) field: workspace

Release notes snippet

TBD.

Problem/Motivation

Issues we're trying to solve

• core: 8.x in an info file is restrictive
• we invented our own dependency syntax that is overly complex because of the optional core major version
• we want to move away from having the major version in the module version (e.g. 8.x-1.x » 1.0.0)
• we want to move core away from version: VERSION so we can do subtree splitting
• we want contrib modules to be able to declare their composer dependencies - e.g my module 1.3 needs symfony/yaml 4.0
• as a bonus, themes could rely on modules

@sun suggested this in #1936886-21: Rename $module.info.yml into extension.yml

Proposed resolution

use composer.json for

• discovery of themes/modules/profiles/engines
• dependency declaration
• version numbering

Deprecate the dependencies, type and version keys in info.yml files

Remaining tasks

Wind back to the scope of comment #39

User interface changes

API changes

Data model changes

API page: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Component%21Date...

See for instance https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Component%21Date.... The '@see __construct()' is not forming a link.

Problem/Motivation

As part of the general clean-up of the File API, file_save_htaccess() and file_ensure_htaccess() need to be deprecated and moved into services.

Proposed Resolution

Move this functionality into a service called htaccess, then turn both of these functions into wrappers around that service.

Problem/Motivation

I have Drupal 8.4.3 installed along with a lot of other modules. When clearing the caches via the UI (specifically routing and links cache or plugin cache - others are okay), or one of these cache-clears is triggered via another operation then opening the views overview page, or editing any view returns this error: -

The view entity type did not specify a list_builder handler. in Drupal\Core\Entity\EntityTypeManager-getHandler() (line 236 of core/lib/Drupal/Core/Entity/EntityTypeManager.php)

Running drush cr resolves the issue, until next time a non-drush cache-clear happens.

Problem/Motivation

Some of the test topics, test modules, and tests in Help Topics are relying on production help topics, or linking to production help topics. This could cause problems if one of the production help topics changes, gets deleted, etc.

Proposed resolution

Make it so the tests and test modules for Help Topics are completely decoupled from production topics.

Remaining tasks

Make a patch.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

Drupal\Tests\system\Functional\Mail\MailTest() has a number of test functions that depend on the simpletest module.

The test should not depend on simpletest, since it's a BrowserTestBase test, and since we want to get rid of simpletest.

Proposed resolution

Add a fixture module to the system module's tests that will implement hook_mail_alter(), and have the test depend on that.

Remove simpletest_mail_alter().

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet