There is no hx-set-title so what is our approach here?
As far as what the HTMX module provides (this part is not going in Drupal core i presume), having HTMX Entity View defaulting to a <title> of the entity's label would meat the 80% use case.
Updated commits further fix it— robust but undeniably hacky. Still no idea why this site is not like other sites.
After recent updates to Drupal core, the patch here no longer applies, and getting this error:
Error: Typed property Drupal\path\Plugin\Field\FieldType\PathItem::$alias must not be accessed before initialization in Drupal\path\Plugin\Field\FieldWidget\PathWidget->formElement() (line 29 of core/modules/path/src/Plugin/Field/FieldWidget/PathWidget.php).
Drupal\Core\Field\WidgetBase->formSingleElement() (Line: 222)
Drupal\Core\Field\WidgetBase->formMultipleElements() (Line: 120)
Drupal\Core\Field\WidgetBase->form() (Line: 197)
Drupal\Core\Entity\Entity\EntityFormDisplay->buildForm() (Line: 121)
Drupal\Core\Entity\ContentEntityForm->form() (Line: 138)
Drupal\node\Form\NodeForm->form() (Line: 107)
Drupal\Core\Entity\EntityForm->buildForm()
call_user_func_array() (Line: 528)
Drupal\Core\Form\FormBuilder->retrieveForm() (Line: 279)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 622)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 183)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 53)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 124)
Drupal\cloudflare\CloudFlareMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 715)
Drupal\Core\DrupalKernel->handle() (Line: 19)
Guess we should open this up for anybody to work on but pancho you are more than welcome to take it back; your progress here was awesome.
The way it is working now, if a PDF has five fields with the same key, and you come along and map a token for the first one, nothing works because the later empty, tokenless PDF keys seem to take priority.
Was coming to file an issue about mitigating this, somehow not showing duplicate-key fields in the view that lists fields and then only looking at that first one for filling, but this approach of using PDF Key as the key for each field FillPDF keeps track of is much better than any after-the-fact bolting on.
As has been noted Drupal 7 did this, and in particular dealt with case sensitivity by making the key column BINARY, #3053622: Case-insensitive unique index on pdf_key breaks parsing →
Thank you! Still feels there must be a step or an explanation missing…
- The token is automatically generated and used by Siteimprove.ai to authenticate your subscription.
- Is the token then copied and pasted into the Siteimprove website somewhere?
- Or does a person have to be logged into Siteimprove while visiting this Drupal settings page?
We are already logging an unexpected-ish state (falsy value for a given transition ID in $transition_data) and know there is at least some transition data. We can prevent this warning and if no one else has run into it figure it is rare enough that when anybody cares enough this existing log message will help the debugging.
It is in the commit of course but here is the removed code, for use in a custom module or to be reintroduced as a submodule here, to use state information in a template per the above:
/**
* Implements hook_preprocess_node().
*
* Expose the current revision state and latest revision state to templates.
*
* This should probably be moved to a different helper module, or maybe core.
*
* Taken initially from Kay Beissert's solution here:
* https://www.drupal.org/forum/support/theme-development/2018-04-20/how-can-i-get-the-content_moderation_state-of-last#comment-12603894
*/
function workflow_buttons_preprocess_node(&$variables) {
// Note: Access key booleans in Twig node templates like this:
// node.isDefaultRevision()
// node.isLatestRevision()
$variables['latest_revision_state'] = '';
$variables['current_revision_state'] = '';
$node = $variables['node'];
// $was_default_revision = $node->wasDefaultRevision();
$variables['current_revision_state'] = _workflow_buttons_safe_get_moderation_state($node);
// If we are viewing the default revision and *not* the latest revision, then
// we will want to load the latest revision.
if ($node->isDefaultRevision() && !$node->isLatestRevision()) {
// $loaded_revision_id = $node->getLoadedRevisionId();
// Above appears to always match below.
$current_revision_id = $node->getRevisionId();
// Get all of the revision ids.
/** @var \Drupal\node\NodeStorage $node_storage */
$node_storage = \Drupal::entityTypeManager()->getStorage('node');
$revision_ids = $node_storage->revisionIds($variables['node']);
// Check if the last item in the revisions is the loaded one.
$last_revision_id = end($revision_ids);
if ($current_revision_id != $last_revision_id) {
// Load the latest revision, so we can reference it's state.
$last_revision = $node_storage->loadRevision($last_revision_id);
// Get the revision's moderation state.
$variables['latest_revision_state'] = _workflow_buttons_safe_get_moderation_state($last_revision);
}
}
}
/**
* Get the moderation state as a string.
*/
function _workflow_buttons_safe_get_moderation_state($node) {
if ($node->hasField('moderation_state')) {
return $node->get('moderation_state')->getString();
}
}
Looks good! Like discussed in person maybe some of these could also be readonly.
Not sure this is within scope but i think where we frequently see the message out of place is with rabbit-holed content that is referenced by non-rabbit-hole content.
3.0.x branch is the first steps toward a failed (for now) effort to rebuild on Commerce and Webform.
The continuation of the working 2.0.x branch (from where a new major version should have been made before the disruptive changes started, but it's too late to do that) is in the 4.0.x branch.
Oh and unfortunately documentation for FAPI seems to have largely moved out of the codebase and the generated table of D7 days that remains the most useful reference and into the Drupal Wiki → , in particular Form Render Elements → which does link to in-code documentation sometimes including for Form States API. Maybe this would make sense there?
The current merge request fixes this and has a test. I agree with darthsteven that the bug needs to be fixed first and then the API addition can be worked on in a new issue with the tests already in place to prevent another regression.
Respectfully boosting to major as this is a significant regression and it can hit key workflows and – how do the marketers call it? – success journeys like checkout or donations, with the result that key information and functionality shows up when it should not— or does not show up at all.
(And i think these words are all in here already but i still needed StackExchange to surface this issue for me, so to repeat the common representation of the issue: drupal form #type item not working with #states API.)
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.