@scambler

I am now thinking something like this would be better:

protected function getExposedFormActionUrl(FormStateInterface $form_state): Url {
    $request = \Drupal::request();
    try {
      $url = Url::createFromRequest(clone $request);
    }
    catch (MatchingRouteNotFoundException | ResourceNotFoundException | ParamNotConvertedException $e) {
      // If the route is not found or a route parameter is not valid,
      // fallback to the 404-page URL.
      $uri = \Drupal::configFactory()->get('system.site')->get('page.404') ?? $request->getRequestUri() ?? '<front>';
      $url = Url::fromUserInput($uri);
    }

    $url->setAbsolute();

    return $url;
  }

Otherwise the bef_links filter will take you to the homepage, instead of applying the filter on the 404 page as expected. This new way will redirect you to the 404 page and apply the filter (which is what all the other filter plugins do).

If so, then the tests should probably be expanded to make sure the BEF filters actually work on the 404 page.

I have added a test to a new branch, but must have done the process wrong, as I cannot create an MR.
https://git.drupalcode.org/issue/better_exposed_filters-3396769/-/tree/3...

The exposed filter needs to be using the Links widget to trigger the error. This might be why you cannot recreate @smustgrave.
I am working on some tests now. Hopefully I will be able to upload tomorrow.

The patch #27 fixes this issue for us as well. For us it is caused by the search404 → module.

Our bug:

1. Visit a non-existent page
2. Search404 suggests other pages (1+ of these must have an exposed form block on the page)
3. NodeSearch.php renders each result in isolation $rendered = $this->renderer->renderInIsolation($build);
4. This leads to getExposedFormActionUrl() trying to create a URL from the request, but that fails as the request is a non-existent page

The key part of the problem is having a view with an exposed form block on the 404 page (our view has "Exposed form in block:
Yes"). I have just tested without search404 and the issue still occurs (the patch still fixes it).

Thanks @quietone. I've made a bit of a mess, but I think I've done it right this time.

scambler → changed the visibility of the branch 11.x to hidden.

scambler → created an issue.

I'm not sure whats happened, but I've tried to recreate it again today and a view mode is always set, so the warning does not appear.

Steps to reproduce:

• Create a flag based on the above yaml file
• Create a view (mine is based on Webform Submissions)
• Use a table format
• Add the Flag relationship to the view
• Add a Flag Link field to allow users to flag the submissions from within the view page
• Add a Flags field to display the existing flags for that submission

scambler → created an issue.

scambler → created an issue.

scambler → created an issue.

Seconding #56... The "blue cheese" background hurts my eyes

This patch checks if there is an expected answer, and marks it as RESULT_NOT_APPLICABLE if there isn't one.

scambler → created an issue.

Patch:

scambler → created an issue.

scambler → created an issue.

If you are still experiencing this issue, make sure you remove `show_mail_in_messages: 0` from your system.site.yml, otherwise it will be re-imported and break the form again.

Attached is the proposed patch.
Whilst creating this issue I had the idea of creating a route option '_ignore_path_alias_xt' to give developers an easy way to avoid the aliasing. This is a pretty niche situation, so I will leave it to the maintainers to decide whether it's worth adding that to the default config.

scambler → created an issue.

scambler → created an issue.

scambler → created an issue.

#3 didn't work for me either, but this did: drush ev "\Drupal::service('extension.list.profile')->reset();"

Source: https://drupal.stackexchange.com/questions/314430/moved-an-old-installat...

#41 worked for me, thanks.

I was having the same problem, but found the way to do this without a patch.

class MySalesforceSubscriber implements EventSubscriberInterface {

  public function onSalesforcePullEntityValue(SalesforcePullEntityValueEvent $event) {
    $value = $event->getEntityValue();
    if (is_null($value->getValue())) {
      $value->setValue(42);
    }
  }

  public static function getSubscribedEvents() {
    return [
      SalesforceEvents::PULL_ENTITY_VALUE => ['onSalesforcePullEntityValue'],
    ];
  }
}

You need to use setValue() and you don't need to pass by reference.

This is not clear, an example added to SalesforceExampleSubscriber would be helpful.
Also, should the pass by reference be removed from the __construct in SalesforcePullEntityValueEvent.php? As far as I can tell it does nothing.

scambler → created an issue.

Corrected the patch format (missing the first line) in the previous 2 patches.

Nice! I came across the same issue. I used a similar patch and it solved my problem. The only difference is when checking for an empty line, I copied the logic from L422. I'm not sure if there are situations where this will actually make a difference, but I'll upload it anyway.

scambler → created an issue.

The old commands are out of date for the latest versions of Open Social, based on https://git.drupalcode.org/project/social/-/blob/11.4.x/modules/custom/s...

I have added the Version < 11 etc. lines to clarify the command usage.

D10 also requires Drush 11
I was hoping to use this module on our site, but it is already on PHP8 and Drush 11, so it is not compatible.

The code basically goes like this:

function my_module_node_update($node) {
  // Do some checks...
  // Do some stuff...
  
  drupal_register_shutdown_function('my_module_send_request', $node);
}

function my_module_send_request($node) {
  // Manually build up the page into a render array.
  $builder = Drupal::entityTypeManager()->getViewBuilder('node');
  $node_render_array = $builder->view($node, 'full');
  $build = [
    '#type' => 'html',
      'page' => [
        '#type' => 'page',
        '#title' => $node->label(),
        '#head_title' => [$node->label()],
        'content' => $node_render_array,
     ]
  ];
  
  Drupal::service('renderer')->renderPlain($build);

  return $build;
}

function my_module_preprocess_node(&$variables) {
  $view_id = 'watchdog';
  $display = 'page';
  if ($view = Views::getView($view_id)) {
    $view->setDisplay($display);
    $view->executeDisplay($display);
    $preview = $view->preview();
    $variables['content']['glossary'] = $preview;
    $variables['display'] = $display;
  }
}

The problem occurs in the renderPlain() when inside the preprocess node and executing/previewing the view. I have tried to tweak this so that it can work on a vanilla site, but I haven't tested it myself yet.

Also worth noting that we have another process that is calls my_module_send_request manually and it works fine. Which further points at the shutdown function being the 'problem'.

@cilefen I will create some sample code to help reproduce when I next get some free time

*Correcting file path for patch 2

This next patch is more of a suggestion and not one I will be using on a production site (unless others approve it) as I am not confident of the consequences elsewhere on the site.

I have found the line which is causing the error and have reverted it to what it was on 9.5.3.

scambler → created an issue.

scambler → created an issue.

I was getting this error: Refused to execute script from '...' because its MIME type ('text/plain') is not executable, and strict MIME type checking is enabled.

This was on a .js file using the private file system. After applying patch #4, this is now getting the correct mime type and working as expected.

Drupal version: 9.5.3

Thanks @kevin.dutra