🇨🇦Canada @ryanrobinson_wlu

ryanrobinson_wlu → created an issue.

This works for me. I've just started testing the module with this patch, and everything is good so far.

I don't really see a status option for "it's done but not in a stable release yet" so I went with the closest I saw, keeping it open so anybody else looking for the same will find it easily.

I tried this patch as I was looking for the same thing. The general idea works, but I have a couple suggestions.

One is the upgrade path if this is added when you already have a button. I had an existing button that was set to only allow the Teaser display mode and was showing the caption and alignment options. After adding the patch, all of those options went to blank, meaning all the display modes showed up as options and caption/alignment did not. I think this should maintain existing settings as the default: whatever I previously had in display mode, and caption/alignment on. Imagining this coming through as a release, some would be surprised to have the behaviour changed.

The second is that now the second page is unnecessary. The first page I select the entity I want to embed. The second page only shows me that same entity name again. Can that second page be skipped entirely if there are no options on it?

The changes work in my tests, no more deprecation warnings in the logs.

One issue I've now encountered with the patch in #273 is that it adds a new functional test, but the setUp function there does not have the void return declaration, which results in throwing an error if I try to run any functional tests. See https://www.drupal.org/project/recaptcha/issues/3446000 🐛 Functional Tests: Declaration of Declaration of Drupal\Tests\recaptcha\Functional\RecaptchaJavascriptTest::setUp() Closed: duplicate . I added that to an updated patch here.

My editor (VS Code with a Drupal formatter) is pointing out other issues with that file, but those ones don't stop me from running other tests, so I'll leave that to those who are working on that test.

Ah, thanks for catching that the one other patch I'm using for this module is what is adding that bad test. I missed your edit on your first comment before I made my response. I was getting very confused why there was no alignment between the composer version and the repo version. In that case, I should be able to edit that patch file to add that void declaration.

Thank you! The bit I looked into #[AllowDynamicProperties] I got the same impression: maybe there are some situations where it is necessary, but the proper solution usually is to declare the properties.

You're right, I don't see it in 8.x-3.x-dev either. Is there any hint that will be in a stable release soon?

I'm attempting to put together a patch for 3.2, so that tests of my custom modules could run in composer-built CI, but I can't find a way to clone that specific release in order to build a patch of it (using instructions here: https://www.drupal.org/docs/develop/git/using-git-to-contribute-to-drupa... → ). Do I need to switch to the non-stable dev branch or just not have any functional tests until the next release, or am I missing some other way to tell composer I want stable but with this one fix?

ryanrobinson_wlu → created an issue.

Works and makes sense for me.

ryanrobinson_wlu → created an issue.

Ah, great news! Hopefully we'll see it get through to stable before we put production up to 8.2, but at worst I can either write my own patch or ignore the deprecation warnings for a bit longer.

Update: I got three more of them after creating a new H5P node (a Multiple Choice quiz, but I don't know if that matters).

Deprecated function: Creation of dynamic property H5PValidator::$h5pCV is deprecated in H5PValidator->__construct() (line 743 of /opt/drupal/vendor/h5p/h5p-core/h5p.classes.php).
Deprecated function: Creation of dynamic property H5peditor::$content is deprecated in H5peditor->processParameters() (line 158 of /opt/drupal/vendor/h5p/h5p-editor/h5peditor.class.php).
Deprecated function: Creation of dynamic property H5PContentValidator::$allowedStyles is deprecated in H5PContentValidator->filter_xss() (line 4198 of /opt/drupal/vendor/h5p/h5p-core/h5p.classes.php).

Patch also worked for me.

Minor note on the issue description: this started with PHP 8.2, not just 8.3. I found it when I tried updating from 8.1 to 8.2.

ryanrobinson_wlu → created an issue.

Same issue. I enabled term_merge on my local development containers and the error is now gone - I have not yet tested our automated deployment to other servers - but I agree that there needs to be a smoother upgrade path in place.

ryanrobinson_wlu → created an issue.

I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.

I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.

I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.

I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.

I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.

I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.

I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.

I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.

I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.

I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.

I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.

I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.

I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.

I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.

I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.

I think you're right. I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.

I think you're right. I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.

I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even though I specified which group of tests to run.

I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even though I specified which group of tests to run.

Looks good to me so far! Thank you.

I'm still getting the other one about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including linkit). So it's probably another module's problem that is showing up in this module's report even though I specified which group of tests to run.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

I work with @mweiler so I'll jump in here.

The biggest thing is size of the floating icon in the bottom. We'd like it significantly bigger, something like:

.shut #toggle {
    min-width: 72px;
    height: 72px;
}

.pass.shut #toggle {
    font-size: 64px;
}

Then increase the text of the tip wrapper to match the font size of everything else on our site, instead of set at 14px, and its colour to match our main font colour (in our case defined as a variable for our exact black).

.wrapper {
  font-size: 1rem;
  color: var(--black);
}

I might also look at changing the colours to match our brand colours - and from your previous comment maybe I can already do that - but that's not a high priority.

I have not been able to replicate the interface shared by @jannakha. I can say that part of the difference is the IMCE file browser module. If I disable that, and check the "Enable image uploads" button in the text format configuration, I will see the icon shared by jannakha, the one with the up arrow. But if I click on that, it immediately opens my Windows Explorers for an upload, with no in-between options shown here to distinguish between "upload from computer", "insert with file manager", or "insert image via URL."

If, with IMCE disabled, I uncheck the "Enable image uploads," I get the icon with the link on it instead, and clicking on it gives the prompt to enter a URL, like @mweiler's initial report but without the IMCE file browser button beside the link box.

That is consistent with the wording of the "Enable image uploads" option, which says "When enabled, images can only be uploaded. When disabled, images can only be added by URL." It can do "only" one or the other, not both, without IMCE.

Drupal core with CKEditor5 10.2.4, the latest stable as of this writing. Maybe the @jannakha version is Drupal 11 and this has been improved to allow both without needing IMCE? I have not yet started our Drupal 11 update tests so don't have an environment ready to try that.

So, conclusion 1 is that the problem @mweiler is reporting is probably coming from IMCE, not CKE5 in core. Conclusion 2 is that we can't have both mechanisms for adding images without IMCE, so then the question becomes whether we want one button with an inaccessible-by-keyboard file upload, or two buttons that are maybe more confusing to differentiate at a glance.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

I can confirm that the change worked for me. I added it as a patch to my composer, ran the tests on my local dev environment, and those warnings are no longer in the results.

I can confirm that I added this change as a patch to my composer.json and I no longer receive that fatal error running tests (I get a different one from a different module instead).

Came here to report the same one. I believe the change required is as simple as the change in the branch here, so I would love this merged into a release soon.

ryanrobinson_wlu → created an issue.

It looks like I don't get the warnings when testing against the dev branch, only against the latest stable, so I'm guessing it's already been fixed but hasn't made it into a stable release yet. Thank you! I can ignore the warnings until the next release is ready.

Drupal core 10.2.3, PHP 8.1.27.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

I am encountering this error on 10.2.1, or at least a closely related one. I tried to remove allowing dl, dt, and dd tags after the 10.2.1 update, and I get this error:

The following attribute(s) are already supported by enabled plugins and should not be added to the Source Editing "Manually editable HTML tags" field: .

So it's not citing any plugins that are already supported and should not be added, but still throwing that error anyway.

I encountered this error and will add a note here in case anybody else has the same cause as I did.

I created a new data export display on a view, where the other displays were pages and blocks, using the +Add -> Data Export link. I set up my view including the path with the .csv in the filename, then kept getting the error.

Then I discovered in Format -> Format -> Settings there is also an option there to set the accepted request format. That also needs to be set to csv.

ryanrobinson_wlu → created an issue.

ryanrobinson_wlu → created an issue.

+1 would love for this to happen.