Anyhow here is the code i am using; i was going to depend on Libraries UI for 'As-needed assets for rich text → module but decided not to and did this instead:
/**
* Get all libraries, grouped by extension, with info.
*/
public function getAllLibrariesByExtensionWithInfo(): array {
// Start our list with the crucial not-actually-an-extension 'core'.
$extensions = ['core'];
$extensions += $this->listInstalledExtensions();
foreach ($extensions as $extension) {
$libraries[$extension] = $this->library_discovery->getLibrariesByExtension($extension);
}
return $libraries;
}
/**
* Return a list of installed modules, themes, and profiles.
*
* This excludes theme engines and other possible types of extensions.
*/
public function listInstalledExtensions(): array {
$extensions = [];
$extensions += array_keys($this->module_extension_list->getAllInstalledInfo());
$extensions += array_keys($this->theme_extension_list->getAllInstalledInfo());
$extensions += array_keys($this->profile_extension_list->getAllInstalledInfo());
return $extensions;
}
Full context (including, importantly, the dependency injection, made a little easier by constructor property promotion) at https://git.drupalcode.org/project/assets_for_text/blob/1.0.x/src/Librar...
The test that this module seems to have grabbed its code from that i mentioned is in core/tests/Drupal/KernelTests/Core/Theme/StableLibraryOverrideTestBase.php, line 122. Not sure why it checks for .info.libraries files but i think my code that both avoids that and includes profiles is better.
Wait no, there is a separate check for a physical *.libraries.yml file which is likely the cause of the reported bug. Here is the code i am using which avoids that unneeded check (seems to have been copied from a core test which is the only usage of LibraryDiscovery::getLibrariesByExtension in core).
(I don't know offhand any libraries that are added by the build hook so i have not tested.)
This module goes through every module and every theme (plus a special 'core' namespace) and calls \Drupal\Core\Asset\LibraryDiscovery's getLibrariesByExtension() method. So this would seem to be a bug, or at least poor documentation, in core?
If there is a way to see all libraries, including dynamic hook_library_info_build() ones plus changes made in hook_library_info_alter(), that would be wonderful. Right now it would seem the only way is to run the alter hook and use it to gather information rather than make changes. Which seems sub-optimal. (Just checked and the late, great, Drupal console had a command that used the same approach as this module. Side note: both miss profiles.)
Thanks ressa, text added, pretty much verbatim!
Thanks for the merge and thanks for the add!
Thanks! Yes, i am looking at https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → and realizing the expectation is that both widgets and formatters extend from a Custom Field base, rather than existing Drupal widgets being able to easily "opt in"— but your outline in this case of how the twain should meet would be greatly appreciated, and i hope open up the path for more contrib widgets/formatters to work with Custom Field.
Thanks ressa! Done, and i made grumbly comments in ✨ Gently nudge project managers to update default GitLab, when relevant Active lol
Have not seen the question raised and asked yet, so as a module maintainer i ask: can the syncing be automated? One less thing to have to think about would be lovely. If editing in either place affected the other, or if editing the default branch had to be done in only one place, i'd be happier.
Also, because GitLab makes it harder to find these options every day, for any maintainers stumbling into this thread, it is here:
https://git.drupalcode.org/project/EXAMPLE_PROJECT/-/settings/repository#branch-defaults-settings
The commerce_product module needs to be installed first, is all. Fix in issue fork.
Same error, The "commerce_product_variation" entity type does not exist. And this is starting on an installation that had no commerce installed.
Commerce Webform Order, https://www.drupal.org/project/commerce_webform_order →
is probably the way forward.
Noticed that ECA was in the full stacktrace so i'm not 100% sure this error can be reproduced without that, but i still think this is worth fixing here.
Realized if an original filename is NULL or an empty string, none of the processing, token or otherwise, is needed. (And so changed my fix from $original ??= "unnamed"; (after so much research to ensure we did not allow a version of PHP that did not understand the NULL coalescing assignment operator introduced in PHP 7.4, but at least i belatedly got the good news that Drupal 10 and 11 only supports 8.1+) to the quick return that is in the merge request.)
Remove mentions of Drupal 9 and PHP 7, replacing with current equivalents to explain the unscheduled minor release if a dependency of Drupal bumps the minimum PHP version that Drupal can support, and be explicit that no version of PHP 7 is supported by current releases of Drupal.
mlncn → created an issue. See original summary → .
Based on reading 🌱 Requirements and strategy for Core Mailer Active there was disagreement in the architecture for the idea of a core, Symfony-based mailer between adamps and the other person mostly active in the core queue for this, znerol, and as a result adamps stepped away from the core plan and further developing this module.
I'm having trouble following all the related core issues, but they do seem to be continuing to progress somewhat since the late August split and still seem hoping to have an experimental core module by Drupal 11.3.
Remains to be seen if come Drupal 12 time the 46,000+ sites using this module will be most in need of documentation for switching to the in-progress proposed core module or somebody to take over maintaining this a while longer.
Forums and chat serve different purposes— even with a better, open chat like Zulip, that could be archived for visibility on the web, forums are better for natural knowledge-building and onboarding.
Agree that forums should continue to be officially recommended and that we encourage the practice of copying knowledge from chat into forums.
Pretty confused because at /admin/structure/webform/config with Webform 6.3.0-beta5 i already see:
Third party settings
Honeypot
- Protect all webforms with Honeypot
- Add time restriction to all webforms
Enabling it causes the same setting on individual forms to visually be locked to on.
On the other hand, the time limit is not working at all; i have it set to seven seconds in Honeypot configuration and if i submit the form immediately as an anonymous visitor it still allows the submission.
I have not tested the regular honeypot protection the same way, but i at least can see in the page source HTML that the hidden form field is added.
Would this issue make the 'all webforms' protection actually work? Of course, the time restriction for webforms is not working for me when i disable the all forms option and configure it for one individual form either. (Opposite of this issue but per-webform time limits would be an excellent option, as webforms can vary hugely in the time they should take to fill out.)
Am i missing something?
I don't think begrafx and i both added something about ui_patterns to our composer.json randomly— at some point ui_patterns must have asked for this or done it itself:
"extra": {
"allowed-packages": [
"drupal/ui_patterns"
]
},
Presuming the closing of the issues reporting this message means this allowed packages section can be deleted.
Open to co-maintainership to unblock issues like this.
Awesome! Update made, added to the README also.
If we are beginning to use/recommend "Conventional Commits" do we want to link to https://www.conventionalcommits.org/en/v1.0.0/ or probably better our own page on commit message guidance (that references that base standard)?
Updated the issue summary and as noted the fix seems to be entirely doable in Better Exposed Filters, 📌 Use the view base URL for the exposed filters form action Active
(As suggested by Chrisolof in ✨ Support facets 3.x facets exposed filters Active )
Also needed to cover the case of the reset button (what i called the clear facets button in the initial description).
This used a redirect and "" and it has similarly been updated to check for a View display URL before falling back on "". It should be possible to share exactly the same logic if we wanted to and there was a logical place for Plugin/views/exposed_form/BetterExposedFilters to share a trait or something with Plugin/BetterExposedFiltersWidgetBase but i don't think that's very important.
I am not sure how to write tests that depend on a separate module— basically custom code in the test that does what Facets Pretty Paths does?
Including a patch simply because the issue fork page is spouting nonsense about 21 commits behind, 49 commits ahead of the upstream repository, although everything looks good with the merge request from the issue standpoint here.
Just documenting here that Drupal core recipes are in fact in Drupal core, at core/recipes: https://git.drupalcode.org/project/drupal/-/tree/11.x/core/recipes?ref_t...
(Yes, this needs documenting, i went through documentation and these issues before learning this from looking at Jim Birch's Kanopi's Sapling recipes!)
Just documenting here that Drupal core recipes are in fact in Drupal core, at core/recipes: https://git.drupalcode.org/project/drupal/-/tree/11.x/core/recipes?ref_t...
(Yes, this needs documenting, i went through documentation and these issues before learning this from looking at Jim Birch's Kanopi's Sapling recipes!)
This is what has been running for a few months for the picky client, and they are very happy with it! I'd like to start using it in more places too. I do find it the ideal compromise between say media_entity_download where you have full control over the path but Drupal needs to be in the loop every time and media_entity_file_replace
Missed that question but i will participate in https://www.drupal.org/project/issues/site_moderators → as Gisle mentioned.
Merge request !13162 is a straightforward reroll— exactly what is in daniel korte's patch initial patch in #2 🐛 Adding attributes to views-view-list.html.twig doesn't work if Views List class Style option is empty Needs work got into core through changes made out of this issue (without tests?!), so technically the problem stated in the title of this issue is now fixed in Drupal core. My re-roll of a merge request therefore only preserves jwilson's proposal in #12 🐛 Adding attributes to views-view-list.html.twig doesn't work if Views List class Style option is empty Needs work , implemented in gauravvvv's patch in #24 🐛 Adding attributes to views-view-list.html.twig doesn't work if Views List class Style option is empty Needs work , to not blow away attributes that were added by a possibly earlier preprocess.
I agree this is how it should work, but am not up for a test, let alone making this consistent everywhere, and i know there are rumblings about somehow getting rid of hook_preprocess entirely, however that would work, so i leave this humble re-roll and update as my offering.
Opened a followup for the SpamSpan change (which, as noted, is not in config, and i don't think needs to be) instead of Invisimail: 📌 Switch to using SpamSpan if available instead of invisimail Active
Brought into both branches.
Thanks, still looks like the best fix for the moment.
Yep all it needs.
yep got it
Ah so that is what the problem is. Wherever that is documented i must always get that wrong, despite having tried in the past both with manual instructions and the rebase button in GitLab; it had seemed the catch-up rebase itself was the problem. Thanks. Also thought i had fixed it in https://git.drupalcode.org/project/redirect/-/merge_requests/164.diff (in that it was one line and useable, at least).
Either way, despite the maddening fork PLUS branch setup of Drupal issues, yes straightforward re-roll (the lines above had been changed to be better self-documentation) and back to RTBC.
mlncn → changed the visibility of the branch 3342409-redirectformnodeformalter-calls-getinternalpath to hidden.
mlncn → changed the visibility of the branch 3342409-avoid-internal-path-call-on-unrouted-url to active.
mlncn → changed the visibility of the branch 3342409-avoid-internal-path-call-on-unrouted-url to hidden.
mlncn → created an issue.
Based on 🐛 Fix accessibility issues by using visually-hidden on hide and unsetting title element on remove Needs review that is the functionality the module has now— `visually-hidden` on Hide, and fully removed for Removed. So this is all set?
Frustratingly, instead of being committed, this now needs a re-roll :-/
Very nice improvement. Went a baby step further and changed "reorganize" to "reorder" for flat vocabularies.
Thanks for the work and the review!
Made some copy-edits to the form (including describing the newly added feature from [ 📌 Hide "Add child" link from entity operations Active ] and put the use statement in order.
Would welcome follow-up efforts to convert this to the new (11.2+ only) way by using a new OOP hook for the help text.
Thank you!
While no Drupal.org-hosted module needs a composer.json (and the dev branch can now be installed via composer because we have switched it to a supported branch name (2.0.x) allowing us to make an official dev release → ), i agree that modules should have a composer.json primarily because it makes uising issue forks of modules much easier.
mlncn → created an issue.
Looks good; sorry for the delay everybody.
The commands can be seen and run. The main need seemed to be the drush.services.yml, which is not supposed to be needed since Drush 13, but there is documentation and then there is what actually works. I'm still getting errors ("> [warning] Undefined array key "success" batch.inc:229; [error] Error: Call to a member function claimItem() on null in _drush_batch_worker() (line 242 of /var/www/html/vendor/drush/drush/includes/batch.inc) #0 /var/www/html/vendor/drush/drush/includes/batch.inc(204): _drush_batch_worker()"), but that might be with my plugin not the new Drush implementation.
Ah, Drush 13 changed things up: "Drush 13 expects commandfiles to use Autowire to inject Drupal and Drush dependencies. Prior versions used a drush.services.yml file which is now deprecated and will be removed in Drush 13."
Also getting what seems to be errors due to this with content moderation and paragraphs. (Running the drush command for Cached moderation state → module brings up a bunch of "An existing default revision of the 'paragraph' entity type can not be changed to a non-default revision." errors. Seems there should be a change record with some hints of what to do with content created before this was enforced?
I've only just started using it myself, but maybe Batch Plugin → module would make it easier to do this work through the UI, with Drush, or on cron, which is i guess what i need, to initialize cron queue batches from an install hook.
Welll Features may never export namespaces correctly? But six years on we may as well do it correctly ourselves.
This is an accessibility issue, that the descriptive label (say, "Date of birth") is not connected to the form label immediately connected to the form field for a screen reader (will only say "Date").
OK this is 100% cosmetic changes to the code formatting.