Destination query parameter goes missing when dropdown button is rendered

I believe the issue is located in:

docroot/themes/bootstrap/src/Plugin/Preprocess/BootstrapDropdown.php:61

  protected function preprocessLinks(Variables $variables, $hook, array $info) {
    // Convert "dropbutton" theme suggestion variables.
    if (Unicode::strpos($variables->theme_hook_original, 'links__dropbutton') !== FALSE && !empty($variables->links)) {
      $operations = !!Unicode::strpos($variables->theme_hook_original, 'operations');

      // Normal dropbutton links are not actually render arrays, convert them.
      foreach ($variables->links as &$link) {
        if (isset($link['title']) && $link['url']) {
          $link = [
            '#type' => 'link',
            '#title' => $link['title'],
            '#url' => $link['url'],
          ];
        }
      }

Line 61 ("$link = [") clearly overwrites by reference the original link structure wiping out the additional information like 'query'

I took a stab at various rendering methods to produce a url that would include the fully render link but my D8Fu is lacking today. Is it Friday yet?

Problem solved after some additional debugging. The getDefaultOperations method that was used in the custom code was based off of the NodeListBuilder.php method as an example of how to do that in core.

The core node method applies the 'query' portion outside of the Url 'url object, and is rendered later on.

The more up to date and correct way to do this is to apply use the Url->setOption() method on the Url object itself instead:

  protected function getDefaultOperations(EntityInterface $entity) {
    $operations = parent::getDefaultOperations($entity);

    /** @var RedirectDestination $redirectService */
    $redirectService = \Drupal::service('redirect.destination');
    $destination = $redirectService->getAsArray();
    foreach ($operations as $key => $operation) {
      $operations[$key]['url']->setOption('query', $destination);
    }
    return $operations;
  }

This issue looks to be an artifact of the many many ways Url's can be generated and the current state of deprecation of render arrays of doom.

Why have you set this issue to "fixed" when no patch has been provided, nor a duplicate issue linked (where the fix occurs)?

However, that being said, this sounds like a core issue so I'm moving it to the appropriate queue.

Mainly because the solution was in a custom module and not technically a Bootstrap issue as it turned out. Perhaps 'wont fix' or 'works as designed' are more appropriate.
This is essentially an issue of deprecations and implementation being ahead of core methods.

Notice that using bootstrap as a base theme the Operations on the admin/content and admin/people list builders don't have their destination query parameters as part of the url in the buttons?

Both of those list builders are setting the ['query'] in the $operation itself when it should really be the setOption('query', $destination) on the Url object.

I have been looking through the D8 queue to see if there is an existing issue but haven't found one specifically and am considering opening one.

This sounds very similar to #2726471: active class doesn't get added to links LI when the URL has a query, possibly related?

this not seems a core issue and is reproducible only using bootstrap theme. With bartik, seven and other contrib theme the dropbuttons behavior is correct.
Links attributes and url options are not retained for dropbuttons probably because they are not taken in account in BootstrapDropdown::preprocessLinks()?

With this issue block_place module is unusable when bootstrap is the active theme

Okay, so to get this working with the current theme/core versions, here is a patch that should solve the problem. I'd appreciate your reviews.

+++ b/src/Plugin/Preprocess/BootstrapDropdown.php
@@ -54,6 +54,13 @@ class BootstrapDropdown extends PreprocessBase implements PreprocessInterface {
+            $link['url']->setOption('query', ($url_query ?: []) + $link['query']);

I think this should really use NestedArray::mergeDeep here. Also, I think it would make more sense to assign the empty array to the variable above, not while doing the other operations below.

No problem, here is the updated patch ;)