🇺🇸United States @mark_fullmer

What did you have in mind? You wouldn't want to add a test for each of the ~369 mappings.

I agree that this doesn't seem like a typical thing that Drupal core would add test coverage for, namely, a test that verifies that all of the extensions defined in the standard installation profile's media types are present in the MimeTypeGuesser array. I think automated test coverage *would* be more appropriate for 🐛 Deprecated function: explode(): Passing null to parameter #2 ($string) of type string is deprecated in Drupal\file\Plugin\Field\FieldFormatter\FileMediaFormatterBase::mimeTypeApplies() (line 171 of Plugin/Field/FieldFormatter/FileMediaFormatterBase.php) Needs work , to demonstrate that when unknown file types are declared, they do not trigger a PHP warning, and/or are handled through appropriate form validation.

So, for this issue, I think it might be most appropriate to start by adding steps to reproduce, to show what "problem" there is when the MimeTypeGuesser does not include some of the file extensions defined in the standard installation profile's document media type configuration. Something like:

1. Install the "standard" installation profile
2. Enable the media_library module
3. Go to Structure > Media Types > Document > Edit > Manage display
4. [Describe resulting problem]

Hi @rhovland! Thanks for contacting me about maintainership. I've added you as a maintainer to https://www.drupal.org/project/media_library_theme_reset → . You should have all appropriate administrative permissions. Given that you consider the module still relevant, feel free to update the project page to remove the statement about the module being deprecated.

Best,
Mark Fullmer

The problem is that if you follow that documentation, you end up with unnecessary nested block templates.

I think this depends on what your block.html.twig file is doing. For example, Olivero's template renders the additional divs:

<div{{ attributes.addClass(classes) }}>
  {{ title_prefix }}
  {% if label %}
    <h2{{ title_attributes.addClass('block__title') }}>{{ label }}</h2>
  {% endif %}
  {{ title_suffix }}
  {% block content %}
    <div{{ content_attributes.addClass('block__content') }}>
      {{ content }}
    </div>
  {% endblock %}
</div>

...whereas Stable9, for example, does not:

<div{{ attributes }}>
  {{ title_prefix }}
  {% if label %}
    <h2{{ title_attributes }}>{{ label }}</h2>
  {% endif %}
  {{ title_suffix }}
  {% block content %}
    {{ content }}
  {% endblock %}
</div>

If a site is defining a custom block plugin, I think it would be reasonable to "solve" this issue by customizing a block-level template, either site-wide, or for a subset of blocks, which can be done through Twig template suggestions.

I think this issue is "works as designed."

Thanks for reporting this. I am unable to reproduce the problem using a standard Drupal installation of 10.3 with the 3.x branch of this module. Below are the steps I took. Can you provide more specific steps to reproduce this problem? (Please make sure this problem occurs with a standard Drupal installation without any other modules first!)

1. Install the "standard" installation of Drupal.
2. composer require drupal/url_embed:^3
3. Enable the url_embed module.
4. Add a "Link" field to the Basic Page node type.
5. Set the field formatter to "Embedded URL"
6. Add a Basic page node and populate the Link field with a valid embeddable URL. -- no problems.
7. Add the URL Embed button to the "Basic HTML" text format and enable the "Display embedded URLs" text format filter.
8. Create a Basic page and use the URL Embed button in the CKEditor 5 toolbar to embed a URL -- no problems.

I can confirm that the answer in #11 worked for me -- it was resolvable by configuring the GD toolkit "correctly".

Note: this was updated in the README, but is still out of date on the project page.

I tested this (steps listed below), and everything worked well, with the exception of one thing. For the non-recurring date formatter, the legacy configuration was not "found" initially. As a result, an existing configuration will fail to render the date augmenters. The attached diff shows my suggestion for checking for that legacy location. With that change in place, both the recurring and non-recurring field instances successfully displayed date augmenters, both prior to and after the configuration being re-saved.

Testing steps

1. With the 4.1.x branch of smart_date and the addtocal_augment module used:
2. Create two fields on a node, both of type "smartdate," one using "smart_date_recur," one not using "smart_date_recur."
3. Configure both fields' formatters to display an date augmenter plugin. (I used addtocal_augment).
4. When a node is created & viewed, both fields display the date augmenter. (So far, so good).
5. Switch to the merge request.
6. Rebuild the cache.
7. When a node is created & viewed, the non-recurring field no longer displays the date augmenter. (The diff, attached, makes this step work as expected).
8. Re-save the field formatter settings for both fields. As expected, the non-recurring field's structure will change:

Before:

    third_party_settings:
      date_augmenter:
        status:
          addtocal: '1'

After:

    third_party_settings:
      date_augmenter:
        instances:
          status:
            addtocal: true

9. Viewing the node displays the date augmenter for both fields (works).

Assigning myself for review of the MR...

To all followers of this issue: there is a different feature request related to multilingual capabilities that looks ready to be included in the module. If this topic is important to you in how sites use Linkit, please review ✨ Allow "Linkit URL converter" filter to generate links based on the language of the current page, rather than the language of the referenced entity Postponed: needs info and leave any applicable comments. I don't see that issue as incompatible with this one, since it is implemented as a configurable option. I just want to make folks following this issue aware of that one. Thanks!

well, we now have a test that does indeed fail in the tests-only feature, and passes with all the changes :)

This is wonderful! Thanks so much. As a maintainer of the Linkit module, I am open to adding this to the module, given that it is an opt-in configurable feature. I just want to make sure everyone who is invested in ✨ Multilingual support: Allow linking to specific translations Needs review as another multilingual feature request is still accommodated. I'll leave a comment on that issue for the followers to review this issue's updated description and where it's landed to allow a chance for more feedback before proceeding.

Please note that the merge request here references a deprecation that was introduced in Drupal 10.3 and will be removed in Drupal 12.0.0. Therefore, the changes staged in this merge request are not required for Drupal 11 compatibility.

mark_fullmer → created an issue.

I think the size is too big though? It’s supposed to be less than 10kb if possible.

Sure thing. I've updated the image so that it is now <10KB!

Closing in favor of 📌 Drupal 11 compatibility Active

Thanks, all! I'm going to close this in favor of 📌 Drupal 11 compatibility Active , which the maintainers will work on now...

Thanks, @segovia, for the more modern approach to the responsive embed in https://git.drupalcode.org/project/url_embed/-/merge_requests/9/diffs?co... !

With a few adjustments, tests pass. This is good to add to the 3.x branch, with the understanding that it is designed as an opt-in feature, so it will not negatively affect sites already using this module.

Closing: this module already provides Drupal 10 and 11 support in the 3.x branch.

Is this issue again in 6.1.4 and 7.0.0-alpha1 or did I miss something?
With "Direct URL to media file entity" option I see an URL like media/XXX.

I just functionally tested both 6.1.4 and the latest commit on the 7.x branch, and in both cases, the resulting rendered link to the media entity does go, as expected, to the media file (e.g., sites/default/files). To be clear, the source code in CKEditor will show media/XXX as in the following example, but when rendered, it does provide the link to the filesystem.

    <a href="/media/1" data-entity-type="media" data-entity-uuid="263229c1-f780-4d65-a09e-9c401342caa6" data-entity-substitution="media">test</a>

If data-entity-substitution="canonical", it will render /media/XXX, but if data-entity-substitution="media" it will render the direct link.

Documentation about this is at https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →

@ruslan, let me know if that doesn't answer your question correctly.

The problem is that when you append the fragment to the path, LinkIt will no longer return the data-entity-type and data-entity-uuid attribues for the

Testing this today with the 7.x branch, it appears that the data-entity-type and data-entity-uuid attributes are preserved just fine when an anchor/fragment is present:

Is there another scenario where this is still problematic?

I believe this issue is caused by the steps taken during data entry. As described in ✨ Add better support for linking to anchors Postponed: needs info and ✨ Add a basic matcher for anchors RTBC , using anchor links is definitely possible, provided you enter them in the format described there.

I'm going to revisit both of those issues to see if we can make the anchor links work more intuitively. Closing this issue as a duplicate.

Thanks, all! I've merged this and cut a new release, 7.x-3.8 →

I believe it is necessary to save the URL alias directly in the database instead of canonical URL.

Doing this would have problematic impacts. What happens when the URL alias is updated on the referenced node? If there is no redirect in place, the referencing link would become broken.

As further rationale that the canonical URL should be stored, Drupal core always stores the canonical URL in its database tables, as does the widely-used pathauto → module.

Re-reading this issue description, I conclude that it is not describing a bug in the module, but rather, it is a feature request that can be described as the following User Story:

As a content editor, when I use the link autocomplete functionality, I want to see the URL alias in the editing interface rather than the canonical URL so that it is easier for me to see what the link pertains to.

Note that this user story is distinct from rendering the URL alias to the site visitor on page render, which this module already does.

As such, this is not a bug report, but a feature request and is in effect a duplicate of ✨ Show URL alias after autocomplete selection instead of internal route (e.g., /node/123) Needs work .

Therefore, I'm going to mark this issue as a duplicate. If this analysis/conclusion is missing something, please explain!

Thanks for confirming this! Marking this issue as "works as designed"!

This is a very sensible change! Thanks for reporting and providing the nice implementation!

mark_fullmer → made their first commit to this issue’s fork.

We provided a new release of the 2.x branch, 2.0.1, that fixes the underlying problem with JavaScript. Can someone who is experiencing the issue with the use-ajax class report back whether https://www.drupal.org/project/responsive_tables_filter/releases/2.0.1 → resolves the issue for them? Thanks much!

Our team determined that the problem here stems from the switch from the jQuery version of Tablesaw to Shoestring, which happened as part of the transition in the 2.x branch to move away from jQuery. The Shoestring library, which functions as a kind of replacement for Tablesaw, appears to have some problems with global scoping that interfere with other JS. See https://github.com/filamentgroup/shoestring/pull/146

Reverting to using jQuery resolves the issue.

The merge request above:
1. Reverts to using the jQuery version of the Tablesaw library.
2. Replaces deprecated calls to push() and sort() with supported syntax per https://blog.jquery.com/2024/02/06/jquery-4-0-0-beta/
3. Moves a couple accessibility customizations out of the library into their own JS file so that it's clear what has been modified about the original library.

Thanks for reporting this. The proposed patch includes a hardcoded reference to the basic_html text format, which is not necessarily going to be present on sites. So I think, if this is a problem, it needs to be done in a more generic way.

Toward that end, could you provide steps to reproduce this as a problem? There is already schema definitions for include_unpublished on nodes, at https://git.drupalcode.org/project/linkit/-/blob/6.1.x/config/schema/lin...

We need to know where in the process this absent schema is causing problems (such as in the the attempt to save configuration changes to a text format. However, based on the design of the module, I don't think that would be a problem, since the only reference on a text format to Linkit is going to be the Linkit profile, not things like whether or not to include unpublished entities.

Luke.Leber → credited mark_fullmer → .

Thanks for using this module, and for asking about the url_prefix schema.

This has been addressed in the 3.x branch of the module, which is intended to be the target branch for Drupal 10.1 and above (including Drupal 11). Sites installed using Drupal 10.1 or above should use the 3.x branch.

Sites installed using Drupal 10.0 or lower can still use the 2.x branch without issue.

My assumption, then, would be that you are testing with the 2.x branch using a version of Drupal that is 10.1 or above.

If you do an installation of the 3.x branch, you should not get this issue.

I've created two merge requests that apply only the change required, that of removing $end->add(new \DateInterval('P1D'));.

• For 1.2.x: 3456833-allday-fix
• For 1.1.x: 3456833-allday-fix-1.1.x

Update: I was able to get this working with drupal/core-dev 10.3 by adding "w3c":false and changing chromeOptions to goog:chromeOptions. See https://git.drupalcode.org/project/drupal/-/commit/ec1aa07ac86f7d6f84bf7...

Further narrowing the root cause, it appears that the resulting change is due to switching from behat & instaclick to lullabot:

## Works
- instaclick/php-webdriver (1.4.19)
- behat/mink-selenium2-driver (v1.7.0)

## Breaks
lullabot/php-webdriver (v2.0.5)
lullabot/mink-selenium2-driver (v1.7.3)

This led me to https://www.drupal.org/project/drupal/issues/3458751 🐛 Drupal 10.3.x regression running JS tests using ddev - update lullabot/php-webdriver Fixed , which seems related, but simply updating to core-dev 10.3.x-dev does not resolve the issue. The immediate workaround is to stay on drupal/core-dev ~10.2.0

Based on the comment in #8, I think this issue should be transferred to the Drupal core issue queue, as this is reproducible outside of the Honeypot module.

suspect this has something to do with one of the core dependencies that was changed between these minor point releases of core.
WebDriver, for example, changed major versions, from version 1.4.19 in Drupal 10.2 to 2.0.4 in Drupal 10.3.
But there were a lot of other dependency changes too, so I'm not sure.

I can confirm that changes between the drupal/core-dev library are responsible for this.

On my setup, all FunctionalJavascript tests fail with the error reported here on drupal/core-dev 10.3.1.

Downgrading drupal/core-dev (10.3.1 => 10.1.8) resolves the issue.

There is this change record associated with Drupal 10.3, but for me at least, simply updating the indicated syntax does not fix the issue: https://www.drupal.org/node/3422624 →

The merge request updates the logic to check if the Menu Block contrib module is active on the site. If so, it suppresses the (duplicative) core menus from the list. This is ready for review!

+1! How can this show the option to use "Administration (Seven)" when it's not even installed on my site?!
And shouldn't the default theme be the default drupal core admin theme, ie. Claro?

Also, why do we need to provide custom CSS when in core we already have everything styled & coherent?

For all the reasons stated here, this is why the module Layout Builder iFrame Modal is preferable! See https://www.drupal.org/project/layout_builder_modal/issues/3163024#comme... ✨ Provide theme support for Claro Needs work

If there is a reason why you can't switch to that module, please explain!

Confirming that this problem can be reproduced on any form where (a) a table is rendered when (b) this module's global setting for adding this to administrative Views is enabled. An immediate workaround for someone having this problem is to disable that setting.

Now to the root cause...

Re-opening this issue. The duplicates are resolved in the Settings tray on an individual entity using Layout Builder, but the Layout Builder Restrictions list still duplicates them.

bbrala → credited mark_fullmer → .

I don't see any posts other than the initial issue description.

Ah, my mistake then! I think I was confusing it with another issue I am following that is similar -- 🐛 Linkit field doesn't work in nested Paragraph when Auto populate link text is enabled Active .

The problem is that while the 2.x branch fixes this issue, it introduces a new one: https://www.drupal.org/project/responsive_tables_filter/issues/3460761 🐛 Module causes javascript problems in edit form Active .

Looks like that issue now includes a proposed code change that would resolve the issue. It would be wonderful if someone who is using this somewhat specialized setup (i.e., using this in conjunction with the Paragraphs module) could test that fix and report back. If that fix works, then people can still switch to the 2.x branch, rather than having to revert to the 8.x-1.19.

Thanks in advance for your help in moving this forward!

Release 8.x-1.19 is now tagged: https://www.drupal.org/project/responsive_tables_filter/releases/8.x-1.19 →

It includes the schema change present in the 8.x-1.x branch that resolves this issue.

So I had to revert to the 8.x-1.x branch, which does not include this fix.

The 8.x-1.x branch does include this fix. See https://git.drupalcode.org/project/responsive_tables_filter/-/blob/8.x-1...

As I said previously ( https://www.drupal.org/project/responsive_tables_filter/issues/3460918#c... 🐛 'tablesaw_type' is not a supported key. 'tablesaw_persist' is not a supported key. Needs work ), there is not yet a release for the 8.x-1.x version that includes the fix. I will work on that.

The fix for this was committed to both the 8.x-1.x branch and 2.x branches. See https://git.drupalcode.org/project/responsive_tables_filter/-/commit/eaf...

A release for 2.x is available that includes this change. 8.x-1.x does not yet have a release that includes this fix.

If the goal is simply to alter the content editorial display, and you are okay with storing a full datetime value (which itself can be set to display only as the year via the field configuration), a form alter will do the job:

function MYMODULE_general_form_alter(&$form, &$form_state, $form_id) {
  if ($form_id !== 'MYFORM') {
    return;
  }
  $form['MYFIELD']['widget'][0]['value']['#date_part_order'] = ['year'];
}

Thanks for asking about this! A bit of research confirms my impression that a direct hyperlink to an ICS file is not commonly supported. Rather, the prevailing way to share ICS files via email is to attach them to the email.

For example, both https://support.microsoft.com/en-us/office/create-an-add-to-calendar-lin... and https://answers.laserfiche.com/questions/119723/How-do-I-attach-a-direct... suggest exporting the file and then either attaching it to the email or storing the file in a cloud service like Google Drive and linking to that.

That being said, I think it's certainly theoretically possible that this module _could_ provide the equivalent of a direct link to the ICS file. In order to support this, the business logic would need to be changed so that the hyperlink presented to users is not the data of the ICS itself, but rather, a relative link to a new Drupal Controller route, such as /events/ical/[UUID of event].

As a maintainer, I'm not opposed to changing the business logic along the lines outlined above, but I'd like to get more confirmation from other maintainers and the community that this seems like a valuable and standards-compliant thing to do.

I tested the isolated removal of $end->add(new \DateInterval('P1D')); discussed in #5 and #6 and looked at the output in both iCal and Outlook formats.

With this change, the end date resulted in changing from the following day to the same day. Importing this into MS Outlook successfully fixed the issue: the event that previously spanned two days now was listed as occurring only on one day:

Before

• DTSTART:20240705T050000Z: "Fri, 05 Jul 2024 05:00:00 +0000 (GMT)"
• DTEND:20240707T045900Z: "Sun, 07 Jul 2024 04:59:00 +0000 (GMT)"

After removing $end->add(new \DateInterval('P1D'));

• DTSTART:20240705T050000Z: "Fri, 05 Jul 2024 05:00:00 +0000 (GMT)"
• DTEND:20240706T045900Z: "Sat, 06 Jul 2024 04:59:00 +0000 (GMT)"

As can be noted from the data above, this uses the GMT timezone as its baseline time, so the above values (5:00am), when imported into a calendar that expects a 7-hour offset (CST), correctly results in the event that is occurring in the CST timezone to be displayed in the calendar as occurring on Friday, July 05, from 00:00am to 11:59pm (i.e., "All day").

I also tested how this change would affect the Google Calendar link. It *does* result in a change, but apparently not one that has an effect on Google's output:

• Current output: https://calendar.google.com/calendar/u/0/r/eventedit?ctz=America/Chicago... --> Renders as "July 5 to July 5"
• Output with removal of P1D line: https://calendar.google.com/calendar/u/0/r/eventedit?ctz=America/Chicago... --> Renders as "July 5 to July 5"
• Output when the end date is changed to one day in the future (i.e., event spans two days): https://calendar.google.com/calendar/u/0/r/eventedit?ctz=America/Chicago... --> Renders as "July 5 to July 6"

Based on the above, it appears that we simply don't need $end->add(new \DateInterval('P1D')); , and from a standpoint of parsing the code logic itself, it also appears that the 1-day offset added there should not be needed, since the end date as provided by the data stored in the field should already be set to 23 hours and 59 minutes after the start date. I haven't looked into whether this underlying data storage changed since the code was added 3 years ago, but I don't see an scenario, at least when using the smart_date field type, where the code is relevant at this point in time.

I've attached a patch that represents what changes would need to be included in the merge request to make the functional change and to update test expectations.

Thanks for asking about this. This functionality is already available in the Drupal contrib module "Editor Advanced Link": https://www.drupal.org/project/editor_advanced_link →

Linkit and Editor Advanced Link can be used in conjunction.

Therefore there is no need to duplicate the functionality in Linkit.

I can also confirm that using symfony/frameworkbundler version 6.4.9 avoids the problem introduced in 6.4.8.

I also observed an error, as reported in #22, the first time attempting to sign in, which stopped happening on subsequent attempts. I'm not convicnce that it is "SimpleSAMLphp caching the error page," though, as stated in #22. However, I'm unable to reproduce, so I'm not going to be able to provide the error message.

Important note about Symfony releases: Symfony does not release minor version releases for all of its components at the same time, and there are a number of components that do not yet have a 6.4.9 release. Therefore, the Composer syntax I'm using is to specify the requirement is to require 6.4.9 or higher on ONLY the symfony/frameworkbundle component:

    "symfony/framework-bundle":"^6.4.9"

As a result, I get the latest stable release for all symfony components, some of which are still at 6.4.8, instead of getting development branches of components that do not have a 6.4.9 release, which would happen if I specified ^6.4.9 for all components listed in #2, above.

Because of this, I plan to postpone the update until all of the Symfony components have a 6.4.9 release.

Looks like this is technically available in Drupal 10.2.x (https://github.com/drupal/drupal/blob/10.2.x/core/core.services.yml), which is what I'd used to test 🐛 RuntimeException: media_library.opener.form_element must be an instance of Drupal\media_library\MediaLibraryOpenerInterface Fixed .

But it is not present in the `core.services.yml` file for 10.1.x.

I guess it would still be better to set the compatibility to ^10.3, since it (a) we don't want people using earlier versions of Drupal 10.2 to use this version of Media Library Form Element and (b) it is only in 10.3 that the autoconfigure key *must* be present to avoid 🐛 RuntimeException: media_library.opener.form_element must be an instance of Drupal\media_library\MediaLibraryOpenerInterface Fixed

Although the original report references the comment module, this is not specific to that module. See an issue posted a few years ago: https://www.drupal.org/project/drupal/issues/3176461 🐛 The "extra_field_block:node:recipe:content_moderation_control" was not found Needs work that describes the same general problem.

I can report that this kind of warning is not present on a site install in a codebase running 10.2.7, but the warnings do show up with the same codebase on 10.3.0. The site is question includes an installation profile with configuration bundles. I'm going to explore declaring dependencies to fix the order of operations as described in https://www.drupal.org/project/drupal/issues/3176461#comment-14423398 🐛 The "extra_field_block:node:recipe:content_moderation_control" was not found Needs work

Clarification: based on testing, the change introduced here does not introduce BC problems with prior versions of Drupal core. Rather, this change is required for compatibility with Drupal 10.3 and above.

Therefore, I think we just need to cut a new release -- no change to the core_version_requirement.

Assigning to myself for review with MS Outlook...

Re-opening, since as implied by the original description, this has backwards compatibility consequences: previous versions of media_library_form_element will not work with Drupal core 10.3 or above.

Given this, we should probably change the core_version_requirement to >=10.3 in the 2.x branch and cut a new release sooner rather than later, so that this doesn't prevent sites from updating to Drupal 10.3

I am a maintainer, but do not have permission to create new releases, so another of the maintainers will need to be involved.

Increasing the priority to "Major."

Yep, this does indeed need to be done per https://www.drupal.org/node/3201242 → . Thanks for the merge request!

mark_fullmer → made their first commit to this issue’s fork.

Agreed. This looks good! Merging to the 2.x branch.

Thanks for explaining your perspective on this issue. I've created a request for new maintainership at #3457638: Seeking New Maintainer for media_library_theme_reset → . If you're interested, please follow the instructions there!

mark_fullmer → created an issue.

Hello! The 7.x branch provides compatibility for Drupal >10.1 and Drupal 11:

https://www.drupal.org/project/linkit/releases/7.0.0-alpha1 →

Thanks for the bug report and the proposed change! Assigning myself for review...

mark_fullmer → created an issue.

This issue was resolved in the Menu Blocks module!

🐛 Suppress display of regular system menu blocks in Layout Builder RTBC

Closing as "works as designed"

The most recent version of 3.x shows no coding syntax issues reported by PHPCS: https://git.drupalcode.org/project/layout_builder_restrictions/-/pipelin...

Closing this issue as outdated. Thanks for the help, regardless, everyone!

mark_fullmer → changed the visibility of the branch 7.x to hidden.

mark_fullmer → changed the visibility of the branch 3447669-no-longer-a to active.

mark_fullmer → changed the visibility of the branch 3447669-no-longer-a to hidden.

Thanks for the bug report. Based on what is described in 🐛 No longer a way to post a link as-is if there is 1 pattern match Active , I am concluding that this feature request was not a good idea to start with, since users don't always want to accept a suggestion provided by Linkit, even if there is only one suggestion. I'll work to back out the change in the 6.1.x and 7.x branches.

Based on statements in #13 and #14, it seems we have a strong sense that new major version releases of contributed modules create significant work on the part of individual site maintainers. As a consequence, we should set forth a guideline that recommends creating new major versions of contribs module ONLY in situations where the module introduces changes that require configuration or code changes in the site using that module.

Under this principle, a module release that simply drops support for an UNSUPPORTED version of Drupal core should NOT trigger a major version increment.

A revised version of the proposed guidelines follows, along with an interdiff of what would change.

Major versions

1. Drop a supported major version of Drupal core and all backward compatibility layers
2. Breaking changes from Symfony or other dependency that cannot have backward compatibility support (such as adding types to method signatures.)
3. Impossible dependency resolution (such as supporting Guzzle 6 and 7 at the same time.)

Minor versions

1. Add support for a new major version of Drupal core while dropping a minor version of Drupal core, or unsupported previous versions of Drupal core.
2. Add major new features and want to provide a minor version out of caution for users

Patch versions

1. Add support for new Drupal core major version, with backward compatibility
2. Other bug fixes
3. Small features

The 8.x-3.x branch will not provide Drupal 11 compatibility. Closing.

Thanks for reporting this! The latest stable version of this module did switch the Tablesaw implementation from jQuery to Javascript, so that may be the root cause of this regression.

If someone could provide a more complete set of steps to reproduce, with sample code, that would help the community remediate this. Thanks!

Note the result of this change as described in 💬 What is ?facets_query= in the URL? and how to remove? Active . Should that be addressed, or should we consider this works as designed?

Okay, great! I think this now should be set to merge into the 3.x branch, rather than 8.x-1.x. I've changed that on the merge request. Can you resolve the merge conflict?

Update links to latest Drupal code

I believe the code change responsible for this is shown at https://github.com/symfony/framework-bundle/compare/v6.4.8...6.4

I can confirm that our team experiences this error, too, with Drupal 10.2.6 (which has a requirement on symfony ^6.4, which will result in retrieving symfony libraries version 6.4.8.

A short-term site-specific workaround is to declare a conflict as shown below:

  "conflict": {
    "symfony/yaml":"6.4.8",
    "symfony/validator":"6.4.8",
    "symfony/string":"6.4.8",
    "symfony/serializer":"6.4.8",
    "symfony/psr-http-message-bridge":"6.4.8",
    "symfony/process":"6.4.8",
    "symfony/mime":"6.4.8",
    "symfony/mailer":"6.4.8",
    "symfony/intl":"6.4.8",
    "symfony/http-kernel":"6.4.8",
    "symfony/http-foundation":"6.4.8",
    "symfony/error-handler":"6.4.8",
    "symfony/dependency-injection":"6.4.8",
    "symfony/console":"6.4.8",
    "symfony/config":"6.4.8",
    "symfony/cache":"6.4.8",
    "symfony/var-exporter":"6.4.8",
    "symfony/var-dumper":"6.4.8",
    "symfony/routing":"6.4.8",
    "symfony/framework-bundle":"6.4.8",
    "symfony/finder":"6.4.8",
    "symfony/filesystem":"6.4.8",
    "symfony/event-dispatcher":"6.4.8"
  },
<code>

However, the longer term fix is going to be in the <code>simplesamlphp

library itself. In other words, based on the stacktrace this doesn't appear to be coming from the Drupal module simplesamlphp_auth