Using the AJAX option for views pages breaks the destination url in operation links when filtering repeatedly. Steps to reproduce:

1. Perform a standard installation of Drupal 8.3.x
2. Edit the default "People" view under admin/structure/views, enable the "Use AJAX" option in the advanced settings and save
3. Go to admin/people
4. Hover the edit link for the only user, the destination parameter starts with "admin/people"
5. Click the filter button
6. Hover the edit link again, the destination parameter still starts with "admin/people"
7. Click the filter button again
8. Hover the edit link again, the destination parameter now starts with "views/ajax"

_node_revision_access() hides the revisions tab if there's only one revision of a node. pwolanin mentioned at Drupalcon that this had been flagged as confusing (not sure who by so this is a bit anecdotal but it doesn't surprise me) - sometimes the tab is there, sometimes it's not. The page works fine if there's only one revision - just lists a single revision, and that way you know that revisions are enabled / that you have access to them etc.

It also saves us a COUNT() query on the node table when viewing nodes.

Problem/Motivation

From #2986294: Remove $context['user'] from LoggerChannel::log.

      try {
        if ($this->currentUser) {
          $context['uid'] = $this->currentUser->id();
        }
      }
      catch (\Exception $e) {
        // An exception might be thrown if the database connection is not
        // available or due to another unexpected reason. It is more important
        // to log the error that we already have so any additional exceptions
        // are ignored.
      }

As far as I can see there is never a situation anymore when getting the ID from the current_user service can throw an exception. This was resolved in #2753733: AccountProxy can do unnecessary user loads to get an ID

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Most methods on ConfirmFormInterface are documented as returning a string.

However, in practice, their implementations are typically like:

return $this->t('something');

meaning they really return a TranslatableMarkup, not a string.

Drupal 8 has an absolutely brilliant User Guide at: https://www.drupal.org/docs/user_guide/en/index.html. It's likely to be a key place that new users and evaluators of Drupal start.

Now that Umami is in core, it would be good to add a page in the user guide explaining what Umami is and how to use it to evaluate and learn Drupal.

I've discussed this with @eli-t and we made this plan:
1) he will ask Gabor about this on the weekly call, and find out what the process is, and who we need to speak to
2) I'll research the styleguide for this user guide
3) I'll start a google doc for us to begin collaborating on a draft page for the guide

I have noticed that a search on a single word, the same node is rendered in the search results.
The nodes are not on the same results page although their weights are the same.

Problem/Motivation

When using page manager to override a node view page, there's a fatal error on adding a content type condition as variant selection criteria:

Error: Call to undefined method Drupal\Core\Plugin\Context\EntityContextDefinition::setConstraint() in /var/www/core/lib/Drupal/Core/Plugin/Context/ContextDefinition.php on line 273 #0 /var/www/modules/ctools/src/Plugin/Condition/NodeType.php(37): Drupal\Core\Plugin\Context\ContextDefinition->setConstraints(Array)
#1 /var/www/modules/ctools/src/Plugin/Condition/NodeType.php(17): Drupal\ctools\Plugin\Condition\NodeType->removeConstraints(Array)
#2 /var/www/modules/ctools/src/Form/ConditionConfigure.php(117): Drupal\ctools\Plugin\Condition\NodeType->applyConstraints(Array)
#3 [internal function]: Drupal\ctools\Form\ConditionConfigure->submitForm(Array, Object(Drupal\Core\Form\FormState))
#4 /var/www/core/lib/Drupal/Core/Form/FormSubmitter.php(111): call_user_func_array(Array, Array)
#5 /var/www/core/lib/Drupal/Core/Form/FormSubmitter.php(51): Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object(Drupal\Core\Form\FormState))
#6 /var/www/core/lib/Drupal/Core/Form/FormBuilder.php(589): Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object(Drupal\Core\Form\FormState))
#7 /var/www/core/lib/Drupal/Core/Form/FormBuilder.php(318): Drupal\Core\Form\FormBuilder->processForm('ctools_conditio...', Array, Object(Drupal\Core\Form\FormState))
#8 /var/www/core/lib/Drupal/Core/Controller/FormController.php(93): Drupal\Core\Form\FormBuilder->buildForm('ctools_conditio...', Object(Drupal\Core\Form\FormState))
#9 [internal function]: Drupal\Core\Controller\FormController->getContentResult(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\RouteMatch))
#10 /var/www/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)

It looks like there's a simple mistake in \Drupal\Core\Plugin\Context\ContextDefinition::setConstraints() which tries to proxy the call to \Drupal\Core\Plugin\Context\EntityContextDefinition::setConstraint() instead of ::setConstraints($constraints) (added in #2986033: [regression] The BC layer for EntityContextDefinition in ContextDefinition is incomplete).

Proposed resolution

Proxy to the correct method - \Drupal\Core\Plugin\Context\EntityContextDefinition::setConstraints().

Remaining tasks

• Needs review by someone who understands the BC layer!
• Needs tests

Original report by Siavash

Hello,

I'm having some issues with a freshly installed Drupal site with Panels + Page Manager installed. Tried with both latest release and dev version.

I'm trying to create a variation for the node path for a specific content type. But when I go to save the content types or bundle types I get an ajax error and I'm unable to save the settings. (See screenshot)

PHP log ha an error:
Error: Call to undefined method Drupal\Core\Plugin\Context\EntityContextDefinition::setConstraint() in Drupal\Core\Plugin\Context\ContextDefinition->setConstraints() (line 273 of .../web/core/lib/Drupal/Core/Plugin/Context/ContextDefinition.php) #0

Would appreciate any support, thanks!

Updated: Comment #393

Problem/Motivation

With Drupal 7's vastly-improved install profile functionality, and the recently-improved drupal.org distribution packaging infrastructure, many new install profiles have been created, and they are awesome.

However, install profiles are not inheritable, so if you want to, say, take Drupal Commons, and base your site off of it, but add one or two extra modules in your own customized install profile, you have to clone the entire install profile and change it to your needs. Allowing install profiles to declare base profiles (just like themes can declare base themes) would drastically simplify customizations to existing distributions by:

• Inheriting configuration from a parent install profile (base-profile)
• Overriding specific configuration from the base-profile
• Inheriting customizations in the installer from the base-profile
• Having additional installer tasks and form items to customize their own "start-state"

Additional motivations are detailed on Dries's blog post.

Proposed resolution

• Modify the module load system to take into account base install profiles.
• Modify the install profile system to run parent installer(s) in the correct order.
• One proposed solution was to simply use modules instead of profile inheritance. This was discussedatlength and the prevailing attitude was that the functionality for profile inheritance has valuable use cases that cannot be solved by modules alone.
• An early resolution was to include a tag to exclude dependencies and themes. In an effort to clearly define focus for this patch, this functionality was removed from this patch. The use case for excluded_dependencies and excluded_themes is still very much valid, so this feature request has been given its own issue.

Remaining tasks

• Create plan
• Write useful issue summary
• Fix issue from #405
• Fix issue from #412
• Update Change Record.
• Make tests pass.
• Extensively test this patch against a real-world base-profile
• Add to existing documentation page (To be published only after patch is applied.)
• Review Documentation to make sure they are up-to-date.

User interface changes

None.

API changes

Install profiles can define base profiles using the syntax base profile: BASE_PROFILE inside their .info.yml files.

Or, override dependencies from the base profile using the syntax:

base profile:
  name: BASE_PROFILE

Related Issues

• For D7 patch tracking: #2067229: Allow install profiles to declare base profiles for Drupal 7
• For D8 info inheritance patch tracking: #2692403: Make info and configuration inheritable in profiles
• For D8 excluded_dependencies and excluded_themes: #2914389: Allow profiles to exclude dependencies of their parent

Problem/Motivation

\Drupal\migrate\Plugin\migrate\process\Migration currently uses the check if (!array_filter($value)) to check if the input is empty, and if so it throws an exception. This means that any false-ish value will cause a throw: NULL, FALSE, empty string, zero, etc.

Zero in particular is a perfectly legitimate source-ID value for another migration. It's pretty common to use zero-based numbering for identifiers, for example.

Proposed resolution

Don't consider zero an exceptional value.
Update the documentation

Remaining tasks

• Update the Migration process, including documentation
• Write tests
• See if any migrations in core care about this

User interface changes

N/A

API changes

Small change, but migrate is experimental.

Data model changes

None.

Problem/Motivation

The table drag handles are no longer keyboard-accessible. These are used in many places in the content-authoring and site-building UIs.

When table drag handles have focus, the up/down arrow keys should re-order the table rows. This has stopped working. It was working as of D8.0.0-beta10, and works in D7.43.

Where the table rows have a tree structure (e.g. menu UI) the left/right keys let a user change the indented (parent) relationship. The left/right keys are still working as expected.

Steps to Reproduce

Note: if testing with macOS, you'll need to make sure the tab key is configured to cycle focus through all links and controls - follow these Detailed instructions.

1. Install 7.43
2. Admin > Structure > Menus > Management >list links
   /#overlay=admin/structure/menu/manage/management
3. Tab a bunch until focus is on the arrow(handle) for SubMenuItem (i.e. Dashboard)
   

Up Arrow

1. Focus on Dashboard
2. Press up arrow
   
3. left/right arrow doesn't do anything

Down Arrow

1. Focus on Dashboard
2. Press down arrow
   
3. left/right arrow doesn't do anything

Left/Right Arrow

1. Focus on Dashboard
2. Press down arrow a lot to get it under Taxonomy.
3. left arrow does something
   
4. right arrow does something
   

Proposed resolution

Restore the old keyboard behaviour:

• When a drag handle has focus, up-down arrow keys change the vertical order of the table rows.
• When drag handles are used on tree structures, the left/right keys can be used to control indentation.

Remaining tasks

• Find out where the regression happened. - DONE. It was broken by commit dcf9ab4, between 8.0.0-beta11 and 8.0.0-beta12.
• Fix it - restore old keyboard behaviour.

User interface changes

None as such. This is about restoring keyboard-accessible behaviour that stopped working. No changes are intended for pointing devices such as mice.

API changes

None.

Data model changes

None.

Problem/Motivation

For now, the CKEditorIntegrationTest for the DrupalImageCaption plugin doesn't exists.
I would suggest a new method for testDrupalImageCaptionDialog into the CKEditorIntegrationTest which will check the basic behaviours of DrupalImageCaption CKEditor Plugin.

Proposed resolution

Add a new testDrupalImageCaptionDialog method.

Should checks for:

• Caption's checkbox is visible when the filter_caption is enable
• Caption's checkbox is not visible when the filter_caption is disable

Remaining tasks

Review & Improve

User interface changes

None

API changes

None

Data model changes

None

We want to optimize (= speed up) how menu_router_build() writes information into the menu_router table.
This will speed up not only explicitly requested menu rebuilds, but also content type configuration form submits, views configuration submits, and other things.

This issue going into D8 is a requirement for
#1170278: Introduce hook_menu_router_update()

menu_router vs menu_links

A menu rebuild consists of two parts (in D6 / D7):

1. menu_router_build(), dealing with the menu_router table.
   • Invoke hook_menu() on all modules. -> not discussed here.
   • Update the menu_router table, with the information from hook_menu().
2. _menu_navigation_links_rebuild(), dealing with the menu_links table.
   -> discussed elsewhere

All of these need optimization, but the second one is dealt with in another issue,
#1010480: Optimize _menu_navigation_links_rebuild()

In this issue we only discuss how the data is saved into the menu_router table.

Drupal versions: D6 big speedup, D7/D8 do also benefit

The improvement has the biggest benefit for Drupal 6.
However, also D7 and D8 can benefit.

Diff-based optimization approach

In original D6, menu_router_build will erase the entire menu_router table, and then rewrite it row by row.
In original D7 / D8, menu_router_build will also erase the table, but then rewrite it in a few big queries, each writing a bunch of rows. This is faster than D6, but can still be improved.

The patches (see below) does a big select query, to compare the table contents with the new data and build a diff (rows to insert, rows to update, rows to delete).
In an average case, this diff will be just a few rows.
It will then execute the diff.

• Current D6 patch in #512962-229: Optimize menu_router_build() / _menu_router_save().
• Current D8 patch in #512962-246: Optimize menu_router_build() / _menu_router_save().
• D8 patch with benchmarks (ditto).

The diff data can be made available to other processes, such as _menu_navigation_links_rebuild(). This is to be discussed in another issue.
#1170278: Introduce hook_menu_router_update()

Memory considerations

It was argued that the diff-based approach could have an unacceptable cost in memory, by loading the full menu router with a big SELECT. This would affect both PHP memory and SQL memory.

However: There are already other situations in Drupal where we load the full menu router table, or something as big as it:
- During menu rebuild, we do a module_invoke_all() on hook_menu(). The data generated this way will become the new menu_router, so it has more or less the same size.
- Building the admin menu (contrib) will load something as big as menu_router (both SQL and PHP memory). The same, if we want to show a fully expanded system navigation menu.
- The form for editing the admin menu or system navigation menu. Building this form needs to load a menu with around as many items as the menu_router table.

Benchmarking: Distinguish different parts of menu rebuild.

We need to make sure to benchmark the different parts of menu rebuild separately.
While the above patch does optimize what it's designed for by sth like factor 10, it does have no effects on invocation of hook_menu, or on rebuild of menu_links. So finally the menu rebuild might be around 1/3 faster.

Original text (quite out of date)

As can be seen in various discussions on this site, the function menu_router is a major cause of trouble. See
menu_link_save making multiple (60+) duplicate queries on admin/build/modules
menu_rebuild causes site to lock up
No-op and slow queries during menu rebuild
etc, or try a google search to find more people complain (some of them being duplicates, if I remember right).

Looking at query logs and stack traces, it seems to me that the implementation is far from optimal. For instance, _menu_update_parental_status is called tons of times, and each call causes a SELECT query.

Now, this my naive idea of a decent implementation:
- One big query to load the menu_links and menu_router tables into php arrays.
- Do some computations (without any database queries!!).
- Write the changes to the DB, if any.
- Add some locking mechanics to prevent other requests from doing a menu_rebuild at the same time, or whatever other bad things might happen. But, please don't wait for the locking framework for long operations.

This would save us a lot of queries for this frequent operation.

Thanks,
donquixote

I'd just upgrade my site from 8.4.5 to release 8.5.0 (php7.1) and get now the following exception with one of my views.
This view worked fine before with 8.4.5.

The website encountered an unexpected error. Please try again later.
TypeError: Argument 1 passed to Drupal\views\Plugin\views\field\EntityOperations::getEntityTranslation() must implement interface Drupal\Core\Entity\EntityInterface, null given, called in /srv/devel/deploy/.../releases/20180216111106/core/modules/views/src/Plugin/views/field/EntityOperations.php on line 111 in Drupal\views\Plugin\views\field\EntityOperations->getEntityTranslation() (line 69 of core/modules/views/src/Entity/Render/EntityTranslationRenderTrait.php).

Drupal\views\Plugin\views\field\EntityOperations->getEntityTranslation(NULL, Object) (Line: 111)
Drupal\views\Plugin\views\field\EntityOperations->render(Object) (Line: 1146)
Drupal\views\Plugin\views\field\FieldPluginBase->advancedRender(Object) (Line: 226)
template_preprocess_views_view_field(Array, 'views_view_field', Array) (Line: 287)
Drupal\Core\Theme\ThemeManager->render('views_view_field', Array) (Line: 437)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array) (Line: 1738)
Drupal\views\Plugin\views\field\FieldPluginBase->theme(Object) (Line: 761)
Drupal\views\Plugin\views\style\StylePluginBase->elementPreRenderRow(Array)
call_user_func(Array, Array) (Line: 378)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array) (Line: 709)
Drupal\views\Plugin\views\style\StylePluginBase->renderFields(Array) (Line: 576)
Drupal\views\Plugin\views\style\StylePluginBase->renderGrouping(Array, Array, 1) (Line: 468)
Drupal\views\Plugin\views\style\StylePluginBase->render(Array) (Line: 2112)
Drupal\views\Plugin\views\display\DisplayPluginBase->render() (Line: 131)
Drupal\webprofiler\Views\TraceableViewExecutable->render() (Line: 183)
Drupal\views\Plugin\views\display\Page->execute() (Line: 1627)
Drupal\views\ViewExecutable->executeDisplay('page_1', Array) (Line: 77)
Drupal\views\Element\View::preRenderViewElement(Array)
call_user_func(Array, Array) (Line: 378)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 226)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 227)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 117)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object) (Line: 76)
Drupal\webprofiler\EventDispatcher\TraceableEventDispatcher->dispatch('kernel.view', Object) (Line: 156)
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: 38)
Drupal\webprofiler\StackMiddleware\WebprofilerMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 657)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Here's a new article about oatmeal for the Umami Demo and this issue is to get the article reviewed and added into the articles section of Umami.

Problem/Motivation

When ajax and contextual links are enabled on a view, after triggering an ajax reload the contextual links block disappears.

Steps to reproduce:
- Go to the core Content view configuration
- Enable contextual filters
- Enable ajax
- Add enough content to show the pager (or set the pager amount low enough)
- Go to the content view
- See the contextual links
- Navigate to the next page
- Don't see the contextual link

Proposed resolution

Make sure the contextual link are added after a ajax reload.

Remaining tasks

- find the problem
- fix
- write tests

User interface changes

The contextual links don't disappear.

Original report

i have a view page of titles with a mini-pager. Views AJAX setting is on. On page load I the top rhs context menu is active on hover. when i page the view i lose it until page reload.

This is also breaking ajax_link_api module functionality in the same way. i.e. ajax breaks after first pager click.

Problem/Motivation

Pretty much all of the other issues that are asking for OO hook implementations all run into the same problem: we have an unsettlingly large number of places throughout core that build a function name and then call it with some arguments, rather than calling ModuleHandler->invoke() or ModuleHandler->invokeAll().

This actively prevents implementation of a contrib module that, as an example, extends ModuleHandler and emits events when hooks are invoked. Pretty much anywhere where ModuleHandlerInterface->getImplementations() is used outside of ModuleHandler, there's likely a function name being constructed, and in the vast majority of these cases, it's unnecessary.

Proposed resolution

• Introduce two new hook invocation methods that take an additional callable (often, but not limited to, closures) that takes care of calling each individual hook implementation. Code currently calling ModuleHandlerInterface::getImplementations() to invoke hooks themselves can use custom callables to customize their hook invocations. This is useful to pass on extra parameters or process return values.
• Mark ModuleHandlerInterface::getImplementations() deprecated, to encourage developers to use the (new) ::invoke*() methods instead.

Remaining tasks

Convert all remaining calls to ModuleHandlerInterface::getImplementations() that do not cause test failures. If that's because of a lack of coverage, decide what to do about that.

User interface changes

None.

API changes

None. Existing APIs are merely extended. ModuleHandlerInterface is extended, which is not considered a break (@catch in #29)

Data model changes

None.

I am trying to create a node comment via REST. The user is authenticated with session cookie and the comment is created and assigned to anonymous user. If I inlcude the uid properly, get an error because the user does not has the right to administer comments (as intended). Should the uid not be set automatically?

Here is my JSON request:

{"_links":
{"type":{"href":"http://zauberfrauen.lan/community/rest/type/comment/comment"},
"http://zauberfrauen.lan/community/rest/relation/comment/comment/uid":[{"href":"http://zauberfrauen.lan/community/user/137"}],
"http://zauberfrauen.lan/community/rest/relation/comment/comment/entity_id":[{"href":"http://zauberfrauen.lan/community/node/14"}]},
"entity_id":[{"target_id":"14"}],
"uid": [{"target_id": "137"}],
"entity_type":[{"value":"node"}],
"comment_type":[{"target_id":"comment"}],
"field_name":[{"value":"comment"}],
"subject":[{"value":"Kommentar"}],
"comment_body":[{"value":"Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus et eget bibendum sodales, augue velit cursus nunc,"}
]}

Problem/Motivation

The LayoutBuilderTaskDeriver hardcodes local tasks for sectionStorage plugins.

Proposed resolution

The LayoutBuilderTaskDeriver should let the plugins build their own local tasks.

Remaining tasks

N/A

User interface changes

N/A

API changes

API addition: section storage plugins are now directly consulted when building local tasks (similar to how it is consulted for route building).

Data model changes

N/A

Problem/Motivation

There are a lot of calls to db_query('SELECT COUNT(*) ...');.

Find for example just those in test code with find . -type f -name '*Test.php' -exec grep -Ei "QUERY.*COUNT.*\(\*\)" {} \+.

There's a better and more db abstract way to achieve the same with $injected_database->select(...)->countQuery()

Proposed resolution

Convert those to $injected_database->select(...)->countQuery() in test code. Start here with DatabaseTestBase kernel tests.

Remaining tasks

User interface changes

API changes

Data model changes

Entity Reference Plugins have weird behaviour around their ID and other properties which make them a timesink when trying to create one.

This should be fixed -- see #2649712: Entity reference selection plugins break when not following an undocumented ID pattern (which also has several developers commenting on how they've wasted time figuring it out).

A fix will not be straightforward, so until that lands, the documentation should be improved so we stop wasting developers' time.

Things to decide here before a patch is worked on:

- where should the docs go: the plugin manager / the plugin base class / the plugin interface?
- what do the docs need to say?

To start with:

- An ERSP must declare its ID and group in one of the following forms:
-- group: GROUP, id: GROUP:ID (the id has the group as a prefix)
-- group: ID, id: ID (the id and the group are identical)
- the weight property is not used to order them in the UI, but rather to select the 'best' plugin within a group