I have created a new view with the following settings

Format: Unformatted List
Show: Fields

Filter Criteria:
Published = Yes (AND)
Content-Type = News (AND)
has a taxonomy term (Exposed).

Advanced:
Exposed form style: Basic
Use Ajax: Yes
Caching: Tag-based

I have saved the view and added the block to a region on the theme. Now I cannot see anything on the screen. If I remove "has a taxonomy term (Exposed)." in Filter criteria, then I can see the block and content populated to the block.

If I do the same with a view page and use the same filter criteria and set advanced settings, then the view works fine there.

Problem/Motivation

In Drupal\migrate\Plugin\MigrateMessageInterface, getMessageIterator() is declared as returning \Iterator. According to the PHP page on Iterator, that means the return value should implement five methods, including rewind().

As discussed in #2714529-29: Add source and destination IDs to the data returned by getMessageIterator() , the implementation of getMessageIterator() in Drupal\migrate\Plugin\migrate\id_map\Sql returns an object of class Drupal\Core\Database\Statement, which does not implement rewind().

Proposed resolution

Since this is a public interface, we do not have the option of changing the return type. See the discussion in #5 and #6. Instead, we will add a new method that declares its return value as \Traversable and deprecate the old method.

Completed tasks

• Add a new method MigrateMessageInterface::getMessages() that duplicates getMessageIterator() except that the doc block reads @return \Traversable. See the patch in #2.
• In Drupal\migrate\Plugin\migrate\id_map\Sql and Drupal\migrate\Plugin\migrate\id_map\NullIdMap, copy the implementation of getMessageIterator() to implement the new method getMessages().
• Make both implementations of getMessageIterator() wrappers for getMessages().
• Add a deprecation notice to getMessageIterator(). See Drupal core deprecation policy.
• Search for uses of getMessageIterator() and replace them with getMessages(). For example, grep -ri getMessageIterator core.
• Add a change record. See Contributor task: Write up a change record for a Drupal core issue.
• Add a release notes snippet to this issue description.
• Reroll the patch from #18. See Rerolling patches or Contributor task: Re-roll a Drupal core patch.

Remaining tasks

User interface changes

None

API changes

This is an API change, since MigrateMessageInterface::getMessageIterator() is a public function.

Data model changes

None

Release notes snippet

The method getMessageIterator() from Drupal\migrate\Plugin\MigrateMessageInterface is now deprecated. Use getMessages() instead.

Situation

Given a view with an exposed sort form to sort a search API database or solr index with facet filters.

Issue

When a selection of filters have been applied and you change the 'Sort By' option after using a facet filter, the facet filter is ignored by Views or the Facet API's query parameters are also not being sent to the server and the listings will default to show all results

Work around.

I have attached a patch the works for now. The patch also takes into consideration if you have facet pretty path module enable else it adds facets filters as hidden form fields to views exposed forms.

Problem/Motivation

PHP is weakly typed and this can lead to bugs like https://bugs.php.net/bug.php?id=54547.
In addition, it causes our code to be less explicit than it could be; core is littered with 0/1 where it should be FALSE/TRUE, and strings where they should be integers.

Proposed resolution

Adopt a policy of always using the strongly typed comparison operators, and use them.
It might even expose a bizarre edge-case bug or two.

Create a child issue for each module. Take care of each conditions, only real strict comparison should be converted.
Ex:

// No needs changes because we potentially compare two differents types.
$nid = 1;
if ( $node->id() == $nid) {

}

// Needs changes, we are sure to have string in both.
if ( $node->id() === $node->original->id()) {

}

Remaining tasks

• #2984196: Replace Loose comparison by Strict comparison in core
• Core tests
• Module action: no changes
• Module aggregator: #2984220: Replace Loose comparison by Strict comparison in aggregator module
• Module automated_cron: no changes
• Module ban : #3073996: Replace Loose comparison by Strict comparison in ban module
• Module basic_auth: no changes
• Module big_pipe : #3073997: Replace Loose comparison by Strict comparison in big_pipe module
• Module block : #3073998: Replace Loose comparison by Strict comparison in block module
• Module block_content : #3073987: Replace Loose comparison by Strict comparison in block_content module
• Module block_place: no changes
• Module book : #3074086: Replace Loose comparison by Strict comparison in book module
• Module breakpoint
• Module ckeditor
• Module color: no changes
• Module comment
• Module config
• Module config_translation
• Module contact
• Module content_moderation
• Module content_translation
• Module contextual
• Module datetime
• Module datetime_range
• Module dblog
• Module dynamic_page_cache: no changes
• Module editor
• Module entity_reference: no changes
• Module field
• Module field_layout: no changes
• Module field_ui
• Module file
• Module filter
• Module forum
• Module hal
• Module help
• Module history: no changes
• Module image
• Module inline_form_errors: no changes
• Module language
• Module layout_builder: no changes
• Module layout_discovery: no changes
• Module link
• Module locale
• Module media
• Module media_library: no changes
• Module menu_link_content
• Module menu_ui
• Module migrate
• Module migrate_drupal
• Module migrate_drupal_ui
• Module node
• Module options
• Module page_cache
• Module path
• Module quickedit
• Module rdf
• Module responsive_image
• Module rest
• Module search
• Module serialization
• Module settings_tray
• Module shortcut
• Module simpletest
• Module statistics
• Module syslog
• Module system
• Module taxonomy
• Module telephone: no changes
• Module text
• Module toolbar
• Module tour
• Module tracker
• Module update
• Module user
• Module views
• Module views_ui
• Module workflows: no changes
• Module workspace

User interface changes

N/A

API changes

Policy change: never use == or !=, always === or !==

Original report by chx

I wanted to get rid of them at least since Paris (remember my presentation?) but now that https://bugs.php.net/bug.php?id=54547 is filed and turns out there's more than just filling a presentation and a blog with the quirkiness but there are dire security weaknesses as well (search for ximaz in the bug report), it's time to use === and cast if necessary. It won't be necessary mostly.

See #1530652: [META] Switch from == to === to prevent mistakes and make brute force password attacks harder

Problem/Motivation

As discovered in #3054765: Need to add an entity update event listener to add moderation state for newly revisionable fields, modules need a way to add new (base) fields when an entity type is converted to revisionable.

This is currently not possible because in \Drupal\Core\Entity\EntityTypeListener::onFieldableEntityTypeUpdate() we dispatch the EntityTypeEvents::UPDATE event *before* setting the last installed storage definitions. This means that a field storage that was installed by an event subscriber is discarded.

Proposed resolution

Invoke the EntityTypeEvents::UPDATE event after we set the last installed field storage definitions.

Remaining tasks

Review.

User interface changes

Nope.

API changes

Nope.

Data model changes

Nope.

Release notes snippet

Nope.

Postponed on #2283977: Create a new ConfigEntity type for storing bundle-specific customizations of base fields, which is introducing the BaseFieldOverride class described in this issue.

Problem/Motivation

• When a new 'base_field_override' config entity is created, BaseFieldOverride::preSave() calls the target entity type's storage handler's onFieldDefinitionUpdate() method, passing it the base field definition as the "previous" definition. And similarly, when the override config entity is deleted, BaseFieldOverride::postDelete() calls onFieldDefinitionUpdate, passing it the base field definition as the "new" definition.
• However, if it happens that a base_field_override config entity is being added to or deleted from a site that also implements an override via ContentEntityInterface::bundleFieldDefinitions(), then the above behavior is incorrect, since the previous definition prior to base_field_override insertion and the new definition after base_field_override deletion is the one returned by ContentEntityInterface::bundleFieldDefinitions(), rather than the base definition.
• The above might be an extreme edge case, because using ContentEntityInterface::bundleFieldDefinitions() rather than config to override base field definition is specifically intended for when you need you content entity type completely decoupled from config, in which case there shouldn't be code adding and removing base_field_override config entities for it.
• Also, it's not really clear what FieldableEntityStorageDefinitionInterface::onFieldDefinitionUpdate() is even for. The only implementation of it in HEAD is a completely empty function, even after #1498720: [meta] Make the entity storage system handle changes in the entity and field schema definitions. Perhaps we should consider removing it? Do storage handlers need to be notified of non-storage-related changes to field definitions?

Proposed resolution

Discuss the above and figure out what to do.

Remaining tasks

User interface changes

API changes

Problem/Motivation

While working on adding migration states to the Commerce Migrate Module I discovered an error in the validation test. Turns out when the fixture is not loaded none of the derived migrations are created. And without all the migrations created the test isn't checking the complete set of discoverable migrations. That needs to be changed.

In addition, we should make sure that all the migrations listed in #2208401: [META] Stabilise Migrate Drupal Multilingual module and #2456259: [META] Drupal 7 to Drupal 8 Migration path, which are the remaining ones (correct that if wrong), have an entry in the appropriate module in the 'not_finished' section of the state file.

Proposed resolution

Create a test for drupal 6 and drupal 7, and move the test code to a trait.

Remaining tasks

Patch
Check that all the remaining migrations have an entry in the 'not_finished' section.

User interface changes

API changes

Data model changes

Release notes snippet

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

The help system needs search capability.

Proposed resolution

Probably, using the existing Drupal core Search module to build the search functionality would make the most sense. But build it in such a way that Search API contrib module, or other search modules, could easily grab the help text to index and make it searchable.

A note about caching:
- We're really only concerned here about caching for the search results page.
- The Search module already puts cache tags in based on the search index (which we have a test assert for). So that means whenever the search index changes (i.e. for whatever reason we have decided to add, delete, or update an entry for a help item), the search results page cache is invalidated. That should be sufficient to take into account the idea that if the list of (and contents of) help topics that are searchable changes for any reason, we should invalidate the search results page (because you would get different search results potentially).
- We do also want to let each item in the results, as it renders itself, to declare cache stuff (this is also in the patch/test).
- We also need a cache context for user permissions, because which items can be searched depends on user permissions.
- We should also restrict the search to only look for topics in the current page language, and add a context for the interface language.

Remaining tasks

1. [Done] Implement search indexing and searching, using the core Search module. The latest patch (#54) has this working. Here is what the search results look like:
   
2. [Done] Once it's finalized, we'll need to update its hook_help, and also add a Help Topic for it. NOTE: The help topic could use some links to help topics that don't yet exist about creating search pages and block placement. We'll have to do those later when we clean everything up in the topics on #2687107: Reorganize topics into sensible outline, and/or write more topics so I'll add a note to that issue.
3. [Done] Add a search box to the main Help page. This depended on #3067943: Add capability for search blocks on non-default search and looks like this:
   
4. [Not doing at least now] Possibly add search block to other admin pages?
5. [Not doing at least now] We discussed having a keyword functionality -- a field added to the HelpTopic plugin that would define keywords that could be emphasized in the search, but decided that would not be part of this patch.
6. [Done] Write a test. Things to test:
   - [Done] If you enable Seven theme, you get the search block present on the help page.
   - [Done] Search works for some keywords. Probably best to use the test module HelpSection plugin for that.
   - [Done] Search permissions -- both the overall permission and the one that is used for a given help section. The existing help tests verify this with a section that has permissions, so we could make that HelpSection plugin searchable for further testing.
   - [Done] Internationalization of search -- again with that test plugin... the HelpSection plugins have control over how to render items for indexing/results in a given language, so it would not be too hard to fake the internationalization bit in the test.
   - [Done] Also add tests in the Help Topics module that verify that searching works with Help Topics in particular, and the internationalization of search works for Help Topics. But best to have the main tests independent of Help Topics I think?
   - [Done] Cache tags/contexts/etc.

User interface changes

Help topics provided by the Help Topics module will be searchable. There is a new block on the main Help page that lets you search help.

API changes

No changes to existing APIs.

New API: HelpSection plugins that also implement the new interface \Drupal\help_topics\SearchableHelpInterface will make their topics searchable. So far, only the HelpTopicsSection in the help_topics module implements this interface.

Data model changes

A new database table help_search_items is added to keep track of the IDs of help topics that are searchable.

Release notes snippet

We have added a new search type (that is, a new @SearchPlugin plugin) to Core, to go along with the Node and User search types that already existed. This search type is for searching help, and its plugin is called \Drupal\help_topics\Plugin\Search\HelpSearch (it is in the experimental Help Topics module). Using this type of search, administrators can define search pages that will provide help search to site users with permission to view help.

Modules that provide @HelpSection plugins (which define sections for the admin/help page) can make their help text searchable by implementing a new interface \Drupal\help_topics\SearchableHelpInterface on their HelpSection class, which requires implementing two methods: listSearchableTopics() to list the IDs of help topics that should be searchable, and renderTopicForSearch(), which renders a single ID for either help indexing or help search results. As an example, see the \Drupal\help_topics\Plugin\HelpSection\HelpTopicsSection plugin, which is currently the only HelpSection plugin that implements this interface. (So, currently if you search help, you are only searching Help Topics managed by the Help Topics experimental module.)

When migrating from Drupal 7 to Drupal 8, Boolean field are created in Drupal 8, except On and Off Label are not same as there Drupal 7 counterpart.

Drupal adds tokens to forms for cross-site request forgery protection, but unconditionally skips doing so for anonymous users.

In most cases this does not matter (because if an anonymous user can submit a form, a potential attacker can just submit it themselves anyway), but in some cases where sites are displaying pages differently to different anonymous users (based on IP address or session information), it can matter, and it would be useful to have the option to add a form token in those cases.

This issue was discussed internally in the Drupal Security Team first, and we felt it could be a public issue due to its unusual nature and limited impact.

As for possible solutions, Heine, for example (who originally reported the issue related to this) suggested that if caching is disabled, that would be one case where we could easily add the token even if the form is being viewed by an anonymous user.

I am trying to upgrade my site from the 1.x branch to 2.x but am running in to some confusion and a bit of a performance problem.

When filtering by an entity reference field, I used to be able to do something as simple as /api/entity_type?filter[ref_field]=123, where 123 is the ID of the entity. This is beneficial to using the UUID because it does not require a JOIN on the referenced entity table. The query would be something like:

SELECT base_table.id AS id, base_table.id AS base_table_id FROM {entity_type} WHERE ref_field = 123

Now, when trying to perform the same API request, I get this error: "Invalid nested filtering. The field `ref_field`, given in the path `ref_field` is incomplete, it must end with one of the following specifiers: `id`."

If I change the filter to ?filter[ref_field.id]=123, the query becomes overly complex and performance degrades seriously (we have over 2M entities):

SELECT base_table.id AS id, base_table.id AS base_table_id FROM @entity_type base_table INNER JOIN @entity_type entity_type ON entity_type.id = base_table.id LEFT OUTER JOIN @ref_field ref_field ON ref_field.id = entity_type.ref_field INNER JOIN @ref_field ref_field_2 ON ref_field_2.id = ref_field.id WHERE ref_field_2.uuid LIKE :db_condition_placeholder_0

I am curious: 1) Why was this change added? and 2) Is there anyway I can force the former, more simple approach?

Problem/Motivation

When custom content blocks are placed at page by Layout Builder, there are no contextual links on this block. This is about viewing page, not editing. I dug deeper into the problem and noticed, that some of blocks still has contextual links, e.g. views-blocks and blocks with webforms. But custom content blocks (provided by core module 'block_content') hasn't any contextual links when rendered by layout builder. This also applies to some contrib modules, e.g. Config Pages blocks also has no contextual links with Layout Builder, but when I placed {{ title_suffix }} into config-pages.html.twig, contextual links appeared ar config pages blocks.

Also I found out, that contextual links appears only in those modules, that contains some additional or specific logic of contextual links generation.

Proposed resolution

Do something to attach contextual links to blocks, rendered by Layout Builder.

Remaining tasks

TBA

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

At the moment, the Workspaces module can not be installed if Content Moderation is also installed, see #2971699: Content Moderation and Workspace don't work together.

After #3027598: Omit workspaces entity presave and predelete hooks for internal entities is done, there is very little work needed to make them compatible.

Proposed resolution

Remove the 'latest-revision' link template when both Workspaces and Content Moderation are installed, because Workspaces always shows the active revision on the canonical page of an entity, so the latest revision tab is not needed.

Make Content Moderation skip and pre-save logic if an entity is syncing, for example when it is being published from a non-default workspace to the Live one.

Remaining tasks

Add test coverage.

User interface changes

The Latest revision tab will not be shown when both Workspaces and Content Moderation are installed.

API changes

Nope.

Data model changes

Nope.

Release notes snippet

Workspaces and Content Moderation are no longer incompatible and can be installed and used together. Advanced workflows like moderating an entire workspace are possible as well.

Problem/Motivation

Now that we've adopted Composer as a build tool for Drupal, we're left with some features of drupal that still need adaptation and engineering to work.

Multisite Drupal is an extremely useful feature for many sites, and the consensus is that its a critical feature that cannot be replaced with multiple single sites.

Let's use this issue to do 2 things:

1. Document what multisite is, and the use cases people use it for. i.e *why* do people need it, and *how* do they use it?
2. Brainstorm potential solutions and look for a path forward that allows a multisite user to be able to use any of the modules that have 3rd party composer dependencies, and allow them to update and mange their site with composer.

Proposed resolution

Still TBD. The trickiest use case to support with Composer seems to be a multisite where there are variations of modules/themes on a per-site basis. (For example, someband.com and someotherband.com offer the same features [photo gallery, discography, tour], but have vastly different designs, and/or someotherband.com has an integration module with some one-off analytics application that no other sites want/need.)

This gets tricky because modules + themes are individual projects in Composer, and Composer assumes there is only one location all dependencies are going into. (By default /vendor) This is incompatible with the idea that there are multiple places to look for extension code (sites/all + sites/someotherband.com)

Possible ideas that have been tossed around:

• #17: Move forward with the Composer initiative, not accounting for this use case for now (and documenting such), and work upstream with the Composer project to handle it in a generic way for more than just Drupal.
• #20: Use Composer's ability to override installer paths on an individual package level, along with custom magic in our autoloader, to place some code in different directories. However, there are quite a few downsides to this plan, as documented in #22.
• #36: Add a composer.lock and vendor/ directory to each /sites directory, similar to how you can add a per-site /modules or /themes directory currently. Requires adjustment to the autoloader, possibly other things, but is consistent with the current approach.
• Others?

Remaining tasks

1. Document use cases for multisite that need to be supported in a Composer-y world Captured at https://www.drupal.org/docs/8/multisite/use-cases-for-drupal-multisite
2. Brainstorm potential solutions and look for a path forward

Problem/Motivation

Labelling this as a bug for now, but feel free to change it. It certainly feels like a bug to me but #3052042: If an inline block has been edited outside of layout builder it can't be edited in layout builder and the code that explicitly allows this says otherwise.

The problem is, when a block is created via Layout builder (making it inline/non-reusable) and the block is referenced by a node (or whatever entity type) revision that the user can also edit, that user is able to edit the block through the entity.block_content.canonical route.

The code path that lets this happen is from the access control handler into the inline block dependency subscriber

Why is this a bug? It just doesn't seem to fit with what the rest of the solution around inline blocks is trying to achieve. For instance:

1) The block is explicitly filtered out of the block content collection
2) When the block is edited via that UI, the user is then taken to previously mentioned collection screen where the block isn't listed
3) If the user tries to edit the block again they get access denied because now the new revision is no longer referenced by the node revision they can access and the event subscriber doesn't return a dependency which returns access denied
4) The changes the user made are NEVER seen because nothing references that revision.
5) It causes bugs like #3052042: If an inline block has been edited outside of layout builder it can't be edited in layout builder

Proposed resolution

Deny access from editing inline blocks via any UI except layout builder.

Remaining tasks

1. Agree this is a bug
2. Fix 'er up

User interface changes

Remove ability to edit inline blocks via the block content UI.

API changes

TBD

Data model changes

Hopefully none.

Release notes snippet

TBD

Problem/Motivation

Found in #2946333: Allow synced Layout override Translations: translating labels and inline blocks

It is more obvious in that issue but it can be reproduced without that patch.

1. Create a view that list all non-reuseable blocks and links to the block(will open edit)
2. Create an inline block
3. Save the layout
4. goto the view. Update the inline block
5. Try to edit the block in the layout builder.
6. Get an error

This is because \Drupal\layout_builder\Plugin\Block\InlineBlock stores the revision id. and loads the block for editing.

If the block is only edited in Layout Builder it will always be the latest revision. If it is edited outside of layout builder it will not be the latest revision.

This is an edge-case now but in [# #2946333: Allow synced Layout override Translations: translating labels and inline blocks this will be a problem because translation will store translations of inline blocks so they will create new revisions of the blocks.

Proposed resolution

Use \Drupal\Core\Entity\EntityRepositoryInterface::getActive() in \Drupal\layout_builder\Plugin\Block\InlineBlock::blockForm() to get the revision that can be edited

Remaining tasks

Do it

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Problem/Motivation

In reviewing #2994702: Allow editors to alter embed-specific metadata, as well as `data-align` and `data-caption`, the UX team had this feedback about the "remove" button that appears for each embedded media item:

...it [is] entirely too easy to accidentally stray-click the "X" icon and remove an embed. They asked for a confirmation dialog to be displayed first. Since the existing image embed button does not display an "X" (you just have to click the embedded image and press Delete on your keyboard), we agreed to remove the "X" button from this patch and add it back, with a confirmation alert box, in a follow-up.

That's this follow-up.

Proposed resolution

Restore and update the relevant code from #2994702-43: Allow editors to alter embed-specific metadata, as well as `data-align` and `data-caption` into a new patch in this issue, and add a confirmation dialog when the "remove" button is clicked. (Also, figure out if the presence of the confirmation should be configurable.)

Remaining tasks

Restore the old code, then determine what the text of the confirmation box should be, whether it should be configurable, etc. Then add tests, get UX and accessibility sign-off, and commit.

User interface changes

Media items embedded in a CKEditor instance will receive a new button which allows them to be removed from the content.

API changes

None expected.

Data model changes

None.

Release notes snippet

TBD

Problem/Motivation

With migrate, it would be great to be able to create new revision when you run the migration with update.

Proposed resolution

Add a "new_revision" option to entity destination plugin. If set to true, Drupal\migrate\Plugin\migrate\destination\Entity::getEntity() call setNewRevision(TRUE) on the entity.

Remaining tasks

1. patch
2. reviews needed
3. tests to be written
4. documentation to be written

API changes

None?
If you don't add this option in your migration, current behavior is preserved.