If you enable Content Moderation along with the Lightning Workflow transitions, and create a user with permission that can create and edit a specific content type but only allows them to View Latest Version and View Own Unpublished Content, they will be unable to view a new revision for content they did not originally create. Immediately after saving they will be presented with an Access Denied screen.

Here are the permissions said user has:

permissions:
  - 'access content'
  - 'access content overview'
  - 'access contextual links'
  - 'create and edit custom blocks'
  - 'create page content'
  - 'edit any page content'
  - 'use editorial transition create_new_draft'
  - 'use editorial transition review'
  - 'use moderation sidebar'
  - 'view latest version'
  - 'view own unpublished content'
  - 'view page revisions'

The issue appears to be due to the fact that the user cannot view the latest revision because the original content was not authored by them. The fix is to assign them the permission "View any unpublished content", but this is not desirable as they can then access unpublished content for bundles they technically should not have access to.

Looking through the code the offending line may be this:
File: core/modules/content_moderation/src/Access/LatestRevisionCheck.php
Lines: 63-64
Code:

$owner_access = AccessResult::allowedIfHasPermissions($account, ['view latest version', 'view own unpublished content']);
$owner_access = $owner_access->andIf((AccessResult::allowedIf($entity instanceof EntityOwnerInterface && ($entity->getOwnerId() == $account->id()))));

Alter this to be the following so the revision UID is also checked means that this method now returns TRUE for a newly created revision, but the Access Denied message is still returned.

$owner_access = AccessResult::allowedIfHasPermissions($account, ['view latest version', 'view own unpublished content']);
$owner_access = $owner_access->andIf((AccessResult::allowedIf($entity instanceof EntityOwnerInterface && ($entity->getOwnerId() == $account->id() || $entity->getRevisionUserId() == $account->id()))));

I expected the above change to be the only thing needed to get this working, but evidently not. Is this an actual issue or is there an alternative method to get this working without modifications to the code?

This meeting:
• happens every Tuesday at 8:00 am PT
• Is done over Hangouts
• happens in threads so keep an eye on those notifications

Problem/Motivation

Classy will be moved to contrib before Drupal 9 and we have to remove dependencies on Classy from all core themes.

Proposed resolution

Use this spreadsheet of Core Theme's use of Classy as reference

Refactor Classy libraries Determine if each core theme should receive a copy of these libraries or if they can be centralized.

Copy all remaining Templates and CSS that are not already overridden by the theme and remove dependency to Classy. Note that some templates in Classy are identical to Stable and may not require copying.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Because input formats have changed between Drupal 6/7 and 8, AFAICS in all cases, you get your node/comment titles moved over, but the bodies display as blank:

The data for the fields is in the database, but getting stripped out on the front end.

#3061571: Set filter format in migrations to fallback filter, rather than filter_null, so that body fields show up proposes setting the bodies to plain text vs. an empty string, which would be one way of dealing with this, and a fairly simple patch if the proposal is accepted.

A more complex but more comprehensive fix would be to allow developers to make this mapping themselves, both through the UI and via Drush. Then the code doesn't need to perform any guess work, and potentially get it wrong (e.g. by accidentally exposing database credentials in plain text).

Major because this represents a pretty significant usability hurdle, and harms user confidence in the system early on. However, not tagging Migrate critical because the particular solution here will likely be tricky and we don't want to hold up stability of the overall migration system over it. (If the other issue gets won't fixed by the security team, I guess we might need to revisit this.)

Proposed resolution

Thanks to #2876085: Before upgrading, audit for potential ID conflicts, we now have an "audit" step in the migrations, so we could maybe piggy-back off of that. (Though sounds like that's pretty one-off, so we may instead want to do #3061676: Create an audit plugin class/manager for migrations and have this be one of the plugins.)

@todo come up with mockup.

Remaining tasks

• Find a suitable design
• Find a suitable Drush equivalent
• Write a patch + tests
• Review it
• Commit it!

User interface changes

By default, migrations will now display the proper content for body fields on nodes and comments. (As well as other rich text fields.)

API changes

?

Data model changes

N/A?

Release notes snippet

Migrations now default to the fallback filter format, fixing a problem where rich text fields were not displaying post-migration.

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.

Problem/Motivation

I have a local 8.8.x dev site.
It lives at http://localhost/drupal-8_8
When I try to run core/modules/file/tests/src/Functional/FileFieldWidgetTest.php locally, it fails with 5 of these:

1) Drupal\Tests\file\Functional\FileFieldWidgetTest::testSingleValuedWidget
Behat\Mink\Exception\ExpectationException: Current response status code is 404, but 200 expected.

When I use run-tests and inspect the HTML output, I see this:

GET request to: http://localhost/drupal-8_8/drupal-8_8/sites/simpletest/93134289/files/2019-11/text-0.txt

Notice the double "drupal-8_8" in there?

Digging a bit deeper, each of the calls that fails is something like this:

  $this->drupalGet($node_file->createFileUrl());

Looking at core/modules/file/src/Entity/File.php we find this:

  public function createFileUrl($relative = TRUE) {

So somehow, using relative file links in the test is confusing phpunit + run-tests.sh for me.

Proposed resolution

Invoke createFileUrl() with FALSE to always get absolute links, instead of relying on relative links.

Remaining tasks

1. Do it.
2. Make sure it doesn't break anything (passes locally).
3. Review.
4. RTBC.
5. Commit.

User interface changes

-

API changes

-

Data model changes

-

Release notes snippet

-

Problem/Motivation

Entities created through the UI are validated (required fields confirmed to be present, field values confirmed to be in proper ranges, etc.) through form validation - the entity API (save()) does not do validation, so if migrated data is to be validated it needs to be done explicitly. As benjy says:

I think we've discussed this elsewhere but no, entity->save() doesn't cause validation, you have to do $entity->validate() for that which opens up a can of worms with migrate.

Still, no reason not to permit those who choose to do so to open that can...

Proposed resolution

Add a "validate" option to entity destinations - when true, call $entity->validate().

destination:
  plugin: entity:node
  validate: true

Remaining tasks

1. Write the code (should take about 2 minutes).
2. Write tests (slightly longer).

User interface changes

N/A

API changes

Adds a configuration option to entity destinations.

Data model changes

None.

Release notes snippet

The ability to validate content entities during a migration is available. On the destination just set validation: true. See https://www.drupal.org/node/3073707 for more info.

If you try to use #ajax on a Views exposed filter form element, the callback is never invoked. This was discussed at length in the Views issue queue here:

#1183418: Ajax attached to exposed filters in form_alter doesn't trigger callback

The same bug exists in the version of Views in Drupal 8 core. As merlinofchaos wrote:

Views are $_GET forms and they specifically remove the form_id and form_build_id and form_token because they are 'submitted' even when they aren't submitted. That means the standard #ajax tools don't work with them, since those rely on being able to cache the form in core's form cache. That system is to naive to work with core's filters. I've never really tried to do anything like this in D7 yet, so I don't know what the solutions might be, but I can say that it's going to provide very ugly URLs if you hack the form id back in.

The proposed solution is to add a little custom JS magic so that we identify all the form info via after_build callbacks, stash those in JS settings, and then inside the JS, we reattach the relevant form info to the #ajax-enabled form elements so that their callbacks can be properly invoked.

I'm not sure if this is a bug or I'm just doing something wrong so I've tagged it as support for now.

I'm trying to make a custom views filter plugin that uses ajax in the form. It's a multi-vocabulary term select - the user selects a vocabulary then selects a term from that vocabulary from an ajax-populated list.

However, I'm encountering several bizarre issues while trying to set it up. If I provide the ajax callback as [$this, 'updateTerms'] it gives me this ajax error in preview:

A fatal error occurred: Recursion detected

Ajax never even runs in the full view. In this case the widget is not rendered at all and the error occurs even on the first load of the widget.

If I provide the ajax callback as either '::updateTerms' or 'Drupal\de_vocabulary_level_views_filter\Plugin\views\filter::updateTerms' it gives me this error in the views preview:

A fatal error occurred: The specified #ajax callback is empty or not callable.

and, inexplicably, this error on the full view:

An unrecoverable error occurred. The uploaded file likely exceeded the maximum file size (8 MB) that this server supports.

This issue occurs even on a fresh minimal install of Drupal 8 core with no extra modules or configuration besides enabling taxonomy, views, views_ui and the custom module itself and adding the filter to a view.

The form is pretty simple and works outside of views.

The form is provided in the valueForm function (though I've had the same results inside buildExposedForm) which is overridden like so:

  /**
   * {@inheritdoc}
   */
  protected function valueForm(&$form, FormStateInterface $form_state) {
    $vocabularies = $this->vocabularyStorage->loadMultiple();
    $vocab_options = array();

    foreach ($vocabularies as $voc) {
      $vocab_options[$voc->id()] = $voc->label();
    }

    $form['value'] = [
      'vocab' => [
        '#title' => $this->t('Vocabulary'),
        '#type' => 'select',
        '#options' => $vocab_options,
        '#empty_option' => $this->t('- Any -'),
        '#empty_value' => NULL,
        '#default_value' => !empty($form_state->get('vocab')) ? $form_state->get('vocab') : NULL,
        '#ajax' => [
          'event' => 'change',
          'callback' => 'Drupal\de_vocabulary_level_views_filter\Plugin\views\filter::updateTerms',
          'wrapper' => 'de-vocabulary-level-views-filter-terms-wrapper'
        ],
      ],
      'de_vocabulary_level_views_filter' => [
        '#title' => $this->t('Term'),
        '#type' => 'select',
        '#empty_option' => $this->t('- Any -'),
        '#empty_value' => NULL,
        '#default_value' => !empty($form_state->get('term')) ? $form_state->get('term') : NULL,
      ],
      '#prefix' => '<div id="de-vocabulary-level-views-filter-terms-wrapper">',
      '#suffix' => '</div>',
    ];

    if (!empty($form_state->getValue('vocab'))) {
      $term_query = $this->entityQuery->get('taxonomy_term')
        ->condition('status', 1)
        ->condition('vid', $form_state->getValue('vocab'));
      $term_query_result = $term_query->execute();
      $terms = $this->termStorage->loadMultiple($term_query_result);
      $term_options = [];
      foreach ($terms as $term) {
        $term_options[$term->id()] = $term->label();
      }
      $form['value']['de_vocabulary_level_views_filter']['#options'] = $term_options;
    }
  }

There's a small ajax callback:

  public function updateTerms(&$form, FormStateInterface $form_state) {
    return $form[$this->options['expose']['identifier']];
  }

Currently it reloads a section of the form from the base of the filter form but the same results occur treating it as if it was just the bit from valueForm.

Problem/Motivation

This is step one of #3087227: [META] Split up and refactor MediaLibraryTest, to make the very large and disruptive MediaLibraryTest more manageable and docile.

Proposed resolution

Split MediaLibraryTest into several smaller tests that make sense, sharing a common base class containing helper methods. The actual testing business logic should NOT be changed in this issue.

Remaining tasks

The thing I just said.

User interface changes

None.

API changes

None. MediaLibraryTest is not an API.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

Follow-up from #2745797: Add option to content entity destinations for validation
Relevant discussion at https://youtu.be/9rBkBl4uGlg?t=1265

Discussion on whether we can make entity validation the new default in migrations, and how we can do that.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Over in #2913196: "Link type" option, to support email links, it was raised by numerous people that the lack of support for email links in Drupal 8's CKEditor is a) a regression from Drupal 7, and b) no suitable workaround exists; either editors have to manually add "mailto:" in HTML source view, or they can install a contrib module such as https://www.drupal.org/project/editor_advanced_link which ends up providing two identical link buttons, leading to confusion and frustration.

At the same time, a lot of work was done in Drupal 8 to simplify the WYSIWYG UX for content authors, and that includes the link field in CKEditor, which has moved from a litany of choices for the user to make to instead a simple text field to paste into, and we would rather not step back from that.

Proposed resolution

Following patterns established by apps such as Google Docs and WordPress, add processing "behind the scenes" so that if text that matches an email address pattern is pasted into the CKEditor link field, it automatically gets converted into a "mailto:" link. Examples:

Google Docs

WordPress

Remaining tasks

1. Discuss
2. Implement
3. Ensure test coverage for edge cases

A follow-up could be to do a similar detection for "Anchor" links, but this was not cited as frequently used in the other issue.

User interface changes

Should hopefully be none.

API changes

Don't think so?

Data model changes

N/A

Release notes snippet

CKEditor now supports autocreation of email links in the link dialog.

Create a view using fields, add a relationship to an entity. Note that the base field from the related table gets add the the select clause in the sql query.

This added field can prevent using DISTINCT to remove duplicate records from the query results.

Problem/Motivation

With the following issues

1. #2807145: [policy, no patch] Allow contrib projects to specify multiple major core branches
2. #2313917: Core version key in module's .info.yml doesn't respect core semantic versioning
3. #3009338: [META] Support semantic versioning for extensions (modules, themes, etc) in Drupal core

We will not be able to tell if a module is compatible with a specific version or even a major version by the prefix 8.x- or 7.x-.

When all these issues are done a new contrib module created after these changes could have these releases:

• 1.0.0 that is compatible with Drupal 8
• 1.1.0 which compatible with Drupal 8.8 and above(not drupal 9
• 1.2.0 that is compatible with Drupal ^8.8 and 9
• 1.3.0 that is compatible with only Drupal 9

Currently with the metadata in the update xml from Drupal.org there would be no way of telling if these releases would work with the current major version of Drupal.

If a site is running Drupal 8 should they be shown all these updates?

Should we do #3074998: Add explicit information about core compatibility to update data so that Drupal core can filter out some of these?

In these example releases above any one of these updates could be a security release that makes the previous releases insecure.

If we decide not to show releases that are not compatible with the current version of core we should probably show them in any case if they are security releases.

If we decide to show all releases regardless of whether they are compatible with the current major version of Drupal core should there at lease be some message to tell the site owner that they will have to upgrade to the next major version of Drupal to update the module.

It could be possible for site that some of the contrib modules haven't been updated to Drupal 9 and some have and some are only compatible with Drupal 9. If the available updates report shows all of these without any indication of what state each module is in this could be very confusing.

Proposed resolution

In the near term we need a solution for #3009338: [META] Support semantic versioning for extensions (modules, themes, etc) in Drupal core and the fact that all modules will no longer have core: 8.x in their info.yml files. If don't make any change except to use the CURRENT option that drupal.org offers for update XML the user will likely be shown contrib updates that are not compatible with there major version of Drupal(8 for now) without any indication of this.

Near term solution

As first step we should

1. Switch to the new CURRENT option that drupal.org offers for update XML.
2. in #3074998: Add explicit information about core compatibility to update data add a new core_compatiblity value for each update. This is will be based on core_version_requirement or if not available it will be based core: 8.x

   This is will be for the project not individual modules in the project. Details to be determine in that issue

3. Display a message for each available project update that displays the core compatiblity range based on 1) actual available updates the update module has retrieved from the update server and 2) the core_compatiblity for the project update xml(see above)
4. For most common possibilities for core_compatiblity this will be able to displayed as a simple range.

   For example
   Installed core: 8.8.3
   latest 8.x patch release: 8.9.1
   Drupal 9 not released yet
   project xml core_compatiblity: ^8 || ^9

   This module is compatible with Drupal core: 8.8.3 to 8.9.1

   If Drupal 9.0.3 had been released this would change to

   This module is compatible with Drupal core: 8.8.3 to 9.0.3

   if project xml wascore_compatiblity: ^: ^8.8.9 || ^9 (not using core_version_requirement because the value will be directly from the project xml not the info.yml files)
   This module is compatible with Drupal core: 8.8.9 to 9.0.3

5. Some less common values for core_compatiblity will not be able to display by a simple range. In that case we should display them in a series of ranges.

   For example
   Given:
   Installed core: 8.8.3
   latest 8.8.x: 8.8.7
   latest 8.x patch release: 8.9.1
   Drupal 9 not released yet

   core_compatiblity: ~8.8.0 || ^9

   This module is compatible with Drupal core: 8.8.3 to 8.8.7

   Because 9 hasn't been released it won't come into play.

   If Drupal 9.0.3 had been released

   This module is compatible with Drupal core: 8.8.3 to 8.8.7 and 9.0.0 to 9.03

6. In this first step no modules will be filtered out of the list.

   This will mean hypothetically you could get projects updates with the message like

   This module is compatible with Drupal core: 9.0.0 to 9.0.5

   In the near term this is very unlikely because 1) Drupal 9 is not out so no module should be compatible with it but not Drupal 8 and 2) 9.0.0 should be compatible with 8.9.0 for modules not using deprecated code. Therefore any module that is compatible with 9.0.0 because it remove deprecations should also be compatible with 8.9.0. So the project would likely have this in the project xml
   core_compatiblity: ^8.9 || ^9 or core_compatiblity: ^8.8 || ^9

All of this could be done in #3009338: [META] Support semantic versioning for extensions (modules, themes, etc) in Drupal core because it doesn't make sense to switch to the update xml without providing messages for the new updates return by the XML which might not be compatible with the install major version.

But another option to keep each issue scope smaller would be to create new issue to be done first: Display core compatibility ranges for all module available updates
This would useful in itself because it would tell you if the update was compatible with your current minor.

Next step

After the above is we should determine if we want to filter out updates that aren't compatible with either your current core minor and/or your current core major version

Many steps down the road

Determine if the is way to display the updates compatiblity in way that considers not just core compatibility but also other module compatiblity and other composer dependencies.

Remaining tasks

Everything

User interface changes

Probably report changes

API changes

TBD

Data model changes

TBD

Release notes snippet

TBD

This error occurs when an exposed sort has been added to a view, and an exposed filter is subsequently added. When the filter identifier is validated, Drupal\views\Plugin\views\display\DisplayPluginBase->isIdentifierUnique() runs through all handlers and the line

$id != $key && $identifier == $handler->options['expose']['identifier']

throws the notice since exposed sorts don't have this option.

This seemed to be an issue in D7 views as well (see #1456836: AJAX HTTP error: Undefined index: identifier in is_identifier_unique()).

A straight forward fix would be to check if that option is set but there's probably a nicer solution, potentially only iterating over handlers that have the identifier option in the first place?

Punctuation is cool, we should use it and improve legibility of interfaces.

Before

After

Affected

• Taxonomy select
• Menu parent select
• Book outline select

There is a @todo note about this.

@todo When \Drupal\Core\Config\TypedConfigManager has been fixed to use
class-based definitions, type-hint $definition to
DataDefinitionInterface. https://www.drupal.org/node/1928868

We can go ahead now as #1928868: Typed config incorrectly implements Typed Data interfaces is resolved.

What are the steps required to reproduce the bug?

1. Create a custom module with its own package.json with a dependency on @babel/core^7.7.2
2. Create a nightwatch test and tag it.
3. Run the following from the core directory: "yarn test:nightwatch --tag my_test"

What behavior were you expecting?

The test would run and core does not try to transpile my custom module code.

What happened instead?

I get this error message:

Error: Requires Babel "^7.0.0-0", but was loaded with "6.26.3". If you are sure you have a compatible version of @babel/core, it is likely that something in your build process is loading the wrong version. Inspect the stack trace of this error to look for the first entry that doesn't mention "@babel/core" or "babel-core" to see what is calling Babel.
    at throwVersionError (/www/sites/site/web/modules/custom/module/node_modules/@babel/helper-plugin-utils/lib/index.js:65:11)
    at Object.assertVersion (/www/sites/site/web/modules/custom/module/node_modules/@babel/helper-plugin-utils/lib/index.js:13:11)
    at _default (/www/sites/site/web/modules/custom/module/node_modules/@babel/plugin-proposal-class-properties/lib/index.js:13:7)
    at /www/sites/site/web/modules/custom/module/node_modules/@babel/helper-plugin-utils/lib/index.js:19:12
    at Function.memoisePluginContainer (/www/sites/site/web/core/node_modules/babel-core/lib/transformation/file/options/option-manager.js:113:13)

You can see that core's babel is interacting with my custom module. I think this is because of the babel-register command that is run as part of the test:nightwatch script in core's package.json. It does this according to the docs:

One of the ways you can use Babel is through the require hook. The require hook will bind itself to node's require and automatically compile files on the fly. This is equivalent to CoffeeScript's coffee-script/register.

I think it's a bug because I don't want core trying to transpile my custom module's code as the module already does that itself.

Problem/Motivation

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

Proposed resolution

Add a field plugin to handle Drupal 7 node reference fields.

Remaining tasks

• Write the field plugin
• Write tests of said plugin
• Update the Drupal 7 fixture with a node reference field or two
• Update our integration tests to ensure that the node reference fields and their configurations are migrated correctly
• Update other integration tests to ensure that node reference fields' values are migrated properly
• Commit the patch
• Jump into a ball pit and roll around happily

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

Steps to reproduce the problem:

1. Enable the tracker (human-readable name Activity Tracker) module of Drupal core. It requires no further configuration.
2. Create a piece of content, for example a Page or Article.
3. Log in to the site with an other user account different from who the content has created.
4. Visit the /activity URL path of the site. You should see a table listing the only one content.
5. Beside its node title a colored "new" or "updated" text appears.

The <span class="marker">updated</span> element containing the status text has no gap from the <a> element containing the node title. This is bad not only for human reading, but for accessibility reasons as well.

Drupal core: 8.8.0-beta1
Apache: 2.2.34
PHP: 7.3.8 / Mem: 128M
MySQL: 5.7.26
mac OS: 10.13.6

Proposed resolution

Insert an extra non-breaking space ( ) character between these two elements. Advantages are that they will stay together in any circumstances (not breaking under into a new line, for example) and being theme/CSS agnostic.

Remaining tasks

Probably no further tasks are known.

User interface changes

Hopefully a minor visual improvement fixed.

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Original report by [username]

N/A