🇺🇸United States @dave reid

megachriz → credited dave reid → .

dave reid → created an issue.

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

dave reid → created an issue.

dave reid → created an issue.

I would agree this is at least major since the module isn't functional without this fix. I have tested the fix using the MR changes and agree this is ready for merging and releasing.

Can you check if 🐛 Preview results in Error: Call to a member function getDefinitions() on null Active resolves the issue instead?

This is a duplicate of https://www.drupal.org/project/focal_point/issues/3462165 🐛 Preview results in Error: Call to a member function getDefinitions() on null Active

Thanks all!

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

Merged and releasing!

Marking as working as designed since this isn't an issue with the actual module here.

Committed and pushed #2 to 2.x. Will create a release shortly.

Hey sorry all, life has been super hectic the last couple of months.

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.

https://www.drupal.org/project/library_attach/releases/1.0.1 → is out.

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.

This was fixed by 🐛 Ajax error Undefined index: target_bundles in entity_browser_entity_form_inline_entity_form_reference_form_alter Fixed

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.