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.
Seems the best solution, despite adding one more nested div, is to add the form-element template as a wrapper, which should let all themes treat form items as they thing they should be treated.
Happy to add a configuration option for this, disabled by default, if at most we want an optional change that does not impact existing sites at all.
mlncn → created an issue.
Confirming the code quality and functionality of this patch. Also think that it is the right solution, and a good one. In particular for a vocabulary where a user does not have edit permissions for the terms, the inapplicable operation link to "Add child" is very in-the-face and distracting.
Back to needs review at the very least, for the patch in #14 as per #20
It was RTBCd (comments #15 and perhaps #18) and it still works 7 years later! To address #16 the module could offer an interface for capturing keycodes but clearly that is not needed to address the immediate pain of Coffee stealing a common browser shortcut. And there is no need to prompt administrators to configure the keys because there is an update hook to assign all the currently available keys by default.
Improvements that could be made in follow-ups but should be considered out of scope for this patch which allows site administrators to making Coffee more compatible with browsers and more usable for more people:
- Allowing any key code to be used.
- Providing a helper for capturing keycodes.
- Allowing individual users to set their own keycodes.
Changing the issue title to make clearer that last one in particular was never the intent of any of the patches contributed here.
Thank you so much! It definitely was not healthy there for a minute and very much needed this report!
Thanks! Are you using the module actively in Drupal 11 or simply helping out here? Thanks!
Tested, fixed follow-up error, and tagged a release, 8.x-1.3.
Thank you for the report, so sorry for releasing a Drupal 11 version that was not actually compatible.
Gentle reminder that rather than proclaiming a module "dead" this is a golden opportunity to contribute a fix → . Although, on second thought, that is thousands of words making clear how complicated it is to contribute what should be the simplest of things. Ah well. Fix coming shortly.
mlncn → changed the visibility of the branch 2906496-give-media-a to hidden.
This problem of the Drupal\pathauto\PathautoItem object (contrib, i know, but it extends Drupal\path\Plugin\Field\FieldType\PathItem with minimal changes not relevant here) having an alias property of NULL is also an issue for validation even when automatic aliases are enabled.
The updated workaround/fix is now in a brand new branch with a merge request that has only what it should have.
Still do not know how the alias property can end up NULL in the first place – when the values array has the alias correctly in the very same object – so not sure how to add a test, but the fact that all existing tests pass indicates that it is a harmless failsafe.
mlncn → changed the visibility of the branch 3535695-url-alias-field to hidden.
mlncn → created an issue.