Imagine a scenario, where the main website is served at https://example.com, and the iFrame domain options is set to an alias; https://oembed.example.com

This way when media on a page is viewed, the markup on https://example.com would be something like:

<iframe src="https://oembed.example.com/media/oembed?url=https%3A//youtu.be/Dc3LpT69crc&amp;max_width=0&amp;max_height=0&amp;hash=J3reigEh1oul-MNqUBBvVbfHUo1eI54gZryZJT22g1E" frameborder="0" allowtransparency width="480" height="270" class="media-oembed-content"></iframe>

Out-of the box, this fails with an error:

Refused to display 'https://oembed.example.com/media/oembed?url=https%3A//youtu.be/Dc3LpT69c...' in a frame because it set 'X-Frame-Options' to 'sameorigin'.

Unless an appropriate X-Frame-Options header is set, the iframe content will not load.

Should this be an optional setting, addition to iFrame domain in Media settings > Security?

    $form['security']['x_frame_options'] = [
      '#type' => 'checkbox',
      '#title' => $this->t('Set HTTP header: X-Frame-Options: allow-from {IFRAME_DOMAIN}'),
      '#default_value' => $this->config('media.settings')->get('x_frame_options'),
      '#description' => $this->t('If the content served from iFrame domain is not displayed try enabling this option.'),
      '#states' => [
        'invisible' => [
          ':input[name="iframe_domain"]' => ['empty' => TRUE],
        ],
      ],
    ];

Then set the HTTP header in an EventSubscriber:

  public function onKernelResponse(FilterResponseEvent $event) {
    $iframe_domain = $this->config->get('iframe_domain', '');
    $x_frame_options = $this->config->get('x_frame_options', 0);

    if ($iframe_domain !== ''&& (bool) $x_frame_options) {
      $response = $event->getResponse();
      $response->headers->set('X-Frame-Options', "allow-from ${iframe_domain}");
    }
  }

Problem/Motivation

follow up #3041659: Remove the layout tab from translations because Layout Builder does not support translations yet

Part of #3044386: [META] Make Layout Builder layouts translatable

Right now you are not able to translate layouts at all.

The most common use case is probably translating the block labels and inline blocks but having the actual layouts not change from language to language. For different layout per language: see #3040487: Allow Independent Layout Override Translations

Proposed resolution

1. Provide access to the Layout table on translations
2. On Translations the Layout builder would only allow translating labels and inline blocks
3. Translated settings for block would be stored a new field that would be translatable(the current Layout field would still be untranslatable)
4. Most blocks could only have labels as translated settings
5. Inline blocks could additionally have a block revision ID stored.

Remaining tasks

• Get#3013197: Cloning an implementation of SectionListInterface does not deep clone the Section or SectionComponent objectscommitted.
• Write more tests for Inline blocks. <-- We are here.

User interface changes

API changes

Data model changes

Problem/Motivation

When upload file with a long name (name does not contain spaces) via the file widget then the file name displayed in a single line and page markup looks like broken (al least a horizontal scroll shows up):

Proposed resolution

Add the tag after each underscores in the file name:

User interface changes

Add the Break row checkbox to the field manage page:

The feed URL is hard coded to 'rss.xml' and the link only works when clicked on home page.

/**
 * {@inheritdoc}
 */
public function build() {
  return [
    '#theme' => 'feed_icon',
    '#url' => 'rss.xml',
  ];
}

Problem/Motivation

TelephoneItem declares default_formatter = "basic_string". However, only string (and telephone_link) but not basic_string is available as a formatter for telephone fields.

Proposed resolution

Fix the default formatter to be string.

Note that we could also change it to telephone_link. It's arguable which choice would be more backwards-compatible: Right now basic_string does actually get used when rendering by default (see FormatterPluginManager::getInstance()) and code string is functionally equivalent to that by default (i.e. when the link_to_entity setting is set to FALSE). However, when visiting the Manage display form, the telephone_link formatter is selected by default, because it is the first one. So just visiting that page and saving it without any (explicit) changes will configure telephone_link to be used.

Alternatively we could also make basic_string availabe for telephone fields. But both string and basic_string have the same label ("Plain text"), so we would have to fix that, as well, in order to not make the UI confusing.

While we're working on fixing up logging for process plugins, I'd like to see us improve upon the work from #2655154: Optionally log messages for skip_on_empty and skip_row_if_not_set.

That issue added the ability to put a log message into your migration yml when you invoke skip_on_empty or skip_if_not_set. However, the message must be entirely hard-coded directly in the migration configuration. Your message can't use any context from your migration row at all. It'd be a lot more valuable to be able to log messages that are specific.

For example, let's say your migration has some logic to drop various taxonomy terms that are considered invalid in the D8 version of your site. If you're in a d6_term_node migration, and you want to skip because the term is gone, instead of this:

  field_department:
  -
    plugin: migration_lookup:
    migration: d6_taxonomy_term
    source: tid
  -
    plugin: skip_on_empty
    method: row
    message: 'Skipped missing department term'

It'd be nicer to be able do something like this:

  field_department:
  -
    plugin: migration_lookup:
    migration: d6_taxonomy_term
    source: tid
  -
    plugin: skip_on_empty
    method: row
    message: 'Skipped missing department term ($tid)'

A) Yes, I know, technically this specific case could be sort of figured out since the message table has the incomprehensible source_ids_hash column, and if you manually JOIN against the map table, you can eventually figure out what tid you skipped. But that's a lot of hoop jumping. And I'm *sure* we can come up with other examples where the context you want to log doesn't happen to be one of the source IDs.

B) Yes, $tid is totally invalid above. That's meant to be shorthand for a better solution. ;) Things I tried initially with this migration before looking at the code and realizing the message had to be hard-coded directly in the configuration included:

  skip_message:
    plugin: concat
    source:
      - 'Skipped missing department term: '
      - tid
  field_department:
  -
    plugin: migration_lookup:
    migration: d6_taxonomy_term
    source: tid
  -
    plugin: skip_on_empty
    method: row
    message: '@skip_message'

Etc. ;)

Anyway, the specifics of exactly the best way to get this working are TBD. I'm just opening the issue for discussion on the basic concept before I get too lost in the details.

Regardless, this should probably be blocked on #2959125: Not able to add MigrateSkipProcessException message, so starting life here postponed.

Thoughts?
Thanks!
-Derek

Problem/Motivation

Continuing from https://www.drupal.org/project/drupal/issues/2951715#comment-12559059
Log message if migration_lookup skips on empty

core/modules/migrate/src/Plugin/migrate/process/MigrationLookup.php:248:      
throw new MigrateSkipProcessException();

The skip occurs only in the case when there are multiple source_ids. What should be the text of the error message?

      if (isset($this->configuration['source_ids'][$migration_id])) {
        $configuration = ['source' => $this->configuration['source_ids'][$migration_id]];
        $value = $this->processPluginManager
          ->createInstance('get', $configuration, $this->migration)
          ->transform(NULL, $migrate_executable, $row, $destination_property);
      }
      if (!is_array($value)) {
        $value = [$value];
      }
      $this->skipOnEmpty($value);

And we have a blocker for this is
https://www.drupal.org/project/drupal/issues/2959125
The blocker was closed as Closed (cannot reproduce)

Proposed resolution

Log a message to MigrateSkipRowException to clearly explain why the row is skipped.
So far, the following messages have been proposed.

• 'Skipped processing because of its not an array'
• 'The migration process is skipped because the value is FALSE.'
• 'The migration lookup process skipped because the source_ids array is empty.'
• 'The migration lookup process skipped because the result was empty.'

The latest patch in #6 uses 'The migration lookup process skipped because the result was empty.'

Anyone have a recommendation for a better error message?

Remaining tasks

Confirm the error message.
Patch
Review
Commit

User interface changes

API changes

Data model changes

I am trying to group counple of exposed filters in a View In the content type called Product, I have a taxonomy vocab 'Product Type' with terms 'Charts', 'Labels','stickers', Friezes'
Now when I add a filter of 'Product Type' Content and expose it with grouped Values
say
Stickers Is one of Labels
Stickers
Charts is one of Charts
Friezes

I get these option on the view but when I select one of them none the valus gets returned.
But if I select 'any' in the same filter all the values are retured. I have tries Views 7.x 3.5 dev version

follow up for #2809535: Convert AJAX part of \Drupal\system\Tests\Ajax\MultiFormTest to JavascriptTestBase

There is a version of assertNoDuplicateIds on AssertContentTrait but this is meant for Kernel tests. We need a version to use for functional tests.

The version here \Drupal\Tests\file\Functional\FileFieldDisplayTest::assertNoDuplicateIds might be a good start.

Existing implementations should then use the method on the trait

It is possible to upload multiple images in a media field where the cardinality is set to 1. When this happens you cannot save the node or remove 1 of the images in the field.

To replicate:
1. Enable media module (with media library).
2. Add a media field to the basic page content type.
- Set the limit to 1.
- Set the media type to "Image"
3. Create a new basic page.
- When filling in the media image field:
- first upload an image and insert it.
- remove this image (so you have an image in the library.)
- click 'add media' and select the uploaded image from the library
- when it is selected, upload a new image
- insert both images (when using the new Claro theme, you don't see that you have 2 images selected)
- now you can't save your page or remove any of the selected images.

Short video added where the issue can be seen

There are LOTS of bug reports in contrib for this crash in the translation system:

> Call to a member function getPath() on null in /core/modules/config_translation/src/ConfigNamesMapper.php on line 233

It's really easy to cause this if you don't set up your entity type properly. One way to do it is to define the 'field_ui_base_route' annotation property on an entity type, but not actually define the route elsewhere. Then run drush cr.

Adding a check to ConfigNamesMapper that the route exists and throwing an exception if it doesn't would be a big help to developers who hit this error, as currently it's really confusing and doesn't give you any indication of what's wrong. An exception that says which route name could not be found tells developers exactly where the problem is.

Problem/Motivation

I'm working on creating a custom field that has multiple entry items in the field. The field would look like this
Field 1 - Text
Field 2 - Text
Field 3 - Text

All would be saved into separate columns.

Now my question is with a cardinality of -1 the Add More works great to put the next item to enter but how would one item be removed from the list of them. Ideally a "delete" or "remove" button would be at the end of the item line but I don't see this. I know with a single field emptying the text field "removes" it but this isn't obvious to a use.

It's not unlike the Remove button that appears next to the Image Fields when multiples are allowed.

Is this something available or less of a support request and more of a feature request?

Note: For 7.x there is a contrib module for that: https://www.drupal.org/project/multiple_fields_remove_button
This issue is about adding that functionality to core.

Proposed resolution

There are two contending approaches. Not sure which is the better one.

See #145 and #143 as examples.

1. Use checkboxes and no ajax. Checkbox is hidden with CSS and toggled from inside Remove button's event handler. Each remove checkbox will get rid of the contents of that field when the entity is saved. Advantages:
   • instant removal (no AJAX round trip/form rebuild penalty), which also means no race condition
   • degrades nicely - can be made to work even without JS
   • potential for undo-ability (not implemented)
2. Use ajax and reload element to remove the item from the page.

Remaining tasks

• Decide on direction
• Add tests
• Review
• Commit

User interface changes

API changes

Data model changes

Followup #2999721: [META] Deprecate the legacy include files before Drupal 9

Problem/Motivation

There is already an existing utility Error class. So lets keep things together.
Deprecate legacy errors.inc file functions. Just get rid of errors.inc file in drupal:10.0.x.

Proposed resolution

Convert all error handler related functions to the methods in the Error class.
That will help to work on the next step of modernizing Drupal error handler in #1722694: Replace Drupal's error handling with Symfony/HttpKernel's without carrying out of legacy errors.inc file loading BC layer in Drupal 10.0.0.

Remaining tasks

• Deprecate functions
• Replace usages in the code
• Add legacy tests

User interface changes

-

API changes

• new methods in \Drupal\Core\Utility\Error class
• deprecated error handler related functions

Data model changes

-

Release notes snippet

-

I use the migrate module to import data from ATDW(Australian Tourism Data Warehouse). However, the migration process often fails during the image uploading process.

I was running the migration process through Drush: drush.php migrate:import --group warehouse_data --update --sync

The migrate shows the below error message

Server error: `GET https://assets.atdw-online.com.au/images/034004635bfc9018f4a81e266f008f9...` resulted in a `524 Origin Time-out` response (https://assets.atdw-online.com.au/images/034004635bfc9018f4a81e266f008f9...)

Cloudflare successfully connected to the origin web server, but the origin did not provide an HTTP response before the default 100 second connection timed out.

I can fix this issue by running the migration couple of times but I think it is better to have a workaround such as skipping or retrying if an image fails?

Problem/Motivation

On October 17, 2013, Internet Explorer version 11 was released to the world.
(In comparison, Chrome browser released 45 versions since then)

Through the years, that pain point of writing additional code and spending numerous amount of hours to add support for IE11 only grew bigger, due to lack of standards and IE11 doing things in its own special way...

Inspired by https://death-to-ie11.com/ and https://www.swyx.io/writing/ie11-eol/
The latest statistics (May 2020) show that IE11 usage is already below 1.5% and keeps declining.

Let's bring a smile to millions of developers by stop supporting IE11, this could become one of the most exciting new feature of Drupal 10!

♬ Time to say goodbye ♬

Proposed resolution

• Get clarification on Drupal's policy for supported browsers #3080068: [policy, no patch] Define usage heuristics for browser support.
• Create patches to remove IE11-specific code code
• Reconsider what HTML, CSS, and Javascript functionality we've been avoided until now, that we can finally benefit from.
• Update d.o documentation
• Create a CR for all those changes.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the admin UI-related modules: contextual, help, inline_form_errors, quickedit, settings_tray, shortcut, toolbar, tour module(s).

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
   

     switch ($route_name) {
       case 'help.page.contact':
   

   And ends either at the end of the function, or where you find another case 'something': line.

3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
4. See if some of these tasks are already documented in existing topics. Currently, all topics are in core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix).
6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig (and "MODULENAME" can be "core" as discussed above).
7. Make a patch file that adds/updates the Twig templates. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

1. Apply the patch.
2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/help_topics/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
4. Review the topic text that you can see on the page, making sure of the following aspects:
   • The text is written in clear, simple, straightforward language
   • No grammar/punctuation errors
   • Valid HTML -- you can use http://validator.w3.org/ to check
   • Links within the text work
   • Instructions for tasks work
   • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

At the moment there is no generic revision UI, this means that every module with revisionable entities will need to create their own UI similar to the Node revision overview page (node/{node_id}/revisions. This means quite a bit of boilerplate code, especially for modules with multiply revisionable entities.

Proposed resolution

Create a route provider for generating revision list, revision revert form, revision delete form based dervived from link templates.

Remaining tasks

Direction/decisions

Items needing discussion

• ✅Whether to continue blocking this issue on #3043321: Implement a generic revision access API, an access checker will be added and immediately deprecated.
• ❌Whether Node should use this in this issue.
• ✅Whether we should generate local tasks, or if entities should add their own.
• Revert terminology updated to be agnostic of target revision' time.
• Should we adopt Version terminology (per patch)?

Blockers

• #2927077: $entity->toUrl('revision-*') should fill revision parameter on all applicable routes. per 45, 59, others.
• #3043321: Implement a generic revision access API per 67.

Patch to date for this issue relies on patches in these.

User interface changes

New opt-in UI based on features already established by Node.

API changes

None

Data model changes

None.

Release notes snippet

Problem/Motivation

On the comment reply page, \Drupal\history\Controller\HistoryController::getNodeReadTimestamps throws a 404 error for the /history/get_node_read_timestamps path. It looks like the data-history-node-id attribute isn't present on the comment reply page, while the comment/drupal.comment-new-indicator JS library, which relies on that attribute to pass the node ids to \Drupal\history\Controller\HistoryController, is loaded on the comment reply page (in \Drupal\comment\CommentViewBuilder::buildComponents).

Steps to reproduce

1. Install Standard profile
2. Create an article
3. Create an comment on the article
4. Click 'Reply' on the created comment

Check the db log for the 404 error.

(tested on a clean install on Simplytest.me)

Proposed resolution

Don't load the comment/drupal.comment-new-indicator JS library on the comment reply page, since I don't think we need a 'new' indicator there?

Problem/Motivation

In Drupal 7, the entityreference module allowed to create multiple field instances of the same field. The migration here "works" but then any time an entity without any data attempts to set an entity reference value an InvalidArgumentException is thrown in ContentEntityBase.

InvalidArgumentException: Field <field name> is unknown.

A comparison between getting field definitions directly from entity_field.manager reveals that the field does in fact exist on the bundle, but getting the field definition on the entity itself fails. I found that if I reset the field definitions before the exception, then it tries to go further, but runs into a similar exception in typed_data_manager.

Furthermore this is only an issue for one of the bundles. The other bundle works fine.

Steps to reproduce (as detailed in a test-only patch):

1. Add field_reference_3 field_config
2. Add field_reference_3 field_config_instance to both article and forum node bundles.
3. Run the appropriate migrations.
4. Load node 2 (an article node) e.g. $node = Node::load(2);
5. Attempt to set an initial reference e.g. $node->set('field_reference_3', [5]); or $node->get('field_reference_3')->appendItem()->set('field_reference_3', [5]); or $node->field_reference_3 = ['target_id' => 5];
6. An exception is thrown and we can see that the field definition doesn't exist on the node, but does exist on field manager.

This might be why #2814963: Support Drupal 7 entity reference fields is still open/postponed even though plugins exist for it?

Proposed resolution

Reset the entity cache of the entity type that a field instance is attached to after the field instance is migrated.

Remaining tasks

1. Review proposed resolution
2. Reword test comments to accurately describe the issue and problem

User interface changes

Unknown

API changes

Unknown

Data model changes

Unknown

When fields allow multiple values (other than e.g. checkboxes), the widget is output in a table with tabledrag. This is functional but difficult to style to look consistent with other form elements. When a form needs to match a design, we often find ourselves fighting to hide the fact that fields, which often do not need to be orderable at all, are being presented in a tabledrag table we don't want.

This patch adds an option to the field widget settings which shows up for multiple fields to allow you to choose if the field should be orderable. If you do not choose orderable it will not use a table with tabledrag to output the fields.

Before:

After:

Setting: