Problem/Motivation

There is ENTITY_TYPE_list cache tag and it is being invalidated very often. For example, if we have 20 different content types and created views page to display the list of content for each type, then whenever editor adds/edits/deletes one of the content - all 20 views pages will be invalidated BUT only related should be invalidated, others still have no changes. So, it means that on current sites if somebody changes something then Drupal will clear cache for almost the entire website.

Proposed resolution

Add bundle specific list cache tags - ENTITY_TYPE_list:BUNDLE
For example:

• If the node listing is empty then add node_list tag.
• If the node listing is only showing single bundle(page) then add node_list:page tag.
• If the node listing is showing more than one bundle then add node_list tag.

Also:

• Rename getListCacheTags to getListCacheTagsToInvalidate.
• Add getListCacheTags in the follow up where we determine bundle specific cache tag based on query object.

so that listing pages can add bundle specific list cache tags or generic list cache tags

Remaining tasks

1. Write tests as per #93.5
2. Create follow-ups.
3. Create change record.
4. Open issues for views, search_api and other modules that will require an update.

Original report by [effulgentsia]

Follow up from #1712456: How to leverage cache tags in Views.

Two problems:

1. That issue changed EntityViewBuilder::resetCache() from just clearing the TYPE:ID tag to also clearing the TYPE_view_BUNDLE tag. However, what is the meaning of this tag? What does it mean to "view" a bundle? #1712456-50: How to leverage cache tags in Views says "Say you save settings for one node type, it would invalidate caches for every node on the system?!", so ok, if the intent of this tag is to clear caches upon a change to the settings of a bundle, then why is it being cleared upon the saving of a single entity, which is when EntityViewBuilder::resetCache() is called? OTOH, the same comment also says We need a way like this to invalidate 'lists' containing this entity type. This and 'view' could be similar though I guess.. Hm, if the 'view' here refers to lists (where Views module is the most common list generator) rather than to the 'view' in the sense of EntityViewBuilder, then let's rename this tag to 'list' instead. If we then also want a per-bundle 'view' tag for clearing when bundle settings change in a way that would affect their display, then that's what we should use 'view_BUNDLE' for, but then clear it only where bundle settings are managed (e.g., EntityDisplay) rather than in EntityViewBuilder::resetCache().
2. If we do rename this to TYPE_list_BUNDLE, then how should we handle Views that are cross-bundle? For example, currently in HEAD, if I enable tag-based caching on the front page View, then visit the front page at a time when only Article nodes are promoted to the front page, then I add a Page node and promote it, it doesn't show up on my front page until I manually clear caches. Perhaps we need a non-bundle-specific TYPE_list tag as well, and add that to all cross-bundle Views, but not to Views and EFQ listings that we know are bundle-specific?

Problem/Motivation

We are updating eslint as part of #3101543: Update core JavaScript dependencies listed in package.json.

It seems like eslint 5.4.0 introduced .eslintrc overrides, and for that reason, .eslintrc files are being read from subfolders.

There's an invalid .eslintrc.json file in the scaffold fixtures which leads to following error message:

Failed to read JSON file at /Users/lauri.eskola/Projects/drupal/core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/drupal-assets-fixture/assets/.eslintrc.json.

Proposed resolution

Make the file a valid .eslintrc.json file so that it doesn't lead into an error.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

We should update all of core's remaining JavaScript dependencies prior to 9.0.0-beta1, including any major version updates that may be available. This includes dependencies listed in package.json.

Proposed resolution

Here's a table of all core JavaScript dependencies in the package.json, and the latest versions of the packages.

Major

Minor

Patch

Remaining tasks

Problem/Motivation

Many functions declare a return of a boolean value (TRUE or FALSE). Some of these return the result of the preg_match function.

 * @return bool
 *   TRUE if the string is a valid hexadecimal CSS color string, or FALSE if it
 *   isn't.
 */
function color_valid_hexadecimal_string($color) {
  return preg_match('/^#([a-f0-9]{3}){1,2}$/iD', $color);
}

However preg_match() function returns 1, 0 or FALSE.

 * @return int|false <b>preg_match</b> returns 1 if the <i>pattern</i>
 * matches given <i>subject</i>, 0 if it does not, or <b>FALSE</b>
 * if an error occurred.
 * @since 4.0
 * @since 5.0
 */
function preg_match ($pattern, $subject, array &$matches = null, $flags = 0, $offset = 0) {}

Proposed resolution

Check the result type:

return preg_match($regex, $value) === 1;

Sorry if I'm posting this issue in the wrong place, but I was only able to fix the problem on Core level as you can see it in the patch.

Reproduce

1. Install the Paragraphs with composer and enable it.
2. Install Inline Entity Form module with composer and enable it.
3. Apply the patch from https://www.drupal.org/project/inline_entity_form/issues/3015323, patch: https://www.drupal.org/files/issues/2018-11-26/3015323-3.patch
4. Enable the core Workflows module.
5. Create a basic Paragraph type (Paragraph Test).
6. Create a new content type (Bar) with a Paragraph field (Paragraph field) that uses the previously created paragraph type (Paragraph Test) set it not to be required.
7. Create a new content type (Foo) with a Reference field (Inline form), referencing the previously created content type (Bar).
8. Choose the 'Inline Entity Form - Complex' widget for the field (Inline form), in the Form display page.
9. Create a new workflow (Moderation) apply it to the previously created content type (Foo).

Steps to reproduce:

1. Add a new content for the Bar content type do not add a paragraph yet
2. Add a new content for the Foo content type and load the existing Bar entity into the Inline form field
3. Save the entity
4. Go back to the Foo entity's edit page and open the Inline form field's referenced Bar entity with the Edit button
5. Click on the Add new paragraph button in the Paragraph field named field
6. Nothing should happen which is the sign that the problem exists
7. Check the Network tab in the Browser's developer tool and you will see the Internal Server error message.

Expected behavior

The expected behavior is that the Add new paragraph button adds the paragraph fields to the form.

Proposed solution

I've created a patch, where the EntityTypeInfo.php's entityPrepareForm method is "fixed".
The problem was that the $entity and the $form_object->getEntity() objects were not the same in case when I used the Inline Entity Form.
And the method only checked if the $form_object is moderated entity form or not, but didn't check if the $entity itself is a moderated entity or not. I also added the $form_object->getEntity() === $entity so this way only the correct entity will get the new revision.

That is the point where I'm uncertain about that the problem lays here at the Content moderation module or in the Inline Entity Form, because the $entity comes from the latter one. I think the content moderation module should check if the received $entity is moderated and belongs to the current form object or not. This way the default behavior persists and the Inline Entity Form incompatibility is fixed, because the module won't try to create a new revision for the wrong entity and won't overwrite the entity in the $form_object.

Problem/Motivation

I have been pretty inactive over the past year as a now role in my career has left me less directly connected with Drupal and specifically core contribution. Therefore I think it's best I withdraw as maintainer for Node, Statistics, and Content Moderation.

Proposed resolution

Remove timmillwood from MAINTAINERS.txt

Remaining tasks

Write a patch

User interface changes

Tears

API changes

Sadness

Data model changes

Pride

Release notes snippet

👋🏻

In the fight against spam more and more ISP's require mail send though the php function to originate from the main domain. The contact form however uses the senders email as "from:" address.

I'd like to see a field in settings to optionally set a fixed "from address" (for example contactform@domain.tld) and use "reply-to" to enable replies to the sender, while still using the fixed from address which is accepted by the isp.

Current Status

This issue was fixed for Drupal 8: committed to the 8.3.x branch on 2 August 2016 and the 8.4.x branch on 27 January 2017.

As of 29 October 2017, the issue is RTBC for Drupal 7, so it may be fixed in an upcoming release of Drupal 7.

Until then, you can either apply the patch from this issue or use a contrib module to get the same effect. One module mentioned in the comments below is Contact Reply-To. There may be other options.

Updating from Drupal 8.7.10 to 8.8.0, When I do drush updb, I get the following errors:

 [notice] Update started: field_group_post_update_0001
>  [notice] Update completed: field_group_post_update_0001
>  [notice] Update started: views_post_update_limit_operator_defaults
>  [error]  The "media" entity type does not exist.
>  [error]  Update failed: views_post_update_limit_operator_defaults
 [error]  Update aborted by: views_post_update_limit_operator_defaults

How do I recover?

Every once in awhile, a new dependency gets added to a module, for example #3084983: Move all the code related to path aliases to a new (required) "path_alias" module added path_alias as a dependency to the path module.

When this happens, as in the above example, trying to import configuration which had been exported with a previous version of Drupal will result in:

[error]  Drupal\Core\Config\ConfigImporterException: There were errors validating the config synchronization.
Unable to uninstall the <em class="placeholder">Path alias</em> module since the <em class="placeholder">Path</em> module is installed. in Drupal\Core\Config\ConfigImporter->validate() (line 755 of /var/www/html/core/lib/Drupal/Core/Config/ConfigImporter.php). 

This is because, in the core.extension.yml generated before the new dependency was added, we have (in this example):

   path: 0

but not:

   path_alias: 0

So Drupal tries to enable path but disable path_alias; which fails. Thus, configuration which was fully acceptable with a previous version of Drupal (before the new dependency) is now corrupted (unusable) and needs to be regenerated with "drush config-export" to be valid again.

Upon enabling modules based on a core.extension.yml file, could we compute the dependencies automatically so that whether or not we have "path_alias: 0" in core.extension.yml, we would enable it? The code to do so already exists in ModuleInstaller::install.

Problem/Motivation

One major piece of functionality from the D7 Entity Reference module was left out entirely in #1801304: Add Entity reference field: the ability to render exposed views filters as a select list or autocomplete of available entities.

Proposed resolution

Generalize the taxonomy module's TaxonomyIndexTid plugin to be available for all entity reference fields and migrate the existing taxonomy filters to be based on the new generic filter plugin.

How to use

1. Add on an entity type / bundle an entity reference field, ex field_test_reference.
2. Create a view displaying this entity type.
3. Add a filter on the view for field_test_reference.
4. Configure the entity selection mode and the widget display mode.
5. Configure the filter behavior (ex: required, multiple, etc.)
6. Finally use the filter field for filtering the results based on the selected entity from the autocomplete or select list.

Remaining tasks

• ☑ support for content entity reference
• ☑ support for configuration entity reference
• ☑ support for content with and without bundles
• ☑ taxonomy filter rebased on generic entity reference
• ☑ settings forms to configure the filter
• ☑ display widget in select or autocomplete
• ☑ filter values based on reference view
• ☑ filter values based on bundles
• ☑ maximum filter values in select list for performance concerns
• ☑ sort for filter values when in bundle selection handler mode
• ☑ argument support for when view selection handler is used
• ☑ views configuration schema update
• ☐ existing configuration migration
• ☐ fix select option (#208, #215)
• ☑ tests

Post tasks

• ☐ conversion of the "authored by" filter to use the entity reference filter
• ☐ extract selection handler form logic in separate plugins that will specialize for rendering and validating the filter selection config form
• ☐ caching of the value form?
• ☐ documentation updates

User interface

Known issues

• CANNOT REPRODUCE ATM sometimes when switching between widget it gets stuck on the previous selected one
• FIXED when switching between the widget types the previous value is left in the exposed form and it's incompatible with the other widget type
• FIXED triggering ajax requests on the extra options form right after adding the filter brings you back to the add handler form fixed

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

Contextual module's js files read Press the esc key to exit., but it should be Press the Esc key to exit.. A patch is on the way.

Problem/Motivation

The string '_none' is repeated throughout the module and tests, using a constant makes it easier to refactor.

Proposed resolution

1. Convert _none to a constant.
2. Move form_select_options() to a helper class.

API changes

String '_none' is converted to constant.

Beta phase evaluation

I am not sure if this is a bug but have isolated that the issue appeared with RC4. I read the notes in the jsonapi.api.php about the new access testing that RC4 introduced and that's what is causing the API to return no data.

First - here is the API Request. The filedepot_folder content type is very basic but has a entity reference back to itself in order to represent a nested file folder structure. In this case, we are looking for all folder nodes that don't have the parent_folder field set -- ie: are top level root folders.

• This worked fine up to RC4 and continues to work if the client app is logged in as Admin "uid 1"
• Does not work even if the client user has the administrative role
• Works if I grant Bypasss content access control permission to the client user

http://{site_url}/jsonapi/node/filedepot_folder?sort=-nid&fields[node--filedepot_folder]=title,uid,field_parent_folder,changed,drupal_internal__nid&include=uid,field_parent_folder&fields[user--user]=name,mail&filter[folder][condition][path]=field_parent_folder.id&filter[folder][condition][operator]=IS%20NULL&page[limit]=50

Result:

{
   "data":[

   ],
   "jsonapi":{
      "version":"1.0",
      "meta":{
         "links":{
            "self":{
               "href":"http:\/\/jsonapi.org\/format\/1.0\/"
            }
         }
      }
   },
   "links":{
      "self":{
         "href":"http:\/\/d8react2.ddev.local:8080\/jsonapi\/node\/filedepot_folder?fields%5Bnode--filedepot_folder%5D=title%2Cuid%2Cfield_parent_folder%2Cchanged%2Cdrupal_internal__nid\u0026fields%5Buser--user%5D=name%2Cmail\u0026filter%5Bfolder%5D%5Bcondition%5D%5Boperator%5D=IS%20NULL\u0026filter%5Bfolder%5D%5Bcondition%5D%5Bpath%5D=field_parent_folder.id\u0026include=uid%2Cfield_parent_folder\u0026page%5Blimit%5D=50\u0026sort=-nid"
      }
   }
}

Tested with enabling all content view related permissions, including contact and user-information. Also tested API without the uid and 'user--user' fields - same result.

But if I use a different [operator] and filter condition, then the query works and data is returned.

http://d8.6.5.ddev.local:8080/jsonapi/node/filedepot_folder?sort=-nid&fields[node--filedepot_folder]=title,uid,field_parent_folder,changed,drupal_internal__nid&include=uid,field_parent_folder&fields[user--user]=name,mail&filter[folder][condition][path]=field_parent_folder.id&filter[folder][condition][operator]=%3D&filter[folder][condition][value]=f71b6e54-71c5-4cda-8861-cd9e67f4f604&page[limit]=50

Is this a bug or usage issue?

Thanks!

Hi,

I'm having problems doing modules updates on drupal 8.7.10 and upgrade to 8.8.0.
I have some 8 modules to update but all attempts to make module updates fails at database update process.
The module page indicate that the module is updated but the database update didn't occur. Seems that the something is blocking the database update process.

The bug may be related to "ckeditor media embed plugin" or "asset injector" modules because I got that errors : (I changed my site name with mysite.com)

mod_fcgid: stderr: PHP Fatal error: Class 'Drupal\\Console\\Core\\Command\\Command' not found in /var/www/vhosts/mysite.com/modules/ckeditor_media_embed/src/Command/InstallCommand.php on line 31, referer: https://mysite.com

Now that I tried the drupal core upgrade nevertheless, my site is inaccessible and I get that errors in the server :

Non-zero exit status returned by script. Output stream: 'PHP Fatal error: Class 'Drupal\Console\Core\Command\Command' not found in /var/www/vhosts/mysite.com/modules/ckeditor_media_embed/src/Command/InstallCommand.php on line 31
'. Error stream: 'PHP Fatal error: Class 'Drupal\Console\Core\Command\Command' not found in /var/www/vhosts/mysite.com/modules/ckeditor_media_embed/src/Command/InstallCommand.php on line 31

Has anybody faced that issue ? Can you help me with it ? (I can recover the entire web site to give more clues.)

Regards.

Scenario

Migrating a D7 list text field to a D8 list text field. The field is a select field so only one value can be selected. Some of the D7 list fields values were never set (it was not required). In D8, the field is now required so I want to set the default value during the migration for any of those fields that never had a value on the D7 site.

The list text field has three possible values ("top", "bottom" and "center") and we want "center" to be the default if nothing was ever set on the D7 site. Here is the migration config for the process plugin.

field_hero_image_position:
  plugin: default_value
  default_value: center
  source: field_banner_image_position

Expected Behavior

The expected behavior is that the migration will migrate over the content from the D7 field to the D8 field if it is set. However, in the event that it was not set, the default_value plugin should be run in which case it would determine the value to be empty and therefore use center as the default value.

How to Reproduce

Migrate a D7 list text field with unset values (I am not sure if this applies to any other field type) to a D8 list text field and try to apply a default value during the migration.

If you remove the source line from the migration configuration. The default_value plugin works as expected and the default is set on the field.

Why it's happening (see code snippets below)

1. MigrateExecutable.php calls the processRow method for each row. This loops through each field and plugin. In this case we have one field but it sets the field as having two plugins (Get and DefaultValue).
1. The Get process plugin runs first, and tries to grab the value but there is no value set, so it sets $value to an empty array.
2. The process then sets the $multiple variable to TRUE. This is important because it controls what happens in the next iteration of the loop.
3. On the second iteration of the loop, the code falls into the first if statement since $multiple variable is now TRUE.
4. Since $value is an empty array, the process skips over the foreach and the DefaultValue process plugin is never called.
5. This causes the default value of any fields that were not set on the D7 site to remain null/empty on the D8 site.

Here is the relevant code from the processRow method in MigrateExecutable.php. You should be able to follow the steps above and see what is happening.

foreach ($plugins as $plugin) {
  $definition = $plugin->getPluginDefinition();
  // Many plugins expect a scalar value but the current value of the
  // pipeline might be multiple scalars (this is set by the previous
  // plugin) and in this case the current value needs to be iterated
  // and each scalar separately transformed.
  if ($multiple && !$definition['handle_multiples']) {
    $new_value = [];
    if (!is_array($value)) {
      throw new MigrateException(sprintf('Pipeline failed at %s plugin for destination %s: %s received instead of an array,', $plugin->getPluginId(), $destination, $value));
    }
    $break = FALSE;
    foreach ($value as $scalar_value) {
      try {
        $new_value[] = $plugin->transform($scalar_value, $this, $row, $destination);
      }
      catch (MigrateSkipProcessException $e) {
        $new_value[] = NULL;
        $break = TRUE;
      }
    }
    $value = $new_value;
    if ($break) {
      break;
    }
  }
  else {
    try {
      $value = $plugin->transform($value, $this, $row, $destination);
    }
    catch (MigrateSkipProcessException $e) {
      $value = NULL;
      break;
    }
    $multiple = $plugin->multiple();
  }
}

Here is the relevant code for the Get process plugin. I think pretty much any field will be returned as an array and will therefore set the $multiple variable to TRUE.

public function transform($value, MigrateExecutableInterface $migrate_executable, Row $row, $destination_property) {
    $source = $this->configuration['source'];
    $properties = is_string($source) ? [$source] : $source;
    $return = [];
    foreach ($properties as $property) {
      if ($property || (string) $property === '0') {
        $is_source = TRUE;
        if ($is_source) {
          $return[] = $row->getSourceProperty($property);
        }
      }
      else {
        $return[] = $value;
      }
    }

    if (is_string($source)) {
      $this->multiple = is_array($return[0]); //This is where multiple is set to TRUE
      return $return[0];
    }
    return $return;
  }

The Solution

Since I don't completely understand how the Migration process is working, I don't know the best way to fix this without potentially negatively impacting something else.

There may be an alternative solution with a different process plugin. I am also not sure if this is intended behavior but if it is, then I believe this behavior should be documented more clearly.

original D8 issue: #728702: Visiting index.php should redirect to install.php if settings.php already has database credentials but database is empty.

Problem/Motivation

If the user visits the site index for a Drupal site that has database credentials in settings.php but has not yet been installed completely, the user will receive a fatal error that does not in any way indicate that the user should visit install.php to complete the installation.

Proposed resolution

Detect an empty database during bootstrap, and redirect to install.php if installation is not already in progress.

Patch in #728702-17: Visiting index.php should redirect to install.php if settings.php already has database credentials but database is empty. is confirmed to resolve this issue for both D7 and D8.
see patch in this issue rerolled from #728702-36: Visiting index.php should redirect to install.php if settings.php already has database credentials but database is empty.

Remaining tasks

None.

User interface changes

User will be redirected to install.php if there is a database configuration but the database is empty.

API changes

None.

Original report by @arpeggio

The setup are:
-database empty
-drupal updated from CVS
-set the C:\xampp\htdocs\sites\sites.php with $sites['localhost'] = 'kapitbisig.com';
-manually populated the the database credentials in C:\xampp\htdocs\sites\kapitbisig.com\settings.php

I got the following error message when I browsed http://localhost

Fatal error: Call to undefined function _system_rebuild_theme_data() in C:\xampp\htdocs\includes\theme.inc on line 586

ISSUE DESCRIPTION:

When a user create new tag (or any other) term, through attached field in a content editor form, for non-default language, the tag term is created in default language and not in a language of the current node.

ENVIRONMENT:

OS/web server: All
Drupal version: v8.8.1

REPRODUCIBILITY: Always

STEPS TO REPRODUCE:

- Let's suppose that English is default language

- Add new language (e.g. Spanish)

- Enable translation for both, content (e.g. Article) and Tag taxonomy

- Attach a tag field to Article

Now, we want to create a new Article in spanish language only and also to create new tag term ("noticias") linked to this spanish version of the content

- Create new Article content

- Select Spanish in the language dropdown and fill all other required fields

- Create new tag term (e.g. "noticias") in the Tag field and save the content

- List all created tag terms on Structure > Taxonomy > Tags and find "noticias" term

- Click the edit > translate, and a table of all translations will be displayed (e.g. English and Spanish in our case)

EXPECTED BEHAVIOR:

Term "noticias" is created in spanish language because the content has been created in spanish, too. The english version should have translation as "n/a" and status as "not translated"

ACTUAL BEHAVIOR:

Term "noticias" is created in default (english) language only, while spanish is marked as not translated.

Problem/Motivation

Steps to reproduce:

1. Install standard in German
2. Enable config_translation
3. Add the english language
4. Edit the standard profile to not have an standard_install() and add keep_english: true to its .info.yml file
5. Export the configuration using drush
6. Re-install the site using drush site-install with the --existing-config flag.

You'll see an error like

 [info] Undefined index: id ConfigurableLanguageManager.php:312 [16.45 sec, 58.13 MB]
 [info] Undefined index: id ConfigurableLanguageManager.php:312 [16.45 sec, 58.13 MB]
 [info] Undefined index: id ConfigurableLanguageManager.php:312 [16.45 sec, 58.13 MB]
 [info] Undefined index: id ConfigurableLanguageManager.php:312 [16.45 sec, 58.13 MB]
 [info] Undefined index: id ConfigurableLanguageManager.php:312 [16.45 sec, 58.13 MB]
 [info] Undefined index: id ConfigurableLanguageManager.php:312 [16.45 sec, 58.13 MB]
 [info] Undefined index: id ConfigurableLanguageManager.php:312 [21.25 sec, 62.74 MB]
 [info] Undefined index: id ConfigurableLanguageManager.php:312 [21.25 sec, 62.75 MB]
 [info] Undefined index: id ConfigurableLanguageManager.php:312 [21.25 sec, 62.75 MB]
 [info] Undefined index: field_type FieldConfigStorageBase.php:25 [22.66 sec, 76.9 MB]
 [info] Undefined index: field_type FieldConfigStorageBase.php:28 [22.66 sec, 76.94 MB]

In FieldConfigStorageBase.php line 28:

  [RuntimeException]
  Unable to determine class for field type '' found in the 'field.field.' configuration

Proposed resolution

The problem is caused by container invalidation not causing a reboot. In a non-interactive install container invalidation shouldn't occur because we don't know what the next task is going to do with the container.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Drupal 9 will come with a new version of Stable. Initially, the plan was to replace the old Stable with a new Stable theme, which essentially would force all themes to upgrade to the next Stable theme as part of the major version upgrade. Upgrading Stable can be cumbersome. Given that upgrading to the next Stable theme comes with very little benefits, it seems unlikely that themes would be interested in upgrading unless they are forced to do so.

Proposed resolution

1. Make base theme a require property in themes: #3065545: Deprecate base theme fallback to Stable
2. Copy current Stable to contrib project so that it can be used with Drupal 9. There's already a namespace reserved for this.
3. Create a new Stable theme with a new name for Drupal 9, following almost the same steps used to create Drupal 8 Stable in #2575737: Copy templates, CSS, and related assets to Stable and override core libraries' CSS
   1. Automated test for library overrides to ensure completeness
   2. Automated test for template overrides to ensure completeness
   3. Copy all the CSS, changing image paths as necessary
   4. Copy all the images, no changes No benefit to this step, they'll get copied when it becomes contrib, though.
   5. Add all the libraries-override needed to stable's .info.yml
   6. Copy all the templates, with appropriate doc changes
4. Deprecate the Drupal 8 Stable theme in Drupal 9 to be removed in Drupal 10.

Remaining tasks

• Agree on maintainers of the contrib project
• Copy code from Stable to the new project
• Decide what happens to Classy which depends on Drupal 8 Stable
• Agree on a name for the Drupal 9 Stable: #3094440: [policy, no patch] Agree on name for Drupal 9's Stable theme
• Create the Drupal 9 Stable theme and copy all the templates and assets to the new theme
• Deprecate Drupal 8 Stable

User interface changes

API changes

Data model changes

Release notes snippet