Problem/Motivation

There are two use cases content moderation should support which involve blocks:

• Moderating a reusable content blocks, through the normal content block creation screen.
• Moderating a whole page which is a combination of various block types, with inline block content created and treated as a composite to the whole page.

Currently when you switch on content moderation for content blocks, moderation widgets and semantics kick in for both use cases, where they should be disabled for the latter.

Proposed resolution

Inline blocks created and inserted into a layout are referenced by their revision ID from the layout storage by design, so there is very little reason to create new revisions or alter the publishing status of an inline block created for layout builder. Content moderation should not get involved for inline blocks.

I believe a good implementation may be allowing the moderation entity handlers to have a say in things like the visibility of the widget, to forcefully opt-out of some aspects of content moderation. I believe you could already switch off creating new revisions or updating the publishing status.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

When we create a new project using the templates, the current required version says ^8.8 which means that it's impossible to use composer to install a particular version of core, because it will always elevate to 8.9 now that it is out.

We need some way to get an exact core version.

self.version wont work because the verison of 'create project' will be 1.0

So, either we need to generate the templates themselves to have a locked version of core-recommended in them, or we need some other mechanism.

Problem/Motivation

The SetInlineBlockDependency event subscriber fails to assign the correct access dependency to inline blocks when creating a pending revision of override section storage.

This creates a conflict between inline blocks, override layouts, paragraphs and content moderation, since the ERR formatter and paragraphs widget creates the following access dependency chain:

1. Paragraphs entity checks host access (view/update).
2. Inline block content checks the host, or "access dependency" for access.
3. Node access should be granted, but the node is assigned to NULL, since the associated revision IDs are checked against the default entity, not the active entity.

Proposed resolution

For the purposes of access dependencies load the 'active' revision from the entity repository for the 'update' and 'delete' operation and load the canonical revision of the entity for all other operations.

Remaining tasks

Agree on an approach and tests.

User interface changes

None.

API changes

Method and constructor signatures only modified on @internal classes.

Data model changes

None.

Release notes snippet

Hi,

I need help with update my Drupal 8.3.4 version.

When i try update i have error:

StatusText: OK
ResponseText: Error: Call to undefined method Drupal\Core\Field\BaseFieldDefinition::setInitialValue() in taxonomy_update_8601() (line 177 of /home/parts/domains/carparts.ie/public_html/core/modules/taxonomy/taxonomy.install).

My watchdog:

Drupal\Core\Entity\EntityStorageException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'h.parent' in 'where clause': SELECT t.tid AS tid FROM {taxonomy_term_field_data} t INNER JOIN {taxonomy_term_hierarchy} h ON h.tid = t.tid WHERE (h.parent = :db_condition_placeholder_0) AND (t.default_langcode = :db_condition_placeholder_1) ORDER BY t.weight ASC, t.name ASC; Array ( [:db_condition_placeholder_0] => 1 [:db_condition_placeholder_1] => 1 ) w Drupal\Core\Entity\Sql\SqlContentEntityStorage->delete() (line 725 w /home/parts/domains/carparts.ie/public_html/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

How to fix it?
Thank you for any tips.

Problem/Motivation

Currently it's only possible to delete a file entity by the owner of an file entity. There is no additional condition defined for any permission or even an exception for user/1 (main admin user).

Proposed resolution

• Use existing permission to delete file entities.
• And maybe define an exception for user/1 to delete file entities like other entities.
• Add a new permission to delete any files (implemented in #45).

Remaining tasks

Direction, Decision, Patch.

User interface changes

TBD

API changes

TBD

Data model changes

None expected.

Original Issue summary:

I've faced with problem when user with id '1' (main admin user) can't delete file entities created by another user. I used view_bulk_operations for deleting file entities. I thought user 1 has absolute access to all entities.

I'm showing drupal comments on the front-end using the default drupal comment display.

I like it, but I can't replicate it in full comment display.

These two fields can't be reproduced in the full comment.

Submitted by Martin on Tue, 11/19/2019 - 15:01

Permalink

And I have far less options showing, why is this?

I just leave it as default as that shows everything I want but it'd be nice to be able to use full comment as that is what it is there for, i never fall back or rely on default for any entity type display.

Problem

RSS view with fields instead of content rendering in RSS view mode results in wrong URLs from path field (with pathauto enabled).

Instead of correct URL with http://mysite.domain/content/my-node-title we got http://mysite.domain/my-node-title.

Reproduced on multiple sites with current d.o D8 pathauto module.

1. Edit 'Frontpage' view
2. Select 'Feed' display
3. Switch display mode from content to fields
4. Add title, path, author, created field
5. Configure fields in display mode settings. Link & GUID with permaLink = Path field
6. Check URLs in preview output

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Umami's new language switcher has various issues:
When adding more languages (beyond the existing English and Spanish) it will break the nice flow of the header, or when viewing the website in RTL language.

Umami's mobile main-menu has accessibility issues (#2940023)

Proposed resolution

Creating an accessible dropdown component can solve the current issues with both Umami's language switcher and Umami's mobile main-menu.

Remaining tasks

Create dropdown menu.
Figure out best positioning and a visual representation that will be easy to identify as "Here's where I can switch to another language"

Problem/Motivation

The twig.engine is manually included for BC reasons in Drupal\Core\Template\TwigEnvironment. See #2591515: Move twig_without() to the TwigExtension where all the other filters are and deprecate for more information.

Proposed resolution

Remove the manual inclusion in Drupal 9.0.0 release, as we can then know for sure that the deprecated functions in twig.engine aren't being used.

Remaining tasks

I have wanted to do this for a very long time. Since Drupal 8.3, actually.

The "cckfield" plugin type, defined by the Migrate Drupal module, was superseded by the "field" plugin type. Grafting a backwards compatibility layer onto this monumentally poorly named plugin type was hell and I'm pretty sure it almost drove @quietone insane. So it is going to be tremendously satisfying to completely remove this plugin type, and all of the related usages and test coverage, from core in Drupal 9.

Problem/Motivation

When running and debugging migrations from Drupal 7, it becomes tedious and frustrating to have to repeatedly set the database connection up.

Proposed resolution

Allow the source database to be set up via settings by looking for a database with the key name migrate_drupal_source. If it is present, skip the "Source database" section of migrate_drupal_ui's CredentialForm.

Remaining tasks

User interface changes

If a database is already set up, the "Source database" section of Drupal\migrate_drupal_ui\Form\CredentialForm is omitted.

API changes

The database key migrate_drupal_source will now have a significant meaning.

Data model changes

None.

Release notes snippet

TBD

Problem/Motivation

The changes I made to the D7 source while working on #3008028: Migrate D7 i18n menu links caused an unexpected and unrelated error,

[error] Attempt to create a field field_text_plain_filtered that does not exist on entity type node. (/opt/sites/d8/core/modules/field/src/Entity/FieldConfig.php:312)

while running d7_field_instance_label_description_translation migration. That migration should not be trying to save to a field that does not exist and it even has a skip_on_empty to prevent that.

There are several issue already for improvements and fixes to migration_lookup but I didn't see this particular problem there.

  exists:
    -
      plugin: migration_lookup
      migration: d7_field_instance
      source:
         - entity_type
         - objectid
         - type
    -
      plugin: skip_on_empty
      method: row

However, the skip does not skip when the field does not exist. When the field does not exist migration lookup returns an array with 3 elements, all NULL and thus there is no SkipRowException.

Proposed resolution

Option 1) Change migration_lookup to return NULL when all elements of the return array are NULL.
Option 2) Alter all the migration yml that have a migration_lookup where an array of NULL might be returned and that is followed by a skip_on_empty to include a callback process with array_filter. I guess that will work.

Discussed in migrate meeting and it was decided to implement Option 2. Option 1 would mean the migration_lookup needs to be deprecated and that is for another day as there are several things to improve in that plugin.

Remaining tasks

Write a patch
Add some tests
Review

User interface changes

N/A

API changes

Migration lookup returns NULL instead of an array where all elements are NULL

Data model changes

Release notes snippet

I would like to create a field type "Time" not within or as a date.
But when I use number, I can only display comma or decimal point.
It would be very helpful, if there was a colon possibility in the manage display format. see picture.

Would this be possible. or how did you solve this problem.

Improper definition of exposedHeaders in sites/default/default.services.yml causes the following watchdog error.

Warning: implode(): Invalid arguments passed in Asm89\Stack\CorsService->addActualRequestHeaders() (line 85 of /my/drupal/vendor/asm89/stack-cors/src/Asm89/Stack/CorsService.php)
#0 /my/drupal/core/includes/bootstrap.inc(566): _drupal_error_handler_real(2, 'implode(): Inva...', '/my/drupal/...', 85, Array)
#1 [internal function]: _drupal_error_handler(2, 'implode(): Inva...', '/my/drupal/...', 85, Array)
#2 /my/drupal/vendor/asm89/stack-cors/src/Asm89/Stack/CorsService.php(85): implode(', ', true)
#3 /my/drupal/vendor/asm89/stack-cors/src/Asm89/Stack/Cors.php(53): Asm89\Stack\CorsService->addActualRequestHeaders(Object(Symfony\Component\HttpFoundation\JsonResponse), Object(Symfony\Component\HttpFoundation\Request))
#4 /my/drupal/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Asm89\Stack\Cors->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#5 /my/drupal/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(50): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#6 /my/drupal/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#7 /my/drupal/core/lib/Drupal/Core/DrupalKernel.php(656): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#8 /my/drupal/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #9 {main}.

This is due to the fact that asm89/stack-cors expects exposedHeaders to either be false, or an array. If you end up setting this to true it tries to implode a boolean and throws an error.

We're using Layout Builder to allow editors to add custom blocks to a page. One of our custom blocks has a multi-value term reference field on it, with the form widget rendered as a combobox (multi-select). In Chrome, the list items "escape" the bounding box and overflow vertically.

Screenshot of what it should look like (Seen in Safari/Firefox/Edge):

Here's what it actually looks like in Chrome:

Steps to reproduce:

1. Install fresh site from 8.6.x or 8.7.x and use "Standard" profile
2. Enable Layout Builder
3. Add at least 5 terms to the existing "Tags" vocabulary
4. Add a custom block type and add a term reference field to the tags vocabulary. Allow unlimited items
5. Update form display widget for that block type to use a select list
6. Enable layout builder for the existing "Basic Page" content type default entity view display
7. Edit layout, add block, and select "Add Custom Block"
8. Add the new block you created, and observe the issue

This seems to be related to the "-webkit-appearance: menulist;" CSS property that's added in off-canvas.form.css. Once I removed that, it looks like it does in FireFox and Safari.

Problem/Motivation

On my Drupal 7 wimleers.com I have the following text formats in the DB and the UI:

And this results in the following DB + UI in Drupal 8 after migration:

Proposed resolution

Ensure that the status column is carried over from Drupal 7 to Drupal 8.

Remaining tasks

TBD

User interface changes

N/A

API changes

N/A

Data model changes

The destination data model is now correct, it now matches the source data model.

Release notes snippet

N/A

PHPDoc references CommentStorage::buildQuery on SqlContentEntityStorage::buildQuery. This method no longer exists nor there is any other example adding conditions in core, so I think it can just be removed.

/**
   * Builds the query to load the entity.
   *
   * This has full revision support. For entities requiring special queries,
   * the class can be extended, and the default query can be constructed by
   * calling parent::buildQuery(). This is usually necessary when the object
   * being loaded needs to be augmented with additional data from another
   * table, such as loading node type into comments or vocabulary machine name
   * into terms, however it can also support $conditions on different tables.
   * See Drupal\comment\CommentStorage::buildQuery() for an example.

Thanks

Problem/Motivation

\Drupal\system\Entity\Action::setPlugin() is not actually part of any interface, despite that its docblock uses {@inheritdoc}.

  /**
   * {@inheritdoc}
   */
  public function setPlugin($plugin_id) {
    $this->plugin = $plugin_id;
    $this->getPluginCollection()->addInstanceId($plugin_id);
  }

Proposed resolution

Add this method to ActionConfigEntityInterface

API changes

Because there is a 1-1 relationship between \Drupal\system\Entity\Action and \Drupal\system\ActionConfigEntityInterface this is permissible in 8.x due to the Interfaces within non-experimental, non-test modules not tagged with either @api or @internal section of https://www.drupal.org/core/d8-bc-policy.

However, we should add a change notice.

Problem/Motivation

As mentioned in #3050389: Remove dependency to Classy from core themes, Classy will be moved to contrib before Drupal 9 and we have to remove dependencies on Classy from all core themes. Part of removing these dependencies includes providing each theme their own copies of templates that previously belonged to Classy.

There's considerable potential for error when copying ~100 templates to four different themes, so we need a test that removes some of the uncertainty from the process.

Proposed resolution

Create a test that confirms that themes do not inherit templates from Classy, and that none of the templates they use include/extend Classy templates or attach Classy libraries.

The test will include a per-theme ignore-list of templates that do not need to be included as part of the test. At first, the ignore-lists will be very large, and will shrink with each template-copying issue filed. When a new template-copying issue is filed (for example, copy aggregator templates to Bartik), the first patch will be this test, but with aggregator's templates removed from Bartik's ignore list. This way, the test won't pass until the templates are properly copied.

Every Classy-inheriting core theme currently extends, includes or attaches something from Classy, so these tests will not pass at first.

Remaining tasks

Write the test, configured it to ignore templates that still need to be copied.
Create issues to address existing attach_library() calls to Classy libraries in Bartik/Seven/Claro/Umami, as these will cause the test created here to fail.

• Umami calls {{ attach_library('classy/node') }} in node--article--full.html.twig, node--card--common.html.twig, node--card.html.twig, node.html.twig
• Bartik calls {{ attach_library('classy/node') }} in node.html.twig
• Claro calls {{ attach_library('classy/file') }} in file-link.html.twig
• Seven calls {{ attach_library('classy/image-widget') }}in image-widget.html.twig

The Claro template include/require's should be addressed in the scope of this issue as this is where the test exists to verify they were done properly. This needs to be addressed with the following:

• Bartik {% extends ""@classy/block/block--search-form-block.html.twig"" %} in block--search-form-block.html.twig
• Bartik {% extends "@classy/block/block--system-menu-block.html.twig" %} in block--system-menu-block.html.twig
• Bartik {% extends "@classy/content/page-title.html.twig" %} in page-title.html.twig
• Bartik {% extends "@classy/misc/status-messages.html.twig" %} in status-messages.html.twig
• Seven {% include '@classy/content-edit/image-widget.html.twig' %} in image-widget.html.twig
• Claro {% extends '@classy/form/form-element-label.html.twig' %} in form-element-label.html.twig

User interface changes

n/a

API changes

n/a

Data model changes

n/a

Release notes snippet

n/a

This is a follow-up from #3085534: Configure Umami to use Layout Builder to deliver original recipe content type designs

In Comment #18, it was reported that the icons for "Preparation", "Cooking Time" etc do not show in Layout Builder. Since this issue was not introduced by the patches in that issue, we are creating a follow-up issue here instead to see if we can fix it.

Frontend - Umami Recipe Icons:

Layout Builder - Umami Recipe Icons are not visible