Would this be a good use case for https://www.drupal.org/project/fallback_formatter → ?
Tested and committed #2 to 8.x-1.x. Thank you so much for your contribution!
I had a use case where the plugins were being dynamically generated from YAML files, and while an incredibly generic config schema could be used for all of them, we wanted to provide the specific config schema for each one based on the YAML plugin definition, instead of having to duplicate both the YAML plugins and the config schema for each individual one. I think there's still a valid use case for this.
The library is not getting any more updates, no, and PHPUnit 9 is also not getting any more bug fixes either. Ideally updating to PHPUnit 10 or 11 removes the dependency on the abandoned package.
Also if you are not pushing your site's dev dependencies to your hosting/production code, you can also use composer audit --no-dev.
Yeah apparently searching for things with a dash in the middle caused no results to show up.
I think this can be marked as closed since the original maintainer of that package has added the desired abandoned: false to the package, created a new release, and then re-archived the repository.
https://github.com/sebastianbergmann/phpunit/issues/4828 was updated with a new release adding abandoned: false to prevent this error on composer audit going forward. I think this can be closed as fixed now.
Dave Reid → created an issue.
Not able to remove it myself so please go ahead and remove it for me!
+1 to deleting the role, I don't see why I'd need it. I might be able to remove it myself.
Dave Reid → created an issue.
Dave Reid → created an issue.
I think the biggest benefit of Embed is having the preview route/callback defined for you with additional security checks upcoming like 📌 Deprecate EmbedButtonEditorAccessCheck in favor of a generic access check for "does a filter format or editor have a filter plugin enabled" Active . And not having to fork DomHelperTrait. If there's things I can improve in Embed to help this out, let me know. I could also see separate buttons for YouTube or customizing in the embed type which providers are allowed, which would be possible with the embed plugins to have more than one button for different providers if sites wanted to build it out that way.
Can you check your browser's JavaScript console for any errors that might have stopped JS from running to remove it?
Ideally I think it would work without inline_form_errors given it's not enabled by default or still considered optional even if it were enabled by default in the future. I'm sure it's a bug somewhere that just needs more investigation time in order to surface those errors.
Merged and tagging release now!
Actually it looks like it's already failing on CI: https://git.drupalcode.org/project/library_attach/-/jobs/283789
Hmm, odd. I wonder if this is just failing now on newer versions of Composer. I wonder if we could just use a more explicit dependency like ^4.0 || ^5.0 || ^6.0 || ^7.0.
I will add some CI integration so that we can snuff this out and get it resolved quickly!
Dave Reid → created an issue.
Dave Reid → created an issue.
Dave Reid → created an issue.
Dave Reid → created an issue.
Dave Reid → created an issue.
Dave Reid → created an issue.
Dave Reid → created an issue.
Will add a new release with D10 compatibilty shortly here.
https://www.drupal.org/project/helper/issues/3375973 ✨ Helpers to hide deprecated or hidden blocks/layouts Fixed is also an alernative for this module as well.
I've added to the project page the issue is using reflection to change a class method from protected to public, and using reflection is typically not recommended for production environments/code.
I've added to the project page the issue is using reflection to change a class method from protected to public, and using reflection is typically not recommended for production environments/code. However, since core hides the data we need, there's no way around it.
Does not need to stay open, I made sure to merge the latest 8.x-1.x commits to the 2.x branch now.
This was fixed already in my attempt to get GitLab CI running successfully with https://git.drupalcode.org/project/config_override_warn/-/commit/2fe6d04...
This was already fixed in https://git.drupalcode.org/project/config_override_warn/-/commit/2fe6d04...
Plugin constrictors have always been internal and not APIs, even for core. Sorry this should have potentially been flagged as possibly causing that. I'm not sure we can do anything at this point.
The module already checks the view label permission in \Drupal\entity_browser\Plugin\EntityBrowser\FieldWidgetDisplay\EntityLabel and was released in the 2.9 release with https://www.drupal.org/sa-contrib-2023-002 →
Dave Reid → made their first commit to this issue’s fork.
Dave Reid → created an issue.
Can we get a merge request version posted so that we can start running the new GitLab CI testing against this?
I cannot replicate this failure in tests or locally either. Can you help provide some steps to reproduce this issue?
There's no reason that entityTypeManager shouldn't be set with dependency injection.
Dave Reid → created an issue.
Patch version against the latest 2.10 release.
Agreed, let's just fix this in 8.x-2.x directly. I shall ensure this gets in the next release.
I solved why the edit dialog was always using the default form mode and not the configured version, it was the routing definition had it hard-coded to default. Functionality wise this is working again.
This will need to be checked again or updated after 🐛 Use theme function for ajax progress Fixed was merged.
I think you are possibly using core's Media Browser, and not the entity browser?
Patch no longer applies and needs to be re-rolled or MR opened.
Merged latest MR to 8.x-2.x after testing. Thanks all!
Dave Reid → made their first commit to this issue’s fork.
Committed to 8.x-2.x. I'm a little curious, what if I did want to select the same entity more than once? Should this be configurable? Or is it generally undesired?
I'm curious why it's this module's responsibility to add that library and why it isn't included with the rendered View? Does this point to a Drupal core bug?
Dave Reid → made their first commit to this issue’s fork.
Actually this looks like it is handled by 📌 Remove update hooks, update test and requirements hook RTBC
Tested and confirmed this resolved all config schema errors.
I had to change this replacement from boolean to string for the "multiple" variable.
FYI boolean is the correct type here. Once this is committed and you update, if you re-save the entity browser configuration it should fix itself from a string to the correct boolean type for that value.
I found a couple more things to fix and opened a MR. Working on validating and reviewing the changes.
Dave Reid → made their first commit to this issue’s fork.
Tests are currently passing on Drupal 8.1 and 8.2.
Tested both usages of the progress throbber and both work as expected. Merging to 8.x-2.x.
Dave Reid → made their first commit to this issue’s fork.
@scotwith1t I think the modal buttons issue is a core bug. See 🐛 "Add another item" field button is displayed as a modal action Fixed .
Dave Reid → created an issue.
Yup, I am working on reviewing the RTBC queue still.
Dave Reid → created an issue.
Committed to 8.x-2.x.
Updated patch against current 8.x-2.x.
Dave Reid → created an issue.
Dave Reid → created an issue.
Dave Reid → made their first commit to this issue’s fork.
🐛 [Entity Browser] Tests are failing on D10 Fixed had a bit more progress that I used to merge into the 8.x-2.x branch, so I think most of these things are addressed aside from removing the old update functions and the hook_requirements().
I do agree that I'm not sure this makes sense to do given that core doesn't have any access API around file entities, but the change to MediaImageUpload *does* seem reasonable to me since media entities do have a full access API.
Makes sense to me, committed #3 to 8.x-2.x.
this should wrap the whole thing in an if statement and possibly also log a warning or something, because the only reason for this that I can see is misconfiguration
I still don't see this being addressed in the latest version.
Committed #8 to 8.x-2.x. Thanks all!
Updating as per latest comment.
FYI the Embed and Entity Embed modules fully support CKEditor5 now in their latest stable releases. We also have test coverage running for both CKEditor4 and CKEditor5 in the module without any changes and both are passing.
All DrupalCI configurations have been removed/disabled.