#Drupal 10 compatibility

It seems there is no updatebot issue for D11. Maybe this needs to be fixed first?

Noticed that the 2.x version is no longer supported and the issue has been resolved in version 3.x of the module. I'm marking this issue as outdated.

Please find screenshots after applying patch from MR3.

Using the \Drupal::service('renderer')->render($documentation) instead of render($documentation); function looks good as a quick fix, but it would be nice to replace it with a dependency injection and avoid calling \Drupal::service in class.

I think the dependency injection implementations should be moved to separate issue. I am marking this issue as RTBC for now.

2.x-dev is now available which is Drupal 10 ready. Should we close this ticket? https://www.drupal.org/project/views_dates/releases/2.x-dev →

@baldwinlouie

Thank you for your review. I’ll merge the patch to 7.x and release drupal/cloud:7.0.0-beta1; and close this issue as Fixed.

@yas, Thanks for the patch. It looks good to me.

@baldwinlouie

Can you please review the patch? Thanks!

I've done some work to fix up the tests, added an additional test for multilingual and content moderation together. I also think I've figured out a slightly better way of parsing the URL parameters when the access check is being run before the route object is available. I ended up refactoring some test case stuff into a trait to remove some of the duplication, hopefully that's OK.

Also while writing the tests, I found an additional issue where cache tags for the preview link entity weren't being added to the access result for the preview link route. This meant the page cache could potentially cache the preview page and not be invalidated when regenerating the access token.

It would be great to get a review on this MR now:

https://git.drupalcode.org/project/preview_link/-/merge_requests/27

Tests are failing with 10.x.

I think all the changes required are related to classy being removed.

the module support drupal 10 version.

HI @darvanen

I studied this issue and was able to reproduce it by adding two identical blocks to the LayoutBuilder Layout. The EventSubscriber that was added to implement the module logic functionality for LayoutBuilder does not guarantee the uniqueness of the ID for the blocks. I propose to add to the logic of our EventSubscriber to the ID of the block its weight without a lower dash as a separator to guarantee the uniqueness of the key for the cookie.
@see https://git.drupalcode.org/project/collapsiblock/-/merge_requests/19/dif...

change the code to the following $id = Html::getId('collapsiblock-wrapper-' . $build['#configuration']['id'] . $build["#weight"]);

The cookie will look like this: {%22who7%22:1%2C%22who8%22:0}

Let me know what you think of my idea and we can add it

Automatically closed - issue fixed for 2 weeks with no activity.

I don't know when we release full stable version because right now this module is out of my work scope, but it is nice that plenty of developers work on this module.

Key supports Drupal 10, so I'm closing this.

Wonderful, that's a big improvement, thanks @bobi-mel.

I think we still need to address #43 as we're adding an id to each block. Perhaps we could simply generate a uuid for each block?

Added patch for D10 compatibility.

Hi, any plans for a D10 release? I've tested the patch and it looks fine.

Automatically closed - issue fixed for 2 weeks with no activity.

So I've been testing this out with preview links using url based language-negotiation (so the preview links are generated with the language prefix).

This is the behaviour I can see with the current version of the module:

- If all translations are unpublished, preview link for the default language works, preview link for other unpublished translations return a 404.
- If the default language is published, with a draft translation, the preview link with a language prefix shows the published translation.
- If the default language is published and has a newer draft, and the translation is published with a newer draft, the preview link for the default language works correctly, and the preview link with a language prefix continues to show the published translation

I tried the core patch linked in #49 but it didn't appear to change the behaviour at all.

I then applied the changes from MR 27 and saw the following behaviour:

- If all translations are unpublished, preview link for the default language works, preview link for an additional draft translation displays correctly.
- If the default language is published, with a draft translation, the preview link with a language prefix shows the correct draft translation.

- If the default language is published and has a newer draft, and the translation is published with a newer draft, both preview links work correctly and show the correct drafts, and the language switcher block works correctly.

So the changes seem to work well in my local testing.

I'm not sure if there's a better way to grab out the URL parameters than directly parsing the path info in the new code, but I can see why it's required as the access check is being invoked as part of the parameter upconversion process so the route match isn't available yet.

Installed this branch on a Drupal 10 site this week. I did see some issues when trying to add fields to the ticket entity type, but not sure if it was because of the patch.

Automatically closed - issue fixed for 2 weeks with no activity.

Sending back to Needs review as we can’t trust Specbee reports. There is nothing in comment #12 that indicates anything other than what DrupalCi would have already tested.

Specbee (including this specific user) has been seen to not fully test issues and may just be attempting to gain credits for their D.O. partner rating.

More importantly, this module is basically un-maintained at the moment. If someone is going to want to see issues closed out they are going to need to consider stepping up and working on the rest of the queue to show their interest in maintaining the code.

Automatically closed - issue fixed for 2 weeks with no activity.

I second the official release...!

Thanks,
Eric

Any timeline for this getting released?

Thanks,
Eric

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

Thanks for the module, looks promising. I tested the issue, but unfortunately the MR didn't fix the issue with 10.3 + PHP 8.2. Still gets the same 400 error with message on log:
Drupal\Core\Http\Exception\CacheableBadRequestHttpException: Invalid nested filtering. The field `vid`, given in the path `vid.meta.drupal_internal__target_id`, does not exist. in Drupal\jsonapi\Context\FieldResolver->resolveInternalEntityQueryPath() (line 297 of /var/www/html/core/modules/jsonapi/src/Context/FieldResolver.php

@bushra-shaikh have you actually tested the functionality of this patch, or just checked the upgrade status report?

Whoo.

Yes we should make the remaining changes to the event dispatcher interface, but there's more than what's in the last patch. I created an MR with the ones I found. Let's ensure tests pass.

I applied patch #4 got below error:

error: patch failed: html5shiv.info.yml:2
error: html5shiv.info.yml: patch does not apply

I have reviewed and applied MR !3 this works for Drupal 9.5.11 and Drupal 10.0. and 10.0.1
Screenshots of the compatibility on 9.5.11 have been attached for reference:

can be moved to RTBC+1

Automatically closed - issue fixed for 2 weeks with no activity.

Another request for an official D10 release, please. Preferably a stable release covered by the Drupal Security Team. Right now a casual look on the module page can give the impression that there is only a 7.x version.

Is there a roadmap for such a release? Anything I can do to help?

Automatically closed - issue fixed for 2 weeks with no activity.

Automatically closed - issue fixed for 2 weeks with no activity.

Probably we want to merge and close 📌 Automated Drupal 10 compatibility fixes Needs work first, then rebase this MR onto that.

Leaving this ticket on Needs work until the testing pipeline gets unclogged from its current “Waiting for branch to pass” status.

Automatically closed - issue fixed for 2 weeks with no activity.

@maintainers

This patch has been working for quite a while now.

Would it be possible to have an official D10 release soon please?

Thank you.

Have tested #29 on Drupal 10.2.2 and can confirm that it seems to work.

Raised the following to co-maintain this module: https://www.drupal.org/project/basic_watermark/issues/3446822 💬 Offering to co-maintain basic_watermark Active

Ill keep an eye on this, and escalate after 2 weeks as per https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... → .

Automatically closed - issue fixed for 2 weeks with no activity.