🇺🇸United States @mark_fullmer

See potentially duplicative issue 🐛 Cannot remove media on field, when there is a custom validation error Active .

Seems like this is a duplicate of the more generalized 🐛 Media library remove button triggers field constraint validation Active ?

This change makes sense. Thanks for looking into it and figuring out the parameter differences between <10.2 and above!

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

Good catch. This should definitely be addressed. It looks like the MR is triggering a failure in the tests, right now, with Failed asserting that '' contains "<a href hreflang data-entity-substitution data-entity-type data-entity-uuid title>". -- we'll need to look into that.

Logo added! Marking as fixed!

Logo added to the codebase! Marking as fixed!

Logo updated to "Google PSE" and merged into the development branch. Thanks everyone!

I don't think this needs to be marked as critical, since these packages are not part of the distributed Drupal module; they are internal build tools only. Setting priority to "Normal."

Yes, this all looks good. Thanks! Merging into 7.x

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

May be we can do something similar for ableplayer?

So, effectively, a shim for backwards compatibility. This seems reasonable to me. If I have a chance, I'll work on an audit of the deprecated functions and add shims for each. But first, we should search to see if someone has provided a comprehensive set of jQuery 3 shims for use with jQuery 4....

Thanks so much!

Both url_embed and embed do not have D11 releases

URL Embed does have a D11-compatible release -- https://www.drupal.org/project/url_embed/releases/3.0.0-beta2 → -- but you're right that since it declares a dependency on drupal/embed, you can't use it with a D11 site.

Thanks for contacting us about this. Speaking for myself as one of the two maintainers of this module...

1) Are you OK with me porting it to Backdrop CMS, or would you prefer to do the conversion yourself?

I'm fine with you taking the lead in the porting. If you would like any input/assistance, feel free to reach out.

2) After the Module has been converted to Backdrop CMS are you interested in us being Co-Maintainers?

I'm happy to be designated as a co-maintainer, with the understanding that I would be able to contribute only things like maintenance tasks, rather than working on feature requests.

Maybe this is a misunderstanding on my part, but I was thinking that this would allow modifying the oembed response.

Would this alter hook achieve what you wanted if $url was also pass-by-reference, as in:

$this->moduleHandler->invokeAll('url_embed_options_alter', [&$url, &$config]);

Also I see there's more than technical and support ContactType, but I'm not going to second guess your implicit assertion that (only) these are the best to implement.

1. Actually, I don't think I have the depth of experience with the API to assert this, so I think it's best to include configuration options for all 5 available contact types. Done in the latest code changes!

In the theoretical chance that we make this extensible (which should not be that much work, with configuration translation) it fits Drupal better.

2. Maybe the best (most Drupally) thing to do is make this configurable? That's been done in the latest changes.

3. Yes, there was some test code in there that I've removed. Thanks for catching that!

4. Test coverage added, and tests are passed on previous major, current major, and next minor.

Ready for further review!

Yes, thanks, I've done this on other projects for the same reason. Committing & cutting a new patch-level release.

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

For our purpose, being able to disable the validUntil attribute entirely would be the best, then there are no synchronization issues at all.

Note that as of May 2024, per https://github.com/SAML-Toolkits/php-saml/pull/569 , php-saml now includes a parameter to exclude validUntil.

The merge request proposes to change the logic to "If a module already has a core_version_requirement set, don't try to change it."

It would be maybe just nice if once the .info.yml file was written initially, if it didn't attempt to update that line afterwards, or only if it matches the previous value that was set by the module.

Agreed. I think this is the correct business logic. The current logic is problematic when, say, a Features module has been made compatible for the next major version of Drupal while the site is still running on a previous version. Another simple way of stating the proposed business logic change is "If a module already has a core_version_requirement set, don't try to change it." This would be different than this issue title's stated goal of allowing configuration, but would also avoid the stated B/C breaking consideration.

Ah, thanks for connecting the dots in comment #4! Yes, the 7.x version of this module drops support for CKEditor 4, and the code triggering this problem is for the CKEditor 4 integration, so it can be removed in the 7.x branch. Sites that are *only* using CKEditor 5 presumably would not have this error, just sites that still have CKEditor 4 enabled somewhere.

Committed, and a release is forthcoming!

Given that the SAML spec only supports specific contactPerson and organization attributes, and that the php-saml library further only supports certain values within those attributes (see https://github.com/SAML-Toolkits/php-saml?tab=readme-ov-file#saml-php-to... ) -- in other words, there's no reason to support *arbitrary* values being passed into the metadata, I propose that we provide a UI for entering technical contact, support contact, and organization information.

MR created.

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

Thanks for the report. Given the seemingly simple steps to reproduce, and the fact that this hasn't been an issue for other sites, I'm wondering if there's something specific to your site's configuration that is involved. Would you be able to test this in a generic Drupal 10.3.10 context (e.g., site install with the "standard" profile, no additional modules installed), and see if you can reproduce it in that context? Thanks!

1. I performed a static analysis of this module and no Drupal 11.x or PHP 8.3 deprecations were reported.
1. I performed a functional test of this branch using the latest version of Drupal 11 and was successfully able to add form fields to a view and edit them in bulk.

Based on the above, marking as RTBC!

mark_fullmer → changed the visibility of the branch 3487407-drupal-11-compatibility to hidden.

Can the maintainers provide a timeline for when this compatibility will be provided in a new release? Thanks for all the work you do!

Thank you. Committed. 🍻

Thanks, but I'm not seeing this committed to the 2.x branch, or a 2.0.1 release issued: https://git.drupalcode.org/project/paragraphs_features/-/tree/2.x?ref_ty...

Setting back to RTBC. If I'm mistaken, please forgive!

At this point, I have no plans to merge this change.

Thanks for the clarification on the thinking, @berdir. In that case, I think it might be sensible to more clearly label this issue as something that will not be merged, and leave it going for people who want to patch the module, and direct folks to 📌 Document that URL redirects work from node/{nid} but not alias Needs work to complete that work. Also, based on the progress on that issue, it could probably be renamed to something like "Check for path aliases and guide users to use internal path"?

Would the maintainers be able to provide a sense of when a D11-compatible release will be provided? Thanks for all the work you do!

Note, on this module's project page, that the most appropriate course of action for sites on D11 would be to stop using this module.

1. Noting that the error in #178 only occurs in conjunction with the in-progress enhancement 🐛 Redirects from aliased paths aren't triggered Needs review , it seems that accommodating that should be done as part of that enhancement, rather than this scope.
2. I'm unable to reproduce the problem described in #177. More information (steps to reproduce) would be needed.
3. The latest comment on the MR is addressed.

Based on the above, my own functional testing, and the passing automated tests, I'm setting this back to RTBC.

There are no blockers to providing a stable release. I've done so: https://www.drupal.org/project/linkit/releases/7.0.0 →

Thanks!

Credit added, kul.pratap!

It appears this was already fixed in 📌 Fix phpcs code-standard violations Fixed . Thanks, nevertheless!

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

Google CSE is now Google PSE (Programmable Search Engine). We can't change the module machine name, but the logo should reflect the new name.

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

Thanks, everyone!

Thanks for the work for D11 compatibility, everyone! Since this only drops support for Drupal 8, which is unsupported, it would be wonderful to see even a 4.0.0-alpha6 release of this module that includes this change. Thanks!

Looks good! Thanks for the contribution!

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

I tested this on the 3.x branch and was unable to reproduce, using both a private YouTube video and a video that no longer exists. The report in #3 shows the expected line in embed/embed for version 4 of that library (which is the version that should be used), so I assume this *can* be reproduced with 3.0.0-beta1 of url_embed and v4.4.14 of embed/embed. Can someone provide more specific steps to reproduce?

I did that it only shows up as a link if I paste it in and then click preview.

Hrm. Well, that's not the result I'm getting. Have you been testing this in a "pristine" environment (e.g., Drupal core standard installation, with only url_embed enabled)? In other words, I'm wondering if another text format filter you're using is interfering?

If you have been testing in a "pristine" environment, can you indicate specifically where in the instructions at https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → the problem occurs?

Thanks for the merge! Speaking for the community, it would be wonderful for a tagged release (3.2.1?) to be issued so that sites running on Drupal 11 can use this module in a predictable way.

Thanks so much!

1. I did another static analysis of the 3.0.x branch and it did not report any PHP or Drupal deprecations.
2. I installed the 3.0.x branch with the latest version of Drupal 11, both the main module and the media submodule, and confirmed that I was able to add and render a field to a node successfully, and add a new media item with the video_embed_field media plugin.

A 3.x release would be wonderful, if even marked as an alpha release.

Given that the CKEditor (4) integration has been removed in this branch, I think the module project page should also be updated to indicate that the 3.x branch does not provide *any* WYSIWYG integration (as I don't see any CKEditor 5 implementation).

1. I performed a static analysis of the code and found no PHP or Drupal deprecations.
2. I installed the latest version of Drupal 11 and used this merge request to functionally test the User Field Value module with Views, assigning a plaintext field on a node to use the "User Field Value" contextual filter related to a field on the User entity. This works as expected.

Marking as RTBC. It would be wonderful to have a Drupal 11-compatible release of this module!

Thanks for reporting this, @penyaskito. We do have test coverage for integration with the Dashboards module (see DashboardsIntegrationTest.php), and I just tested this using the latest version of Drupal 10 with Dashboards 2.1.7, and was able to successfully add blocks to a Dashboard, so I'm probably doing different steps than you provided. Here's my annotated version of the steps to reproduce, as originally stated.

1. Enable layout_builder_restrictions and configure for view modes. Enabled. On /admin/config/content/layout-builder-restrictions , the "Entity View Mode" plugin is enabled.
2. Install dashboard module (thas provides a section storage). installed. On /admin/config/content/layout-builder-restrictions, now the "Dashboards View Mode" plugin is enabled (automatically).
3. Try to add a block to a dashboard, it will fail. On /admin/structure/dashboards/add , I create a new dashboard, and use the Block restrictions to suppress Views blocks. I save. I click "Personalize". I see the Layout Builder interface. I successfully add a Section. I try to add a Block. I see that there are no Views blocks listed. I successfully add the Dashboard-provided "Add content" block.

Have I misunderstood something? If d10 will get security support past 11/25, then I don't think nearly as many people will have a problem waiting until then to upgrade to d11.

That's my understanding, too. Our team is looking at likely delaying our update to Drupal 11 for the single reason of the simplesamlphp incompatibility with Symfony 7.

The timeline for a fixed-point release is entirely up to the community. There has been no community participation for years, so I work on this when I can and when I need it personally.

Thanks, so much, for your ongoing contributions to this module & the Drupal community! Based on the creation of this issue titled "Plan for Drupal 11 release," the activity by joseph.olstad, and speaking for my team, the community is requesting a fixed-point release.

I advocate for proceeding with the release as soon as possible, given the following:
- Drupal 11 core has been released for six months now
- Typically, sites do not and should not use development branches (8.x-1.x) in production, so a release gives indication to the community that the module'scode can be used in production.
- This module is used by 20,000+ sites running on Drupal 8/9/10

As for community participation, we could certainly pursue the paths described at https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... → for encouraging community support of mimemail.

Closing as a duplicate of 📌 Automated Drupal 11 compatibility fixes for gtranslate Needs review , which also targets the 3.0.x branch, and has been reviewed functionally and using static code analysis.

1. I performed a static analysis of the code for PHP deprecations and Drupal core deprecated code. No errors were reported.
1. I functionally tested this module using the latest version of Drupal 11 -- everything worked as expected.

It looks like the only thing necessary for providing Drupal 11 compatibility is indeed to update the core_version_requirement, as staged by the updateBot.

It would be great for the maintainers to provide a narrow, 3.0.4 release that includes this change, given that Drupal 11 has been released for 6 months now.

For this to work, the order of the text format filters must have "Convert URLs to URL embeds" BEFORE "Display embedded URLs". I'll add a note about this on https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →

(As a basic explanation, the "Convert URLs to URL embeds" filter renders a <drupal-media> tag, which is then ready for conversion to the external media markup by the "Display embedded URLs" filter

Is it possible to get an Updated-Zipfile?

I think the best way to go about getting a "download" of this would be to use Git to clone the issue fork & branch (see the "Show commands" expandable near the top of this issue).

This fixes this long-running bug, and I agree with #78 that it is prudent to fix this in the contrib module rather than wait for core to fix the underlying issue. Marking as RTBC.

Thanks, Max! Yes, we use this at UT Austin. A representative implementation: https://cml.music.utexas.edu/about/video-essays-learning-music

I functionally tested this module in the context of Drupal 11 and can confirm that the basic functionality -- that of using AblePlayer's field formatter -- works as expected. As such, I'm marking this as RTBC.

Static analysis of the code did not turn up any Drupal 11 deprecations, per se, but there was missing schema definitions, and outdated implementations in the tests. I updated those where I could -- it's clear that one of the tests is a work-in-progress, so I let that be -- and now PHPUnit tests are passing on both Drupal 10 and Drupal 11.

Of note: the maintainers have set the minimum core version requirement to ^10.3 in the 3.x development branch. Based on my reading of the latest views in https://www.drupal.org/project/ideas/issues/3357742 🌱 Guidelines for semantic versioning and Drupal core support Needs review , this module can drop support for Drupal 9 in a minor version release, since Drupal 9 is no longer supported.

I therefore encourage the maintainers to release a 3.2.0 minor version release that provides Drupal 11 compatibility, given that Drupal 11 has been released for nearly six months now. Thank you!

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

I worked through a number of D11 compatibility issues and got this merge request to a point where I think the remaining problems have to do with dependencies:

1. Failing test bibcite_entity/tests/src/Kernel/EntityCitationRenderTest outputs

TypeError: htmlspecialchars(): Argument #1 ($string) must be of type string, array given

, which is potentially due to a problem in the dependency seboettg/citeproc-php. See https://github.com/seboettg/citeproc-php/issues/184
2. Additionally, it appears that some logic has changed in Drupal's denormalizer: bibcite_import is not importing data in the way it did in Drupal 10 at /admin/content/bibcite/reference/import, with Symfony\Component\Serializer\Exception\UnexpectedValueException: Could not determine entity type bundle: "type" field is missing. in Drupal\serialization\Normalizer\EntityNormalizer->extractBundleData() (line 115 of /core/modules/serialization/src/Normalizer/FieldableEntityNormalizerTrait.php).. This can be reproduced in the UI.

At this point, probably a maintainer needs to weigh in.

MR created!

To better establish that this is functionally compatible with Drupal 11, I added a generic .gitlab-ci.yml template to the existing merge request. Based on the output -- see https://git.drupalcode.org/issue/bibcite-3428258/-/jobs/3511898 -- there is still a significant amount of work to do here to make this D11 compatible.

Setting to "Needs work."

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

More information is needed:
- What version of the simpleSAMLphp library are you using, and what version of Twig is it declaring?
- What version of Drupal are you using, and what version of Twig is it declaring?
- What methodology are you using that accommodates these versions of Twig (i.e., are you using Composer to install, or are you downloading)?

Merge request created, demonstrating passing FunctionalJavascript tests on Drupal 10 and Drupal 11. Setting to "Needs review"!

Thanks for the work on Drupal 11 compatibility! Would it be possible to provide a new release of this module that includes D11 compatibility? Based on the commit history, no other commits have been made since the previous release, so a narrow, D11-compatibility release would seem to be quite straightforward.

The latest two commits address compatibility with PHPUnit 10 and PHP 8.2:

• Unit test dataProviders must be static methods, per https://www.drupal.org/project/drupal/issues/3353210 📌 [PHPUnit 10] @dataProvider methods must be declared static and public Fixed
• Creation of dynamic properties are deprecated, per https://www.php.net/manual/en/migration82.deprecated.php

PHPUnit tests are green for both Drupal 10 and Drupal 11. This is ready for a narrowly-scoped release, 8.x-3.16, which would include only this change and https://git.drupalcode.org/project/features/-/commit/d8bb8c1baa795b93b27... compared to 8.x-3.15.

Based on the analysis below and functional testing, this should be ready to merge and a new 8.x-1.7 release provided with Drupal 11 compatibility

Auditor checklist

[x] Deprecated Drupal code is remediated -- no deprecations found using Rector or Upgrade Status, or
[x] Deprecated PHP code is remediated -- change, noted below.
[x] Custom code is compatible with jQuery 4 -- none present
[x] Custom code core_version_requirement indicates Drupal 11 compatibility
[x] This module's composer.json file does not require any changes for Drupal 11 compatibility
[x] I updated the GitlabCI file to run Functional tests against both Drupal 10 and Drupal 11.
[x] Existing functional tests pass on Drupal 10 and Drupal 11

Drupal-Rector Audit of Drupal deprecations

1 file with changes
===================

1) web/modules/contrib/protected_pages/src/EventSubscriber/ProtectedPagesSubscriber.php:134

    ---------- begin diff ----------
@@ @@
   /**
    * {@inheritdoc}
    */
-  public static function getSubscribedEvents() {
+  public static function getSubscribedEvents(): array {
     $events[KernelEvents::RESPONSE][] = ['checkProtectedPage'];
     return $events;
   }
    ----------- end diff -----------

Applied rules:
 * ProtectedStaticModulesPropertyRector
 * AddReturnTypeDeclarationRector


 [OK] 1 file would have been changed (dry-run) by Rector                                                                

Audit of deprecated PHP <8.3 calls
If no errors are listed below, php-compatibility did not find any.

.......... 10 / 10 (100%)

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

The commits noted in #64 match the analysis & recommendation from #59. Code review looks good. This is RTBC and ready for a 2.0.0-beta1 release, which calls out the following:

• The 2.x major version release of XML Sitemap removes functions deprecated in 8.x-1.x four years ago. The functions were likely unused, but developers who have extended XML Sitemap should review #3156088: user_access() does not exist in Drupal 8 anymore → for confirmation.
• 2.x also drops support of Drupal 9 up to Drupal 10.2 (i.e., compatible with Drupal 10.3 and 11). Sites still using lower versions of Drupal core should continue to use 8.x-1.5.

1. I've updated the identified Drupal deprecations per https://www.drupal.org/node/3436275 → . Since the maintainer (vladimuraus) set the core_version_compatibility to 10.3 and above, it is acceptable to replace these, as this release will not need to accommodate versions of Drupal core prior to 10.3
2. Irefactored the jQuery to avoid .click and .change, which are removed from jQuery 4. I functionally tested in an environment using jQuery 4.

The automated tests throw a bunch of failures for either code syntax or Drupal 12 compatibility, but that seems out of the scope of this issue. Setting to "Needs Review."

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

Setting to "Active" to continue to receive deprecation code changes. The actual D11 compatibility effort is in 💬 Drupal 11 release Active .

I performed a static code analysis and confirm that no deprecated code for Drupal 11 or for PHP 8.3 was found. I also functionally tested this using Drupal 11 and found no problems. I've created a merge request, identical to the patch. Marking this as RTBC.

It would be wonderful to have a narrow 3.0.7 release that includes D11 compatibility, now that Drupal 11 has been out for months!

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