🇺🇸United States @mark_fullmer

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.

*If* there was interest in supporting smart date recurring dates, this is a proof of concept for how the correct delta values could be retrieved. It would simply require the View to be configured to include a "delta" field from the smartdate field, and the code here would use that from the row output to find the correct delta.

Not expecting this to be incorporated as-is, of course. Just sharing to provoke ideas & consideration.

I'm also interested in providing support for smart_date type fields through this module, and am happy to test this. However, based on my review of the code and functional testing of the above patch, it appears that the scope of this issue is to handle date spans in smart_date fields only. As far as I can tell, there is still the more fundamental issue of supporting repeating/recurring date instances. It seems that the maintainer has suggested this is not supportable per ✨ Smart Date Support? Closed: won't fix .

Can @lazzyvn confirm whether there is openness to supporting recurring smart_date fields?

Can the @kristiantosney revise the issue description and title to better define the scope of the intended change here?

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

Good call, @poker10. Here's my audit & analysis:

1. The cumulative code changes between the 2.x and 8.x-1.x branch can be seen at https://git.drupalcode.org/project/xmlsitemap/-/compare/2.x..8.x-1.x

• The change committed to 8.x-1.x not present in 2.x is https://git.drupalcode.org/project/xmlsitemap/-/commit/40727c92415802bb1... , which is innocuous enough and could simply be merged into 2.x without issue
• The changes committed to 2.x not present in 8.x-1.x consist of https://git.drupalcode.org/project/xmlsitemap/-/commit/1d59a51562d50b7d3... (see #3257944: PHP 8.1: XmlSitemapWriter::openUri($uri) should either be compatible with XMLWriter::openUri(string $uri): bool → ). This commit removes functions that were deprecated in 8.x-1.x and provides additional PHP 8.1 compatibility with return type hinting.

2. Of note, this MR removes the explicit PHP version constraints from the composer.json file and xmlsitemap.info.yml file that were added in https://git.drupalcode.org/project/xmlsitemap/-/commit/1d59a51562d50b7d3... . I believe this makes sense, since there is no longer a need to specify minimum PHP 8.1 compatibility in the module itself, since its constraint to Drupal 10/11 does the same thing. Conclusion: this change in the MR is fine.

3. I functionally tested this MR locally and can confirm that it works the same in our codebase as 8.x-1.5. While my testing certainly didn't comprehensively evaluate all of the options for XML sitemap, the code review above suggests that there should not be any functional or backwards-compatibility breaking change, and since the Drupal core compatibility is set at ^10.3 || ^11, which have a minimum PHP version requirement of 8.1, there is no risk of incompatibility with sites running on PHP 7.

4. Based on the above, the actions to take, I believe, are:

• (Optional, but probably a good idea) Merge 8.x-1.x into 2.x once more, which will simply add the logo.png file to 2.x and get the branch history up to date.
• Merge the Drupal 11 compatibility changes in this issue into 2.x and release 2.0.0-beta1. The release notes should call 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.

It might also be worth evaluating https://www.drupal.org/project/date_ical → as a solution. In my initial testing, this has seemed to work better with smart_date fields.

I don't remember all the details but basically there was an error in the console and the media wasn't attached. It started with updates to D10 for D9 the module worked just fine.

Hrm... our team uses Layout Builder iFrame Modal and has many components that involve media uploads, and haven't encountered any issues. Our setup could be different than yours, however. If it's not too much trouble to test again and see if you can reproduce, and then report any issues in the Layout Builder iFrame Modal queue, that would be awesome. If it is a generalized issue, fixing it in that module could be an easier solution than moving this issue for Layout Builder Modal forward.

As a maintainer, I agree that this suggestion makes a lot of sense. Perhaps the best thing to do is to move that warning to the URL Embed configuration section, instead of the generic site warnings.

There were some deprecation notices in running PHPUnit, as well as the new, super minor code syntax alpha-case ordering requirement ( https://www.drupal.org/node/3439320 → ). I typically would want to leave code syntax out of a Drupal 11 compatibility issue commit, but since this change was separate from the functional code itself, I went ahead and included that change. Tests now all pass, so marking as RTBC.

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

+1 for an official release!

Everything looks good for D11 compatibility, though I might point out that the vast majority of the code changes here relate to coding syntax, rather than D11 compatibility per se. Nice to see all the green checkmarks on the syntax tests, but I wouldn't want this to hold up a "skinny" D11 release, given that Drupal 11 core was released 5 months ago.

In any case, this is RTBC.

As a maintainer, I would note that if we change the default behavior not to show unpublished media, this would effectively change users' expectations on existing sites. A content editor used to seeing unpublished media items would no longer see them. Is that reasonable? I'm not necessarily saying that we should implement this as an "opt out" feature (i.e., an option to hide unpublished media entities), but if we do this, I think we need to call this out loudly in the release notes and documentation as a behavioral change.

This thinking might also suggest that the issue would better be characterized as an enhancment/feature, rather than a bug, since the module was originally created at a time when media entities _couldn't_ have a published state, and was not designed to suppress them.

Thanks for the further testing, @ruslan_piskarov. I think you're pointing out a specific issue with links wrapping media, which is described in the Linkit issue at 💬 Links surrounding Media Library item strips data-entity-type and data-entity-uuid Postponed , and has been traced back to core issue ✨ Drastically improve the linking experience in CKEditor 5 Needs work . If that sounds right to you, then I think this issue -- the direct media option -- is still "works as designed" and can remain closed without further work.

This works great functionally! I'm just seeing a series of errors when I run tests locally. The first, as shown in the previous major test pipeline in https://git.drupalcode.org/project/linkit/-/jobs/3267712, fails because the form element description is not visible:

1) Drupal\Tests\linkit\FunctionalJavascript\LinkEntityReferenceFieldTest::testLinkEntityReferenceWidget
Behat\Mink\Exception\ElementHtmlException: The string "Start typing to find content or paste a URL and click on the suggestion below." was not found in the HTML of the element matching css "#edit-field-test-er-wrapper".

I'm not sure that the description text "Start typing to find content or paste a URL and click on the suggestion below." is quite right for a generic entity reference field, and I think we could just leave the form element description blank and have the site builder supply appropriate help text. But even with removing that, the tests fail on subsequent checks, such as the following:

1) Drupal\Tests\linkit\FunctionalJavascript\LinkEntityReferenceFieldTest::testLinkEntityReferenceWidget
Behat\Mink\Exception\ElementNotFoundException: Element matching css "li.linkit-result-line .linkit-result-line--description" not found.

I replayed this code change on the 7.x branch, which provides Drupal 11 compatibility. Ideally, we merge to that (but can also merge to 6.1.x). Will need to return to this to understand why the tests are failing as described above. Setting to "Needs work."

This is resolved via release 6.1.6. Closing accordingly.

Assigning to myself for review...

Thanks! This looks great. I recently did the same change for another module.

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

Thanks for asking about this. Yes, for almost all sites, updating from Layout Builder Restrictions version 2 to version 3 should be as straightforward as simply updating the code. As indicated in the release notes of version 3.0.0 → , this version does not introduce any API changes or backward-compatibility-breaking changes. The only notable thing -- and the reason that we updated the version from 2 to 3, is that version 3 is no longer indicated as compatible with Drupal version 9.

Marking as RTBC, based on the comment above from the MR.