Can confirm that existing sites are still able to make recurring donations with the 2.0.0-beta6 release, so whatever the issue, Stripe's API does not make this impossible.
Do new accounts get explicitly told which API versions are allowed? I thought Stripe let APIs specify any version regardless of what the default is in a Stripe account (as is happening: "Stripe/v1 PhpBindings/5.9.2" is the source of the recurring donation made a couple days ago), so there should not be anything stopping new Stripe accounts from having donations created using the old API.
Also wanted to point out #2984105: Error: cannot reference variable name "facets_query" more than once.' → as prior art or rather proof that this could or used to work—back when Facets had their own independent existence from Views, the information for how to filter could come from the facets, and that issue kept that working. So our work here is to make the same thing possible when all the facets information is in a non-page view.
The draft merge request has a janky proof of concept. Uses a separate controller since it should be extending the NodeView controller instead of the View (view) controller.
Aside from the hard-coding of the node with the embedded view, the big problems that remain:
- Removing the last facet fails again a la 🐛 Remove last facet fails Active
- Unaliased path for the node with facets
/node/2464/focus/disability-accessibility/focus/housingworks but aliased path/projects/focus/disability-accessibility/focus/housingdoes not.
Thanks so much! Sorry i had not even realized we were running betas of Webform on our production Drupal 11 sites.
For anybody following along, you can get the D11-compatible rolling dev copy of Webform CiviCRM here.
"repositories": {
"webform_civicrm": {
"type": "git",
"url": "https://github.com/colemanw/webform_civicrm.git"
},
"drupal": {
"type": "composer",
"url": "https://packages.drupal.org/8"
}
},
"require": {
"drupal/webform_civicrm": "6.x-dev@dev",
}
Mailing list integration is working great; i may have made a configuration mistake on the donation connection. Will try to contribute to documentation at least as i get oriented.
Possibly this is not really needed. Certainly for this specific case of CiviCRM the existing exclusion by CSS selectors is fully sufficient.
For Skip over these elements:
.page-civicrm *
And Editoria11y is effectively disabled in CiviCRM.
Oh— marked this a 'major' feature request even though i know i'm asking for a magic pony because this ability was previously working: 🐛 Page not found Fixed
And embedding views in other pages is becoming increasingly common in Drupal (as evidenced by Drupal CMS).
But in the new world of facets 3.x it does not at all seem right to call it a bug.
Also meant to report that the simplest possible (hard-coded) intervention, adding into :
$urls[] = Url::fromUri('internal:/projects');
$pretty_facets_exposed_filters_views[] = 'projects';
And then in the foreach loop of $urls starting around line 90 lying and saying:
$sourceRoute->setDefault('view_id', 'projects');
gets the $sourceRoute->setDefault('_controller', 'Drupal\\facets_pretty_paths\\Routing\\ViewPageController::handle'); line to be called, but that does not by itself do it, a facets path such as /projects/services/research-publishing still gets 404 not found.
Sorry, that probably is the same exact pattern. Not sure why i did not see it. (Except that i was moving on directly to ✨ Make compatible with Facets Pretty Paths Active )
As zooney's code analysys reports, if you delete the page display, the embed display works as expected (for those of us in this issue).
I think this means it should be fairly trivial codewise to make a configuration option in the embed (or block) view display to not look for the page display, even if it is there. (As zooney also suggested.)
In our case deleting the page display is desirable/fine, so i won't be pursuing this further, but i do feel strongly this counts as a bug— especially for the embed view display; block displays going to the page have more history. But the precursors to Views in core with an embed display clearly expected filters to stay on the embedded page → .
Giving it a few days for people running on dev (like myself) to test it and will make a release.
OK figure and main got left out of the "non-compiled" js/ckeditor5_plugins/linebreaks/src/linebreaksfilter.js and for some reason my diffr was showing irrelevant things too and making that harder to find. Adding both and regenerating the built JS.
Great, thanks!
The configuration change for webpack is committed to dev; running npm build to make the minified file was already giving unexpected results (before bringing this in) for 🐛 Empty paragraphs inserted into and before div-like elements. Active so a release that gets rid of the console logging is delayed (still more; sorry for not getting to this).
This looks good and i've merged it into 2.0.x.
I'm going to test whether it fixes a problem in which vertical spaces around images or otherwise in text are auto-added by CKEditor5.
I hope others also have a chance to review before we tag a release.
Thank you jacobupal and apologies for the slow response here!
Like it would be great to somehow use https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Htmx%21Ht... to add to the <body> tag whenever the htmx_preload/preload library is loaded on the page.
This is working— definitely needs documentation, and i was wondering if it is feasible to place hx-ext="preload" into the body tag, since it is annoying to have to add that to something outside of / before the data-hx-get="…" preload tag/line.
Would be great to have a little feedback now, including if the documentation should go in a help topic.
Is this documented at all? These notes suggest SDC Display Preprocess for this but it seems it should not be necessary, but the lack of examples where contextual links are taken care of makes me wonder.
(attributes is not enough; it needs at least title_suffix to get in there also.)
Should not be anything blocking this, Webform has had stable releases for Drupal 11 for a while and the testing incompatibility with Drupal 11.x core (would not be in an official release until Drupal 11.3 anyway) has been fixed 📌 LogicException: The hook update_dependencies does not support attributes Active as luke.stewart noted above.
I'd offer to help with maintaining ( five RTBC issues → plus this D11-compatibility release) but its not clear to me how things are managed over in GitHub. My understanding is there is no chance in bringing it over to Drupal.org's GitLab because the testing suite is set up over on GitHub. But i have not even figured out how to actually get the test suite to run?
For example 🐛 Existing Contact - Autocomplete search broken if Contact ID plus other Contact Display Fields are selected RTBC is marked RTBC and is has no conflicts here: https://github.com/colemanw/webform_civicrm/pull/923
But it has no tests run.
Unlike #3550084: Uploads duplicate files in Multistep form → (just marked this RTBC myself) which does: https://github.com/colemanw/webform_civicrm/pull/1076
I feel i could be a little bit useful kicking off tests, making sure d.o issues and GitHub PRs are synchronized, plus testing locally— but i don't see how to kick off tests on GitHub!
But as far as this issue, that recent issue where tests are running indicates "Integration Tests / Drupal 11.x-dev | CiviCRM dev-master (pull_request) Successful in 65m" so nothing should be holding up making a D11 release, or at least … pushing the GitHub code to Drupal so the dev branch is D11 compatible?
Passing tests in the PR: https://github.com/colemanw/webform_civicrm/pull/1076
Just noting as this issue gets fixed that there is one more permutation of the basic problem:
- Get the link text from the title of the entity being linked to.
- When the entity's title changes, update the text of the link to match the title.
… and coincidentally there is now a module for that: Autoupdate Link Text → .
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