Ah just ran into an issue on this, will need to check the solution more.
First time doing this, I guess I opened a request somehow on 11.x. Sorry for the noise.
I've changed the check to look at the asset type rather than whether it's minified. https://git.drupalcode.org/project/drupal/-/merge_requests/12687 has green tests, so marking this as needs review.
benabaird → changed the visibility of the branch 3535330-assets-paths-in to hidden.
benabaird → changed the visibility of the branch 11.x to hidden.
I've opened a follow up issue https://www.drupal.org/project/drupal/issues/3535330 🐛 Assets paths in CSS no longer rewritten when aggregation is enabled Active for this.
benabaird → created an issue.
This is causing an issue for us with the Font Awesome Icons module loading minified CSS from /libraries/; the relative urls for webfonts are no longer rewritten upon aggregation.
If I understand the original issue correctly I think the fix on the issue should be to check if the asset is of type external before attempting to optimize it, as that's what's triggering the exception, rather than checking if it's minimized. This isset() check might work indirectly for external assets, but I'd guess by some other side-effect of external assets never having a the minified key set.
benabaird → created an issue.
Thanks for this, I was not aware of this recommendation.
benabaird → made their first commit to this issue’s fork.
benabaird → created an issue.
benabaird → created an issue.
Updated this issue for the 2.x branch.
Done in 2.x branch.
I'll be honest, there was no intent of using this module for large lists of nodes when built. If someone wants to work on a more performant filtering option (perhaps as a sub-module) I'm open to it, but for large amounts of entries an entity reference autocomplete is probably the better option.
I appreciate the merge request, but it's not standard practice to minify assets in contrib modules. This module does currently have a build process that can support it, but the plan is to remove it when all browsers within the last 5 years have support. At that point there will be no build process and the JavaScript will be unminified. I'd rather not make that change, and let individuals use a module like Minify JS → if they desire it.
Thanks for the issue and starting on a merge request.
I've added translations in a few more spots and also noted where labels are required.
benabaird → created an issue.
benabaird → made their first commit to this issue’s fork.
benabaird → created an issue. See original summary → .
benabaird → created an issue.
benabaird → created an issue.
benabaird → created an issue.
benabaird → created an issue.
benabaird → created an issue.
benabaird → created an issue.
benabaird → created an issue.
benabaird → created an issue.
benabaird → created an issue.
This was added in the 1.2.2 release but never marked as fixed.
This issue was caused by the fix in Modal/Dialog type behaviors are reversed in JavaScript 🐛 Modal/Dialog type behaviors are reversed in JavaScript Active not updating the field widget. Updated the field widget and added a test to check this.
At this point I don't think we want to add the configuration option added in https://git.drupalcode.org/issue/multiselect_dropdown-3492120/-/tree/3492120-modalbreakpoint-uses-enum, and instead always display it as a dropdown on edit forms as was the original intent.
benabaird → changed the visibility of the branch 3492120-modalbreakpoint-uses-enum to active.
benabaird → changed the visibility of the branch 3492120-modalbreakpoint-uses-enum to hidden.
benabaird → created an issue.
Ah I see. Sorry, I was confused by the issue description and the mention of Select2.
benabaird → created an issue.
Thanks for using the module!
How to implement non-standard input types is documented in the readme.
benabaird → created an issue.
benabaird → created an issue.
benabaird → created an issue.
benabaird → created an issue.
benabaird → created an issue.
This reduces the number of tests run from 75 (with 526 assertions) to 61 (with 436 assertions).
Time to run locally reduced from 5 minutes to 3 minutes.
benabaird → created an issue.
Failed PHPStan test is not a part of this work, tracked in Fix next minor PHPStan issue in tests 📌 Fix next minor PHPStan issue in tests Active .
benabaird → created an issue.
benabaird → created an issue.
benabaird → created an issue.
benabaird → created an issue.
benabaird → created an issue.
benabaird → created an issue.
Very interesting, I was not aware that core considered these unique (it is documented).
Digging, the exception only is thrown when using ::create() from a bundle class.
There's some ambiguity in core on this, so closing this issue for BCA.
Thanks for looking, and for this very useful module!
The failing phpcs tests in MR16 are in files that were not touched by this work, so I've left them as-is to be resolved in a different issue.