dave reid → created an issue.
dave reid → created an issue. See original summary → .
This has already been fixed.
Merged the changes and will tag a new release shortly here.
dave reid → made their first commit to this issue’s fork.
Actually it looks like if there is a future/forward revision, and you go to Delete content, the deleted flag only applies to the latest revision, and not the whole node (only saved to the node_field_revision table, and not the node_field_data table) which causes the issues.
I just ran into this today where the latest revision on a published node that goes with workflows. Can revisions just be deleted like normal instead of trashed?
I'm still here and am working to review this. I'm not sure we need the logic to assume local by default, then CDN, rather than the other way around, since they're functionally the same?
Moving to the URL embed project. Could you please confirm the version of the module you are currently using?
dave reid → created an issue.
Closing in favor of https://www.drupal.org/project/helper/issues/3433341 📌 Automated Drupal 11 compatibility fixes for helper Needs review
Going to merge the existing MR since it's functionally passing for D11, just regression on one test for some reason, and still passing for D10.
dave reid → made their first commit to this issue’s fork.
dave reid → created an issue.
dave reid → made their first commit to this issue’s fork.
The 5.x branch of the module is not supported, this was already fixed on the 3.x branch with 🐛 Deprecated function: Creation of dynamic property Drupal\features\FeaturesGenerationMethodManager::$cacheKeyPrefix is deprecated in Drupal\features\FeaturesGenerationMethodManager->__construct() (line 28 of modules/contrib/features/src/FeaturesGenerationM Active , so I'm going to mark this as a duplicate.
dave reid → changed the visibility of the branch 3507596-fix-regex to hidden.
quietone → credited 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.
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!