The website encountered an unexpected error. Please try again later.
Error: Call to a member function getPluginDefinition() on null in Drupal\views_ui\ViewListBuilder->getDisplaysList() (line 262 of core/modules/views_ui/src/ViewListBuilder.php).
Drupal\views_ui\ViewListBuilder->getDisplaysList(Object) (Line: 109)
Drupal\views_ui\ViewListBuilder->buildRow(Object) (Line: 235)
Drupal\views_ui\ViewListBuilder->render() (Line: 23)
Drupal\Core\Entity\Controller\EntityListController->listing('view')
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Steps to reproduce

1. I have existing view page which I disabled with /sample-path.
2. Then created another view page with path called /sample-path-override
3. I created attachment and attached it "before" to the page /sample-path-override.
4. I changed the url of the /sample-path-override to /sample-path since i disabled the original /sample-path and deleted the /sample-path (i dont know the exact page id, but my guess is page_2.
5. I rename the display name and machine name of the attachment after that, i noticed that the error "Plugin ID was not found." exists and i can't able to view the "View List" or save the "View that is affected".
6. And that's the error above when i visit /admin/structure/views

Problem/Motivation

We discussed in a migrate meeting the fact that creating and rerolling patches with the test fixtures is time consuming and maybe it would be better to update the fixtures with the data for all remaining issues.

It is common to need to bring up a D6 or D7 site using the fixture database in order to enter data. Then, when that database is dumped using db-tools an incredible number of other changes appear in the fixture. For example, every single row of the system table changes, search creates rows etc. Including that in the patch makes for a large patch which makes it difficult for the reviewers, who expect the patch to include only the relevant changes to the fixture. So, the practice is to edit out the unnecessary changes to the fixture in the patch. Of course, for some small changes when you know where to look it is possible to find and keep those. Often that is not the case.

This has been discussed before in #2670846: Add i18n data to d7_dump. In that issue, comment #15, maxocub makes good points about the value of adding the data per issue.

Proposed resolution

Make a new fixture for D6/D7 that adds the data needed for Active issues. Anything already being worked on continues as is.

Remaining tasks

Investigate what D6 and decide if the fixture should be updated for remaining active issues.
Investigate what D6 and decide if the fixture should be updated for remaining active issues.

Problem/Motivation

What is the way to provide query parameters or other route options for entries in links.menu.yml?

my_module.csv_export:
  title: 'CSV Export'
  enabled: 1
  route_name: view.csv_export.rest_export_1
  options:
    query:
      '_format': csv

Proposed resolution

Document in menu.api.php, specificaly section on @section sec_links how to add options such as query strings.

Remaining tasks

Write a patch.

User interface changes

n/a

API changes

n/a

Data model changes

n/a

Problem/Motivation

Unnecessary getter used to get the Id of the entity type.

Proposed resolution

Since we are in an object context, the property may be directly referenced.

Remaining tasks

patch

review

User interface changes

none

API changes

none

Data model changes

none

Release notes snippet

none

Original report by Joachim

      throw new \LogicException("Entity type {$this->getEntityTypeId()} does not support revisions.");

A function call in a string is not going to work, is it?

Problem/Motivation

\Drupal\views\ViewExecutable::$style_plugin and \Drupal\views\ViewExecutable::$rowPlugin
should have corresponding methods, one could call.

Once we do that, we can also mark the public properties as deprecated

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

API page: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Dependenc...

   * Additional tag attributes supported by 'service_collector' only:
   *   - call: The method name to call on the consumer service. Defaults to
   *     'addHandler'. The called method receives two arguments:
   *     - The handler instance as first argument.
   *     - Optionally the handler's priority as second argument, if the method
   *       accepts a second parameter and its name is "priority". In any case,
   *       all handlers registered at compile time are sorted already.
   *
   * Example (YAML):
   * @code
   * tags:
   *   - { name: service_collector, tag: breadcrumb_builder, call: addBuilder }
   *   - { name: service_id_collector, tag: theme_negotiator }
   * @endcode
   *
   * Supported handler tag attributes:
   * - priority: An integer denoting the priority of the handler. Defaults to 0.

The above is incomplete and a little misleading.

Compare with the actual code:

    foreach ($params as $pos => $param) {
      if ($param->getClass()) {
        $interface = $param->getClass();
      }
      elseif ($param->getName() === 'id') {
        $id_pos = $pos;
      }
      elseif ($param->getName() === 'priority') {
        $priority_pos = $pos;
      }
      else {
        $extra_params[$param->getName()] = $pos;
      }
    }

...

      // Keep track of other tagged handlers arguments.
      foreach ($extra_params as $name => $pos) {
        $extra_arguments[$id][$pos] = isset($attributes[0][$name]) ? $attributes[0][$name] : $params[$pos]->getDefaultValue();
      }

We can see the following:

1. The handler instance must be the first parameter that has a class typehint. Apart from that, its position is not relevant. The docs though say:

> The handler instance as first argument

EDIT: nope, scratch that. Looks like a bug though, as the code has:

      $arguments[$interface_pos] = new Reference($id);

just that $interface_pos never gets set to anything other than 0.

2. The priority parameter can be in any position, so long as it is named 'priority'.

3. There can be an 'id' parameter, which gets passed the service ID if present.

4. There can in fact be any number of other parameters, which will be matched up with tag attributes on the collected services, so for example:

   * @code
   * tags:
   *   - { name: breadcrumb_builder, cake: chocolate }

will work with:

public function addHandler(MyHandlerInterface $handler, $cake) {
}

Problem/Motivation

As the wrong type of comment tags are used in the php comment, the commented text appears in the generated error message, as seen in attached screenshot

Proposed resolution

Change the comment tag of the comment from {# to //

Remaining tasks

1. Detail how to reproduce the error
2. Review

User interface changes

The comment will no longer incorrectly appear in the generated error message

API changes

none

Data model changes

none

Release notes snippet

none

Original report by rwohleb

API page: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Template%...

The code snippet for using "without" on attributes is not properly escaped. The browser is trying to interpret it. See screenshot.

Problem

When attempting to use $menuLinkContent->access('randomoperation') an exception is thrown.

The website encountered an unexpected error. Please try again later.
TypeError: Argument 1 passed to Drupal\Core\Access\AccessResult::orIf() must implement interface Drupal\Core\Access\AccessResultInterface, null given, called in /core/lib/Drupal/Core/Entity/EntityAccessControlHandler.php on line 106 in Drupal\Core\Access\AccessResult->orIf() (line 314 of core/lib/Drupal/Core/Access/AccessResult.php).
Drupal\Core\Access\AccessResult->orIf(NULL) (Line: 106)
Drupal\Core\Entity\EntityAccessControlHandler->access(Object, 'clone', Object, ) (Line: 708)
Drupal\Core\Entity\ContentEntityBase->access('clone') (Line: 32)

Cause

\Drupal\menu_link_content\MenuLinkContentAccessControlHandler::checkAccess must always return an object implementing \Drupal\Core\Access\AccessResultInterface. However it incorrectly returns NULL when an access to an operation other than 'view', 'update', or 'delete' is requested.

Motivation

Entity Clone automatically adds a 'Clone' local task to content entities. Patch #2743379: Clone operation shows regardless of permission for Entity Clone updates its clone route to use a 'clone' operation. However because Menu Link Content mishandles unrecognised operations, the menu link page edit form throws an exception.

Problem/Motivation

Modules need a way to declare their migration status and give a short description on the Migrate Upgrade review page, /upgrade. The short description can have a link to a documentation page for example for known issues.

The Review form lists all modules on the source site in either a 'will be upgraded' or 'will not be upgraded' list. However, determining which section to add a module too is not robust. If the module has migrations, it will be displayed in the 'will be upgraded' list, even if it only has one migration and needs more than one to be complete. We need a mechanism that can explain this situation in the UI.

The mechanism needs to be flexible to accommodate the many scenarios possible. See #71 and #72 for details.

This work here is to only create and implement such a system, to make the first step, for what is a complicated problem. Changes may be made to the UI but are expected to be minimal. However, a UX review is planned. When that feedback is given it needs to be decided what can be done in this issue and what must be moved to followups.

Note: in #2914974: Migrate UI - handle sources that do not need an upgrade we defined a list of modules that do not need any migrations (e.g. Overlay, Help) or the contrib functionality has moved into core and there is not a D8 core module with the same name. These modules are listed in ReviewForm::$noUpgradePaths

In a migrate meeting, using a hook or an event was discussed. A possible solution, using hook_form_alter, was implemented in #2914974: Migrate UI - handle sources that do not need an upgrade and removed after a review #176. That review asked some questions, listed below, which should be resolved here.

1. The CR is titled Provide a Method to Intentionally Mark Modules, Themes and Profiles as not Upgradable but we're not really providing a method.
2. Did we give consideration to a dedicated API? E.g. we could put entries in .info.yml or we could put .migrate.info.yml files in modules.
3. How likely is it that contrib modules will need to make this change?

Proposed resolution

After framework manager review the status information moved from .info.yml to module.migrate.yml, the format stays the same.
Add the following to migate.yml to any module providing or needing migrations, include field migrations.

migrations_finished:
  6:
    source_module_A: destination_module_A, destination_module_C
    source_module_B: destination_module_B
  7:
    source_module_A: destination_module_A
    source_module_B: destination_module_B
migrations_not_finished:
  6:
    source_module_C: destination_module_D, destination_module_E

In 'migrations_finished' is a list of all source module/destination module pairs for migrations that are complete in the module. If migrations are found in the module it will be assumed that the migrations are not finished. The 'migrations_not_finished' is needed when more than one module will contain migrations for a source module and at least one of the modules uses the 'migrations_finished' key. Say Module A and Module B provide migrations for Module C. Module A is finished and uses 'migrations_finished'. Then, if Module B has no migrations, it needs to use 'migrations_not_finished'.

See the full details in #72 and #77

Screen shots

Now, for the screen shots which need some attention. The difference between the before and after is that on the after screenshots the modules in the Drupal 8 column are listed in a single line separated by commas whereas in the before screenshots they are on separate lines. That's all.

But the screens should provide some information or direction to the user on what to do about the modules in the 'will not be upgraded' section. After all, if a module they need is listed here they need a next step right on this page. How best to inform them of what to do? A single help text somewhere on the page or something else? The user also needs support on what to do about the other modules that will not be upgraded. See #87

Also, the idea of allowing modules to add text to the page via a hook, in a possible followup, has been discussed by the team. Any decision here should be aware of that.

To navigate to the Review page you need a D6 or D7 Database Then install Migrate Drupal UI and go to /upgrade.

Before
Full page
Module that will not be upgraded section
Modules that will be upgraded

After
Modules that will not be upgraded section
Modules that will be upgraded section

History

The first proposal which came from a migrate meeting was to add the migrate status of the module and a description string to be displayed on the Review Page to info.yml . This was tweaked a few times. See #7 and #8. See #10. Eventually, the description was removed as to difficult to maintain an html string in .info but the version key remained.

Remaining tasks

• Decide on the format of the new 'migrate' key and values in .info.yml. Suggested formats are in #11 and #15. Those have been abandoned in favor of 'migrations_finished' and 'migrations_not_finished'.
• Decide on the allowed values for status. Suggestions are in #7, #9. Currently proposed values are 'complete', 'incomplete' and 'n/a'. The UI impact with a screenshot is in #28.
• Decide if adding a key for source version is ok.As pointed out in #10, the status needs to be declared by source version.
• Review
• UX Review - See #106 - #11
• Update change record
• Update handbook documentation
• Commit

Style error information

https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/named.md

How to Review

## 1. Apply Patch
## 2. Review Code Changes
## 3. Confirm no Code Standard Errors
yarn & yarn lint:core-js-passing
## 4.1 If `NO` errors, mark the issue as `Reviewed & tested by the community` (Don't be shy, we're all friendly)
## 4.2 If `HAS` errors, fix it and upload a new patch (Just do it and you can!!!)

Background

- #2912962: Step 1 JS codestyle: [meta] Fix JS coding standards in core

- We adapted the airbnb coding standard (#2815077: Adopt airbnb javascript style guide v14.1 as new baseline javascript coding standards for Drupal 8 core and contrib), but we are not fully compliant to it yet.

More Information

- Using ES6 in Core
https://www.drupal.org/node/2815083

- To find JS code standard errors stats
cd core/ && yarn & yarn lint:core-js-stats

Valuable Follow-up

- N/A

Problem/Motivation

The layout builder UI, and details of the sections/regions/blocks currently arrangemed inside it, needs to be conveyed to assistive tech users.

Because before a user starts to add/move/delete blocks, they need to know what is there already.

Proposed resolution

TODO: Any other approaches we can consider?

Idea 1

• Add visually-hidden <div role="group" aria-labelledby="" aria-describedby=""> grouping wrappers, to describe the available regions. Each region, and each section gets a group role.
• Include an overview, somewhat like the approaches for describing tables using caption and summary.
• The summary could derived from the *.layouts.yml layout plugin definitions. There are human-readable names for the layout itself, and the regions inside it.
• Sections don't have names, so we'll have to describe these using their number (position-in-set) to distinguish them, i.e. "Section 2."
• The layout plugin's name could also be used, but it may not be unique so we'd append it to the numbered section label, i.e. "Section 2 - two-column layout."
• There is also a human-readable "description" field for the layout plugin, but it is optional. Is this a good way to use the description? We could include this in a section's summary.
• A description for the region group could state the number of blocks currently contained inside.
• This caption and summary could be granular, with a caption/summary per section, as well as one at the start of the entire layout builder UI.
• Verbosity - how much of this is necessary, vs. nice-to-know, vs. way too much?

Remaining Questions, Challenges, and Opportunities

1. Headings are commonly used as the main navigation method by screen reader users. If the layout builder UI makes use of visually-hidden headings, but the block content also contains headings, will these two sets of headings be working at cross-purposes?
   • Possible solution: allow screen reader users to hide the block content previews. There's already an idea to let sighted users do this to assist dragging where blocks are very large.
2. The terms "section" and "region" already have special meanings in HTML5 and ARIA, and they may be announced as roles by screen readers. Will this be a problem? Will it suffice if we choose our labels carefully, like "Layout section 1, left region".
3. The ARIA 1.1 roledescription may eventually be useful here, to override role="group". However it is leading-edge feature, not broadly implemented yet. For example we might eventually be able to say <div role="group" roledescription="Layout region">

Remaining tasks

Get opinions from screen reader users in the community, and/or expert advice (walk-throughs, prior art) from wider a11y community.
Implementation.

User interface changes

Markup changes, primarily visually hidden labels and descriptions for screen readers. No visual changes required to support screen readers, but see related issues which may toggle these between visually-hidden and visible.

API changes

TBD

Data model changes

TBD

Problem/Motivation

For Umami to work with multilingual content (initially with Spanish content), we need to be able to import multilingual content.

Few steps need to be completed in order to achieve that:

1. The existing CSV content files in English should move to a structure that can support future languages (3028627
2. Enable multilingual functionality as part of Umami install profile3029839
3. Translated content in Spanish need to finalized in order to be part of OOTB 3028769

While this process might take time, there are other multilingual configurations and settings that need to be addressed.

Proposed resolution

1. Creating a patch [WIP] of "good enough" patches (instead of waiting for them until they are finalized)
2. Creating dummy Spanish content
3. Updating InstallHelper.php to support multilingual import

That last step of updating InstallHelper.php would be the only real patch that would eventually be committed to core.
The [WIP] patches are there to allow other people to easily test multilingual capabilities with Umami.

Problem/Motivation

The proposed approach in #2905922: Implementation issue for Layout Builder leverages local tasks to expose layout functionality. This issue is intentionally started from a problem statement, rather than solution.

This is like to create usability issues as:

• This is an overarching task, users might not expect or note it near the node edit links.
• It is not homogeneous to the other buttons, which switch the user into an edit page to edit content.
• It requires nesting of "save" and "cancel" links to be close to the overall action.

Resulting in the following design:

We should explore design alternatives that expose it on the page in such a way that its easy to find, distinct from the other "edit actions" and scalable to include the save and cancel functionality.

Proposed resolution

There are several proposed solutions, include them in the comments.

Remaining tasks

• Explore design directions
• UX and accessibility sign-off on the final direction
• Development

User interface changes

We expect to change the design of the change layout, save layout and cancel layout navigation.

API changes

-

Spin-off from #2917777-23: Layout actions can be easily missed or be confusing.

Problem/Motivation

"Save layout" is a button, but "discard changes" and "revert to default" are links. All three look like buttons though. This has a few problems:

• Links which look like buttons don't behave as expected. Buttons, when focused, are operated with enter or the space key, but links can only be operated with the enter key.
• Buttons which look like links can confuse (partially) sighted screen reader users; they are announced as links, and are missing from the "list all buttons" tool. It can also make conversations about the UI confusing (e.g. tech support says it's a button, but it isn't).

Proposed resolution

Use HTML buttons for "discard changes" and "revert to defaults"

Remaining tasks

TODO

User interface changes

Better semantics for assistive technology. More predictable operation for sighted keyboard users.

API changes

TODO

Data model changes

TODO

This is rather new: we see increasing website exceptions created by simple anonymous GET calls.
Everything in this Drupal install (and a testing web I used to reproduce) is up to date (Drupal 8.6.10). None of both uses any module with REST or json functionality.

All one gets is if trying a GET like that in a Browser is: "The website encountered an unexpected error. Please try again later. "
In the apache logs this is just a 404, if trying to visit the related watchdog detail, another error is thrown.

I hope, it's OK if I post here, how to reproduce:

wget 'http://your-testing.tld/node/1?_format=hal_json'

Formats that don't even exist should be ignored.

Formats that aren't in use at all (module not installed) probably should be ignored, too.

Problem/Motivation

When clicking on a "configure block" contextual link in layout builder, the off-canvas dialog has no title. The span.ui-dialog-title is a   HTML entity.

An unlabelled dialog is a WCAG failure at level A (3.3.2 "labels or instructions", and 4.1.2 "name, role, value").

This affects all blocks, including content fields.

Proposed resolution

Make sure the dialog has a title.

Remaining tasks

TODO.

User interface changes

Provide an essential dialog title.

API changes

TODO

Data model changes

TODO

Problem/Motivation

It's impossible to enter edit mode with really small viewport width (below 16.5em) because the contextual toolbar tab item is unclickable (floats below an another toolbar tab)

Proposed resolution

Float the item only if the toolbar is oriented.

Remaining tasks

Patch.

User interface changes

Contextual toolbar tab will be similar to other tabs if viewport width is less than 16.5em.

API changes

Nothing.

Data model changes

Nothing.

The apply button is truncated due to the flexed container and no flex or flex-grow properties defined for the flexed children (entity-moderation-form__item). Looks like adding a flex-grow: 1 to .entity-moderation-form__item would do the trick.

We have what I believe is a regression bug in IE11 with Umami's recipe and article cards being vertically oversized. From memory, this issue might be caused by IE11 calculating the height of the flexbox item based on the non scaled size of the contained images.

Screenshot of Umami 8.6.1 from BrowserStack Windows 10, IE11, middle part of front page:

We'll need to fix and test all card displays on Home, Articles, Recipes, and Article and Recipe content types.

Description of problem

I've observed cases where the off-screen canvas markup is lost when clicking a link from the primary "on-screen" which renders the contents within the off screen when the off screen canvas is currently rendered and open. It is not clear whether this is an issue related to a set of contribs or particular to a custom theme, however, by forcefully closing the dialog and re-initiating the open the problem is not observed.

Specifically, the markup within '#drupal-off-canvas' is removed when initiating the new off screen canvas request in which case the modal header, content, etc. wrapper containers are not apart of the primary returned markup in the AJAX request. I was expecting that the returned markup would include the modal header, footer and content ready for re-rendering.