🇨🇦Canada @efrainh

Hi, I confirm this issue is happening when using Better exposed filters with the reset button + Views Reference Field 8.x-2.0-beta6.
I tested the patch #3 and it kind of worked, but now when we press the Reset button, it redirects first to a URL with a query string and then to the page without the query string, so it reloads twice.

I have a multilingual D9 site and I had the same issue with an entity reference (media) field, it is an untranslatable and required field. I tested the patch #11 and it worked fine. Thanks @ezeedub.

I noticed that this was fixed on Drupal 10, because while upgrading the site (on another branch) and without the patch we didn't have this issue.

I just found that in my case it was not working because we didn't have the module "Password Compatibility" enabled.

Hello, I have the same issue, users can only login via SAML and not with Drupal login, even if their role is selected in the configuration. I'm on Drupal 10.1.2 and using SAML Auth 8.x-3.9.

Hello, I found this issue on a website I'm working on, and I tried another approach to solve it.
We have a some views that create the pages of the pages of some specific taxonomy terms, and we configured custom breadcrumbs for each one of them, so what I did was:

I defined a custom service "breadcrumb" in a custom module we have:

File: /modules/custom/my_custom_module/my_custom_module.services.yml

my_custom_module.breadcrumb:
    class: Drupal\my_custom_module\TermsBreadcrumbBuilder
    arguments: ['@config.factory', '@entity_type.manager', '@language_manager', '@request_stack', '@title_resolver', '@token', '@path_alias.manager', '@path.matcher', '@router.admin_context']
    tags:
      - { name: breadcrumb_builder, priority: 1011 }

File: /modules/custom/my_custom_module/src/TermsBreadcrumbBuilder.php

In the class specified in the service, I used the "build" method to remove the parameters "view_id" and "display_id" and left taxonomy_term as the first one, and at the end I called the parent method, so the "build" method of the "Custom Breadcrumb" module runs using the right parameter.

namespace Drupal\my_custom_module;
use Drupal\custom_breadcrumbs\BreadcrumbBuilder;
use Drupal\Core\Routing\RouteMatchInterface;
/**
 * Class TermsBreadcrumbBuilder.
 *
 * The module Custom Breadcrumbs doesn't work on Terms pages built with Views
 * because it expects the first parameter to be the taxonomy term,
 * but when the term pages are built with views, the 2 firsts parameters are
 * the View ID and the Display ID.
 * https://www.drupal.org/project/custom_breadcrumbs/issues/3258374
 */
class TermsBreadcrumbBuilder extends BreadcrumbBuilder {
  /**
   * {@inheritdoc}
   */
  public function build(RouteMatchInterface $route_match) {
    // If it's a term page, remove parameters so the breadcrumb work correctly.
    $params = $route_match->getParameters();
    $taxonomy_term = $params->get('taxonomy_term');
    // If the page is a taxonomy term, then the parameter taxonomy_term exists.
    if (isset($taxonomy_term)) {
      // Selected taxonomies that have breadcrumb (We use other way to build the breadcrumb for the others).
      $taxonomy_with_breadcrumb = ['my_taxonomy_1', 'my_taxonomy_2', 'my_taxonomy_3];
      // Get the taxonomy of the current page.
      $taxonomy = $taxonomy_term->bundle();
      if (in_array($taxonomy, $taxonomy_with_breadcrumb)) {
        // Remove firsts parameters so the taxonomy term is first.
        $params->remove('view_id');
        $params->remove('display_id');
      }
    }
    return parent::build($route_match);
  }
}

I was thinking about creating a patch adding some of this code to validate if it's a taxonomy and removing the parameters. What do you think, lamp5?

Hi @ girdevmx, does that happen with any of the options in the configuration?
Please provide your Drupal core and PHP version, so I can try to reproduce the issue.

Hi @ehossack, I was testing the new feature, and it looks great, but I have a few suggestions:

1. The field 'allowed-embedding-substr' should be a textarea, for the cases where we need to have more than one path.
2. Using str_contains to check the path might lead to allow a whole group of pages that we might not want, for example if we configure /blog, it will also allow all the blog articles that have the URL like /blog/article1 and /blog/article2. I understand that in your case you will have all the pages with the path /embedded, but for other sites that might be different. We could think of accepting tokens like and *.

What do you think?

Thanks for testing, guys.

I included the patch in the new release: https://www.drupal.org/project/x_frame_options/releases/8.x-1.3 →

I could not reproduce this issue on Drupal 9.5.3 with PHP 8.0, but when I upgraded PHP to version 8.1.14, I started seeing the header X-Frame-Options: SAMEORIGIN, using no matter what Directive in the configuration.
I lowered the priority, so it runs after, and included it in a new release https://www.drupal.org/project/x_frame_options/releases/8.x-1.3 → .

Hi Christopher Riley, thanks for reporting this issue. I'm on Dupal 9.5.2, I just upgraded my PHP from 8.0 to 8.1, reinstalled the module and went to configure it, but I couldn't reproduce that error.
Line 43 has this: $allow_from_uri = Html::escape($this->config->get('x_frame_options_configuration.allow-from-uri', ''));
So, if the value is null, then the escape function would receive an empty string.
Can you please provide more information?

Hey guys, thanks for reporting this issue, specially
mr_scumbag.
Sorry for the delay, I'm trying to fix it now.

Hi, thanks for reporting this issue. I believe it's the same reported here: https://www.drupal.org/project/x_frame_options/issues/3240933 🐛 X-Frame-Options is always SAMEORIGIN in response header Fixed
I'm working to fix it.

Thanks for your request and your code contribution ehossack.
Updating ticket so the community help us testing it.

When trying to import from a CSV file, we got this same error on our site, but it was simply that we missed the columns names in the file:

source,destination,language,status_code

We added them at the top of the file and we could import normally.
We are using Drupal 9.5.3 and module version 2.0.6

Thanks for the patch, we tested it, and it works fine on version 1.0.6, using Drupal 9.5.1