🇨🇦Canada @alberto56

The failing tests seem to be due to another issue, 🐛 Automated tests seem to be failing on 8.x-7.x branch Active .

Here is a patch which tries to fix the definition of setup() vs setup() : void

alberto56 → created an issue.

Thanks, @mparker17, highly appreciated. The test are in effect failing. Specifically, in https://git.drupalcode.org/project/elasticsearch_connector/-/jobs/4435313 we are seeing:

PHP Fatal error: Declaration of Drupal\Tests\elasticsearch_connector\Kernel\ClusterSchemaTest::setUp() must be compatible with Drupal\KernelTests\KernelTestBase::setUp(): void in /builds/project/elasticsearch_connector/tests/src/Kernel/ClusterSchemaTest.php on line 30

I will therefore set this ticket to Needs work.

Here is a first stab at a patch.

alberto56 → created an issue.

Hi @james.williams thanks for your message. My website, which is a complex project that I have inherited, has

* node 123 in /language-one with the alias /this-is-an-alias
* a language /language-two, which has /language-one as a fallback
* node 123 does not have a translation in /language-two
* we want to see node 123 at /language-one/this-is-an-alias and also at /language-two/this-is-an-alias
* In Drupal 10.4, without any patch, or with patch at #158, /language-two/this-is-an-alias shows Page not found
* With the patch at 162, /language-two/this-is-an-alias shows the same content as /language-one/this-is-an-alias

I have tried to reproduce this behaviour on a brand new Drupal 10.4 site, but I could not. Therefore I assume that my website is doing something custom; and that the patch at 162 is for a very narrow usecase which cannot for the moment be reproduced on a new D10.4 site. If I manage to reproduce the problem on a brand new site, I will document it here; if not, please disregard the patch at 162.

Please ignore #161 and use this patch instead. It is identical to #69 except for one line which makes it compatible with Drupal 10.4

Hi all, I was using the patch at #69 with Drupal 10.1, and when I upgraded to Drupal 10.4, the patch at #69 no longer applies. I tried the patch at #158, which does apply to Drupal 10.4, but in my usecase does not fix the issue.

I am including herein a version of the patch at #69 which now applies to 10.4, in case it might be of use to anyone.

@florianmuellerch thanks,

I have tried to reproduce what you said in the issue description:

In this particular example, I'm having translatable nodes with a paragraph field on them. Each paragraph has a "published" flag which itself is translatable. The goal was if I have a translation of the node but don't want to show one of the paragraphs there, I could simply unpublish it and it won't get shown on the translation.

What actually happens is that another language of the same paragraph which itself is published (coming from another translation of the same node) is being shown.

I have installed a new Drupal 11.1.0 site and then did the following:

* drush site:install -y
* composer require drupal/paragraphs
* create a module mymodule which implements function mymodule_language_fallback_candidates_locale_lookup_alter(array &$candidates, array $context) { $candidates = []; }
* drush en -y paragraphs language content_translation mymodule
* /admin/config/regional/language/add
* Language nane: French
* Click "Add language"
* /admin/structure/types/manage/page
* In Language Settings, select "Enable translation"
* Save
* /admin/structure/paragraphs_type/add
* Label: test paragraph
* Save and manage fields
* Create a new field
* Select "Plain text" and continue
* Label: "Field inside paragraph"
* Selct "Text (plain)"
* Continue
* Save settings
* /fr/admin/structure/paragraphs_type/test_paragraph/form-display
* Put "Published" in the visible section and save
* /admin/structure/types/manage/page/fields/add-field
* Select "Paragraphs" and continue
* Label: Paragraph
* Check "Test paragraph"
* Save
* /admin/config/regional/content-language
* Check "Paragraphs"
* Unfold the Paragraphs section
* Check the "test paragraph" and its sub-fields, "Published" and "Authored on"
* Save configuration
* /node/add/page
* Title: "page in English"
* In "Field inside paragraph" write "Hello world"
* save
* /fr/node/1/translations/add/en/fr
* Title: "Page in French"
* In the paragraph, uncheck Published
* Save (this translation)
* visit /fr/node/1 in an incognito window
* confirm you see "Hello world" even though the paragraph is unpublished in the French translation
* curl -O https://www.drupal.org/files/issues/2022-11-10/3186034_10_respect_empty_... →
* patch -p1 < 3186034_10_respect_empty_translation_candidates.patch
* drush cr
* visit /fr/node/1 in an incognito window
* based on the issue description, I would expect *not* to see "Hello world", but I see it.

I will do some more tests but for now I cannot reproduce a scenario where my site acts differently with this patch than without it.

I have inherited a project which uses this patch, and I'm trying to figure out what this patch does exactly.

I have created a node in language fr and a translation in language fr-fr.

The node in fr has a paragraph test, which is published; and the paragraph is translated in fr-fr so that it's not published.

From reading this patch description, I would expect:

* That with the patch, the paragraph test does not appear in fr-fr
* That without the patch, the paragraph test appears in fr-fr even though it is unpublished in fr-fr (put published in fr).

However, whether or not I apply this patch, the paragraph does not appear in fr-fr.

In fact I cannot see any difference anywhere on my website whether I apply this patch or not.

If anyone can advise me on a step by step guide to reproducing a scenario where the site will act differently with and without this patch, when starting from a brand new Drupal site, that would be very appreciated!

Hi all, is there a plan to release a Drupal 11 version of this module? If not, would the maintainers be open to having a co-maintaner?

Something like the following code in your custom module might help if you're experiencing a fatal error because of this:

/**
 * Implements hook_devel_generate_info_alter()
 */
function MY_CUSTOM_MODULE_devel_generate_info_alter(array &$generators) {
  // https://www.drupal.org/project/webform/issues/3499830
  unset($generators['webform_submission']);
}

Related to 🐛 [Drupal 9.x] Declaration of Drupal\webform\Plugin\DevelGenerate\WebformSubmissionDevelGenerate::validateDrushParams($args) must be compatible with Drupal\devel_generate\DevelGenerateBaseInterface::validateDrushParams(array $args, array $options = Array) Fixed and ✨ Move DevelGenerate plugin to a new webform_devel_generate module within this project Active

Related to 🐛 Fatal error: Type of Drupal\webform\Plugin\DevelGenerate\WebformSubmissionDevelGenerate::$entityTypeManager must be Postponed: needs info and ✨ Move DevelGenerate plugin to a new webform_devel_generate module within this project Active

alberto56 → created an issue.

It turns out the project I am working on has 4 years of quite complex legacy code (CSS, SASS, JS), which targets hidden in a very specific way and which I cannot get to work with this change. I have found that by reverting the part of this patch which uses hidden="hidden" intead if aria-hidden="true", and by making it use aria-hidden instead of the hidden parameter, my legacy code works once again. If anyone is in the same situation as me, here is a patch which reverts only the part of this change which replaces aria-hidden with hidden.

I am not recommending you use this patch unless you are in that very specific situation.

alberto56 → created an issue.

Thanks @james.willams for the extra info! In fact my team was using the patch which is named "3110113--16--language-fallback.patch". Because there is a "16" in the name of the patch I assumed it was from comment 16. My apologies if it is not. (You can see it by clicking "Show 9 more files" under the patch 14 at the top of this issue.) The reason I re-rolled that one is because it has long been used by my team with previous versions of this module, without any obvious adverse effects. If anyone is in the same situation they can find my "19" patch by clicking "Show 9 more files" at the top of this issue.

Cheers.

When I upgraded from 5.0.0-rc1 to 5.0.0-rc2, my menu stopped working entirely and I traced it back to this issue.

I documented a fix at ✨ Add a note to the 5.0.0-rc2 release that css should be changed from sidr[aria-hidden=false] to sidr:not([hidden="hidden"]) Active in case anyone else has the same problem

alberto56 → created an issue.

Hi all, the patch at #16 does not apply anymore; I have updated it so that it now applies.

alberto56 → created an issue.

alberto56 → created an issue.

Closing, D11 version is now released.

Closing, D11 version is now released.

Closing, D11 version is now released.

Thanks! Committed, and I created a new release, 1.1.0.

alberto56 → created an issue.

@Murz thanks for posting this. I was going around in circles, and your post set me in the right direction. In my case as well, the triggering element seems wrong.

I would expect:

$form_state->getTriggeringElement()['#name'];

to be the same as:

$form_state->getUserInput()['_triggering_element_name'];

which it is in most cases, but in some cases the former gives me, for some reason, the first triggering element in the page whether or not that's the one I clicked.

$form_state->getUserInput()['_triggering_element_name'];

always seems right.

There is a lot of custom code in my site, so for now I cannot confirm that I'm not doing something which is causing this (although I cannot find anything).

For me, a smelly workaround is the best way forward for now. Thanks!

alberto56 → created an issue.

For anyone looking for a way to consistently reproduce this, and a workaround if you can't or prefer not to apply the patch:

```
drush si -y
cd modules/contrib
git clone https://git.drupalcode.org/project/linkit.git
cd linkit
git fetch -a
git checkout 7.x
drush en content_translation linkit
```

* /admin/config/regional/language
* Add Language: French
* /admin/structure/types/manage/page
* Languager settings: Enable translation
* /node/add/page
* Title: Page in English
* Save
* /node/1/translations
* French: Add
* Title: Page en français
* Save
* /admin/structure/types/manage/page/fields/add-field
* Label: Link, Type: Link
* Continue
* Save settings
* /node/1/edit
* Link: Url: /fr/node/1
* Link: Link Text: View this page in French
* Save

You will notice now that the link links to the English version of the site.

Here is a workaround:

* composer require drupal/redirect
* drush en redirect
* /admin/config/search/redirect/add
* source path: redirect/fr/node/1
* to: http://www.example.com/fr/node/1 (where http://www.example.com is the full base URL of your site)
* language: English
* /node/1/edit
* Link: Url: /redirect/fr/node/1

Hi, thanks for the great issue description. I came across your post while researching a similar issue for a client. Although I am a GTM newbie, I will share what I find in this issue in case it may be fo help to others.

To reproduce this issue on my site, I can do something like:

* Go to a site that I am not tracking using Google Analytics via GTM, for example site-managed-by-another-department.example.com, in an incognito window in the Chromium web browser.
* Go to the site I am tracking using Google Analytics via GTM, for example, this-is-mine.example.com
* Accept cookies using the dialog (if required)
* Open the developer console, and go to the "Application" pane, then "Cookies"
* Confirm I am seeing a cookie "_ga:xxx" for domain ".example.com"
* Go back to site-managed-by-another-department.example.com and reload it
* Open the developer console, and go to the "Application" pane, then "Cookies"
* Confirm I am seeing the same cookie "_ga:xxx" for domain ".example.com" that was set for this-is-mine.example.com

The link you share, "Configure and customize cookies", contains a section entitled "Change cookie domain" which has instructions on how to change your cookie domain from the default (which tracks activity across subdomains), to only applying to the current domain.

What is interesting to me in those instructions is that, in the gtag.js tab, it shows instructions on how to modify the Javascript source directly on your website by adding somethine like:

gtag('config', 'TAG_ID', {
  'cookie_domain': 'blog.example.com'
});

Indeed this seems to be exactly what the obsolete Google Analytics module does, based on the google_analytics_domain_mode setting.

However, the very philosophy behind GTM, as I understand it, is to be an abstraction layer between your website and third-party providers such as Google Analytics, Floodlight, and other services, making the configuration of those services possible on the GTM dashboard, and not in your source code.

As this Reddit post comment states:

If you weren't using GTM, you'd need to manually edit your website's HTML to add the new Javascript. However, with GTM, you just update your GTM settings and your website automatically gets the new Javascript.

So basically GTM exists so that a GTM manager in your organization can do all this stuff directly on the GTM dashboard, and never touch your site's source code (again, with the caveat that I am by no means an expert, this is just my understanding).

Therefore, by design, it seems to be impossible to modify this behaviour in the source code of the website, therefore I can't see any technical way of providing this functionality within this module.

The "Tag Manager" tab in the section entitled "Change cookie domain" seems to provide instructions on how to set the cookie domain directly on the GTM dashboard. If I manage to do this, I will write back here.

Hi @hmendes

files related to phpunit and docker

Although this is not something that's standard in Drupal projects, I use those as part of automated testing, here is how it works: on the github mirror of this project at https://github.com/dcycle/uli_custom_workflow, you will see a green badge that says "Passed", this means CircleCi tests are passing at https://app.circleci.com/pipelines/github/dcycle/uli_custom_workflow?bra...

In turn CircleCI tests are defined at https://github.com/dcycle/uli_custom_workflow/blob/1.x/.circleci/config.yml which basically says tests require Docker to be run and can be run using ./scripts/ci.sh

To run all tests locally without any other dependency, if you have Docker installed, you can run ./scripts/ci.sh on your machine, which uses Docker to run all tests including PHPUnit tests.

Need to merge 1.x into your MR branch and fix tests

The branch as it is, is based on version of 1.x which is not completely up-to-date. There are some changes to 1.x branch, including a change I just made a few minutes ago, which should be merged into the MR branch 3367414/3367414-move-configuration-to.

Once that is done, you can run tests locally by installing Docker and running ./scripts/ci.sh

This will yield some errors such as:

FILE: /code/src/Form/UliCustomWorkflowSettingsForm.php
--------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
--------------------------------------------------------------------------------
 6 | ERROR | [x] Use statements should be sorted alphabetically. The first
   |       |     wrong one is Drupal\Core\Form\ConfigFormBase.
--------------------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
--------------------------------------------------------------------------------


FILE: /code/src/Controller/UliUserController.php
----------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
----------------------------------------------------------------------
 5 | WARNING | [x] Unused use statement
----------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
----------------------------------------------------------------------

Once ./scripts/ci.sh works locally, I will be able to review and test the code.

Thanks for the quick reply @FlutterStack

I have tested everything locally using that technique and tests are passing:

Testing /var/www/docroot/modules/contrib/video_embed_field/tests/src/Unit
..........................................................        58 / 58 (100%)

Based on that, I am setting this to RTBC.

@FlutterStack thanks for the patch!

May I recommend putting the comment number along with the patch name? The reason is that you have you have two links called "3270201-vimeo-unlisted-videos-iframe-url-issue-fix.patch", and the patch in comment 4 leads to https://www.drupal.org/files/issues/2024-05-19/3270201-vimeo-unlisted-vi... → , and the patch in comment 5 leads to https://www.drupal.org/files/issues/2024-05-19/3270201-vimeo-unlisted-vi... → , which are slightly different.

I tested the patch in #5, above, by doing the following:

* Video https://vimeo.com/870790749/127317b755, which is known at the time of this writing to be public unlisted, works fine, shows a preview, and the popup works.
* Video https://vimeo.com/453364499, which is known at the time of this writing to be public and listed, works fine, shows a preview, and the popup works.

I did not run review automated test results because when I go to https://www.drupal.org/node/1243930/qa → , it says "No DrupalCI testing schedules can be added or updated". And the link "View GitLab CI pipelines for this project" goes to https://git.drupalcode.org/project/video_embed_field/-/pipelines which says "This project is not currently set up to run pipelines."

I did run:

php core/scripts/run-tests.sh --module video_embed_field --sqlite /tmpfs/test.sqlite --url http://webserver/ --dburl mysql://root:drupal@mysql:3306/drupal --verbose

with and without this patch, and I'm getting failures such as:

Drupal\Tests\video_embed_field\FunctionalJavascript\Colorbox   0 passes   1 fails  

So I assume I'm not running the tests correctly. If someone can give me instructions on how to run automated tests locally, I will be able to confirm whether all tests pass with this patch applied.

I will leave this at "needs review" until we can ascertain that all automated tests (including the newly introduced ones) are passing with and without the patch.

A little more on this issue:

• First, I have updated the version to 8.x-2.x-dev because it might be preferable to fix this in the latest branch, and then backport to the 7 branch later on.
• I have moved this from support request to feature request because it seems to be a missing feature

Here is the problem:

Example of a listed public Vimeo video which can be embedded

Let's say you have the video https://vimeo.com/453364499, which is a listed public Vimeo video, and you enter that in a video embed field, the resulting popup will be https://player.vimeo.com/video/453364499, which works fine.

Example of a unlisted public Vimeo video which can be embedded

Let's say you have an unlisted public video https://vimeo.com/881819838/e5f1e11b86, and you enter that in a video embed field, the resulting popup will be https://player.vimeo.com/video/881819838

This embedded URL will show "Sorry, We’re having a little trouble."

For this to work properly, we need to have the popup field being https://player.vimeo.com/video/881819838?h=e5f1e11b86

Remaining task

For Vimeo videos in format vimeo.com/ABC/123, the popup should be https://player.vimeo.com/video/ABC?h=123, not https://player.vimeo.com/video/ABC

alberto56 → created an issue.

Kristen Pol → credited alberto56 → .

I'm no longer getting an error when I apply the patch.

alberto56 → created an issue.

Thanks @aman_lnwebworks

It seems that the version of this module on GitHub and the version on Drupal are out of sync. On GitHub, this change seems to already be implemented:

https://github.com/dcycle/eventbrite_one_way_sync/blob/1.x/src/Eventbrit...

Therefore I synchronized the Drupal tree with the GitHub tree, and have published version 1.0.1 at https://www.drupal.org/project/eventbrite_one_way_sync → which contains this change. Thanks again!

Upon inspection, this was fixed in commit fe2d502d - Issue #3384929 by ChristianAdamski: Fix v4 Testing (10 days ago), where "public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition)" was changed to "public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition): DataProviderInterface" in ./modules/geolocation_address/src/Plugin/geolocation/DataProvider/AddressFieldProvider.php

However it is not included in the 4.0.0-alpha2 release, which I was using.

I will therefore set this to duplicate of #3384929 and starting using the latest dev release, my apologies!

I found the solution: in order to _not_ show the map when there are no locations, go to the view, then in the "format" section, click settings next to "Geolocation CommonMap", and once there, uncheck "Display map when no locations are found".

alberto56 → created an issue.

alberto56 → created an issue.

In an attempt to test this, I created a new site, then, I went to /admin/structure/types/manage/article/fields/add-field, and added a new field of type Reference > File which allows PDF imports.

Then I went to /node/add/article and created an article named "test" with a PDF import.

Then I went to /admin/content/files and noted the file's ID, which is 1.

Then I went to /admin/config/content/formats/manage/full_html?destination=/admin/config/content/formats and checked "Convert Legacy Media Tags to Markup", and saved.

Then I opened /node/add/page and created a page called "Test page".

In it, I added in the source code:

[[{"link_text":"this is a test","fid":"1"}]]

In text format "Full HTML".

Then I saved, but on the end page, I could see the following:

[[{"link_text":"this is a test","fid":"1"}]]

And not

this is a test →

If you would like me to commit the patch to the next version of the module, please provide a complete step-by-step guide to testing it, thanks!

Somewhat related, and in case it might be useful to anyone, I have created a module which allows administrators to set a custom "unique log in" message for use-cases other than the standard "click-on-a-link-from-a-lost-password-email" workflow: https://www.drupal.org/project/uli_custom_workflow →

Mixed is a valid type in PHP 8 as per https://php.watch/versions/8.0/mixed-type and in its watchdog_watchdog.info.yml this module declares it is PHP 8 dependent, so I think we're good there.

Also, I'm not sure about keeping markdown lines to 80 characters. According to https://stackoverflow.com/questions/29955688/in-markdown-is-there-an-off..., "There is no best practice for wrapping in Markdown. The only mention of wrapping in the original spec says that hard wrapping is permitted:", not _required_.

Unless we have a compelling reason to wrap to 80 lines, I prefer to keep it as is.

Thanks! Committed.

This now works on branch 2.x, see README

> Perhaps the two fields ("Untranslated message when a user is not logged in ...") could be put on their own config page, to minimize interference with Core settings? It could be under /admin/config/people/accounts/uli-custom-workflow.

Instead of moving the two new fields to their own page, I fixed where the submit handler resides in the form array. If we want to change where the custom fields reside, that would be a separate issue.

Setting to fixed [with this commit](https://github.com/dcycle/uli_custom_workflow/commit/84982c8adb6c49bb247...), thanks @ressa good catch!

I also tagged a new release, 1.0.0-beta5

Setting to major, as this will prevent certain core features from working, although with the workaround of uninstalling this module, setting values in /admin/config/people/accounts, then reinstalling this module.

Interesting. I think it probably is about whoever crafts the ULI to determine what landing page they want and append "?destination=xxx" to the ULI. Because this is already a core functionality, it's probably best not to not reproduce it here.

For example, I maintain a module which provides links on a source website to allow access to a destination website, logging the user in if they are not already logged in. In that module I plan in https://www.drupal.org/project/multiaccess/issues/3364969 ✨ Allow propagating the "destination" parameter to destination sites Fixed to leverage the "destination" parameter to allow redirecting users to a given path, and logging them if they're not already logged in.

Similarly, the https://www.drupal.org/project/one_time_login_link_admin → allows admins to provide other users with a ULI. Currently that ULI is not customizable with a "destination" parameter but that would be a nice feature.

Another reason for having the destination managed by whoever creates the link is that, then, they will no longer be dependent on this module to have the functionality of redirecting the user to a specific page; because it is a core feature.

Based on the above, and the previous comment, I will close this as works as designed. Thanks!

alberto56 → created an issue.

I'll change the title because what we want here is a "default" URL. (The default is currently the user page).

This should not be confounded with the possibility, currently available, of defining a destination, by appending ?destination=/admin/index, for example, to the URL.

For example, this can be added to the "forgot my password" messages at /admin/config/people/accounts

We can also do this in drush like this:

echo $(drush uli)?destination=/admin/index

Right now, if there is no "destination" parameter, we display the user page.

I didn't test the patch, but looking at the patch, it seems that the login form would redirect even if we're not using the ULI (even if we're logging in with our username and password). If that is the case, this would be outside the scope of this module.

Thanks! fixed

I created a dev release at https://www.drupal.org/project/uli_custom_workflow/releases → , maybe that will help? Otherwise, a patch or a pull request on Github (https://github.com/dcycle/uli_custom_workflow) is fine too.

Thanks for the kind words! I was not aware that my blog is no longer on Planet. Maybe they don't like me :)

I'll put that on my to-do list to ask to be reinstated next time I publish a blog post, as my last Drupal one is from over a year ago.

Agreed that MyUserController is an odd name. Would ULICustomWorkflowUserController be a good name? Maybe something shorter?

The message is wrong in case the destination parameter is used. For example, if one appends ?destination=/node to the one-time login link, one gets redirected to /node?check_logged_in=1, then it says "...set your password now...", but it is impossible to do so at this point, because now navigating back to user edit form, it is necessarily to know your current password to set a new one. Perhaps a different message could be shown if the "destination" GET parameter is set.

This has bothered me forever; I created a module as a workaround, it is at https://www.drupal.org/project/uli_custom_workflow →

This is already fixed

This is already fixed

This is already fixed

Hi! I will no longer be maintaining this project, so if someone wants to be a maintainer and create a Drupal 10 release, please open an issue for that, thanks!

Actually this is a PBKAC, just realized this is already returning FALSE, which is good.

alberto56 → created an issue.

I took @8ballsteve's patch at #27 and made a new version which works with 2.0.0-beta3.

This seems to works. Not sure it passes the smell test though...

namespace Drupal\my_module\Logger;

use Drupal\Core\Logger\RfcLoggerTrait;
use Psr\Log\LoggerInterface;

/**
 * The logger which intercepts system messages.
 */
abstract class MyModuleLoggerCommon implements LoggerInterface {

  use RfcLoggerTrait;

  public function logCommon($level, $message, array $context = []) {
    ...
  }

}

if (version_compare(\Drupal::VERSION, '10', '>=')) {
  class MyModuleLogger extends MyModuleLoggerCommon {

    /**
     * {@inheritdoc}
     */
    public function log($level, string|\Stringable $message, array $context = []): void {
      $this->logCommon($level, $message, $context);
    }

  }
}
else {
  class MyModuleLogger extends MyModuleLoggerCommon {

    /**
     * {@inheritdoc}
     */

    public function log($level, $message, array $context = []) {
      $this->logCommon($level, $message, $context);
    }
  };
}

I get a similar error if I try to use this code in PHP 8.1 and Drupal 10:

namespace Drupal\my_module\Logger;

use Drupal\Core\Logger\RfcLoggerTrait;
use Psr\Log\LoggerInterface;

/**
 * The logger which intercepts system messages.
 */
class MyModuleLogger implements LoggerInterface {

  use RfcLoggerTrait;

  /**
   * {@inheritdoc}
   */
  public function log($level, $message, array $context = []) {
    ...
  }

}

The above works fine in Drupal 9, but causes Fatal error: Declaration of Drupal\my_module\Logger\MyModuleLogger::log($level, string $message, array $context = []) must be compatible with Drupal\Core\Logger\RfcLoggerTrait::log($level, Stringable|string $message, array $context = []): void in Drupal 10.

If I change my code to be compatible, then when try the same code in Drupal 9 it no longer works.

You might be looking for route subscribers and event subscribers.

See https://drupal.stackexchange.com/questions/308071/in-event-subscriber-ho...

See  https://www.drupal.org/docs/drupal-apis/routing-system/altering-existing... →

This module is D10-compatible.

I know a lot of people who use one-time login links to log in all the time and never change the password (and have forgotten it long ago). "Set your new password now" gives the impression that you have to set the new password in order to continue, when in fact you can set your new password, but you don't have to. Perhaps "You can set your new password now" would be more appropriate than "Set your new password now".

This is already Drupal-10 compatible

This should be fixed in https://github.com/dcycle/convert_media_tags_to_markup/pull/12/files in the release 3.0.2

Please comment if the fix does not work for you.

Setting to fixed

The rendering problem referenced by @mouse70 has probably been fixed in https://github.com/dcycle/convert_media_tags_to_markup/pull/11/files and released in 3.0.1.

Hi @mouse70 thanks, can you please open a separate issue for the rendering problem? That seems pretty major, but unrelated to Ckeditor5 compatibility.

Patches are welcome.

Interesting. I found a similar issue on another module at https://www.drupal.org/project/improve_line_breaks_filter/issues/3326729 → and here is how they fixed it: https://git.drupalcode.org/project/improve_line_breaks_filter/-/commit/2...

This project is Drupal 10-compatible.

Closing, Drupal 10 version is now available.

This patch no longer applies as of yesterday's 8.x-1.15 release. Setting to needs work.