@geek-merlin I discovered the same issue (
https://www.drupal.org/project/drupal/issues/3530032
🐛
ignore_missing argument in include still logs error
Active
)
Your solution also fixes the issue.
kensae → created an issue.
@mradcliffe I've made some changes, based on your remarks.
Feel free to let me know whether you agree or not.
@jonathanshaw I've created a separate issue for case insensitive matching: https://www.drupal.org/project/xero/issues/3538748 ✨ Case sensitive / case insensitive matching in autocomplete Active
Does the default content approach also applies when we want to create an override for module provided menu links?
We use the core Navigation module and the contributed Masquerade module and would like to move the unmasquerade link from the user menu to the naviagtion-user-links menu.
definitions:
masquerade__unmasquerade:
menu_name: navigation-user-links
parent: ''
weight: -50
expanded: false
enabled: true
We've integrated the 'stripe_payment' form element in a custom module.
I can confirm it works as expected.
- We've used the last version of the branch stripe-3316114
- We've created a custom form in a custom module with the stripe_payment element type.
// Load the payment intent from the form state. $payment_intent = $form_state->getValue(['payment', 'payment_intent']) ?? []; $payment_intent['description'] = $payment['description']; $payment_intent['metadata']['reference'] = $payment['reference']; $payment_intent['automatic_payment_methods'] = ['enabled' => true]; $form['payment'] = [ '#type' => 'stripe_payment', '#stripe_amount' => round($payment['amount']) * 100, '#stripe_currency' => 'EUR', '#stripe_country' => $payment['billingAddress']['country'], '#stripe_paymentintent_unique' => TRUE, '#stripe_paymentintent' => $payment_intent, '#required' => TRUE, ];
- Enabled Card, Bancontact and Paypal as a payment methods in Stripe Sandbox Dashboard
- It shows the following form element:
- The card payment is handled onsite, and returns to a confirmation page, we redirect to in the form submit handler
- Bancontact and Paypal are handled offsite, and redirect to /stripe/checkout afterwards
@n1k I noticed the same issue, the commit in #32 should resolve your issue.
kensae → created an issue.
Create a patch file from the latest MR
Feel free to update the MR if another approach is preferred.
I've commited a proposition in the issue branch.
I've noticed a small issue using drupal 11.1.7, Gin 4.0.x-dev and the patch from MR589. There is no right-padding in the top bar which causes the local actions being pushed to the edge of the browser.
It seems this can be solved with a max-width: 100% on the top-bar class.
kensae → created an issue.
I'm sorry for spamming this issue queue. I've made some modifications to the patch for 2.0.0-alpha2 to make sure it provides the same functionality as the merge request does.
Just another patch to fix the exception: TypeError: Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher::dispatch(): Argument #1 ($event) must be of type object, string given
In #16 I accidentally left out the GiftcardActivatedEvent class so I've re-uploaded the patch in #17
We encountered the same issue and solved by adding the --uri paramter to the drush command.
So instead of running
drush filefield-to-media:copy upload upload_media document field_media_document node
run
drush filefield-to-media:copy upload upload_media document field_media_document node --uri=https://www.yoursite.com/
Maybe this should be added to the readme of this module.
I've also created a patch that works for version 2.0.0-alpha2
I've moved the patch from #15 into a merge request. I've tested it myself on a project we're working on and it works.
I've moved the patch of #34 into the MR, because this was the last patch that worked for me.
And made some minor modifications to move events in the correct order.
It uses the default consent mode form google tag module if consent mode is enabled and reorders de dataLayers to execute the default consent mode and the consent mode update from this module, before the container initialization and other google tag events.
kensae → created an issue. See original summary → .
I've created a 2.0.x branch but this branch needs testing
I've fixed some merge conflicts.
To update this, we 'll need fixes to the issue
https://www.drupal.org/project/commerce_giftcard/issues/3181301
✨
Need to activate (Status enable) a gift card only when the payment is confirmed
Needs review
to make sure the GiftcardActivatedEvent is available in the 2.x branch of the Commerce Giftcard module.
The Merge request is currently failing for that branch, so I'll have a look into that first.
I've added onInit, onAccept and onDecline options to the Klaro App entity and I've updated the form in MR!79
I think the main problem of this issues is fixed in https://www.drupal.org/node/3227250 → ?
Thanks for merging!
I think I'm done with my changes.
If I encounter any issues I'll open a new one in the issue queue.
I made some small changes to the if statements to check if a value exists in the form_state input / values array on the given key
I was not able to update to beta4 in Drupal 11 because of the webform_options_limit dependency in info.yml
When I try to update I get the following error:
I have webform 6.3-beta installed with it's webform_options_limit submodule.
I thought adding a composer.json would solve this issue.
When I pull this issue branch with the composer.json included, I don't get this composer errors
MR18 in this issue branch covers the existing functionality of the Invite module for both Drupal 10 & 11.
I'm sorry for replying this late. It seems good implementation. I'll test it right away.
I can confirm the the fix in the issue sukr_s has referred to, solves it for me.
In my case I had a couple of fields that were filled based on the value of another field after an ajax callback.
Based on the fact if these fields have a value, the submit button's disable attribute would change from disable to enabled state.
Before the patch, the submit button keeps the disabled state, even if all fields have a value.
After patching drupal core 10.4 with the patch from the MR from issue
#2468860
🐛
Form field #states not woring with entity reference fields
Active
, the submit button gets enabled after all fields are filled out.
I've tested the change myself with a website of one of our clients.
It's running in production for two weeks now.
I modified the MR to solve the issue I mentioned about the possibility to select a an option that's greather than the remaining number.
I've tested the MR with both the Number Limit handler and the Options/Checkbox with number limit handler
The Number Limit handler works as expected!
On the Options/Checkbox with number limit handler there 's a little bug that allows you to select more places then available.
I think it's something ajax related. I'll check if I can find more details why it's failing.
Ok fine, if that's ok I'll work on the issue branch in this issue?
Then I still think we're talking about a different use-case.
In my case I don't want to set the a limit per option, but the selected option (1,2,3,4) is added to the number of allowed subsciptions, as would a number field in the NumberLimitHandler.
If I have f.e. an event with a maximum of 20 seats, and each registrant can reserve 1-4 seats (select field) then:
- I can have 5 registrants (form submissions) who select each 4 seats
- 10 registrants who select each 2 seats
- 3 registrants who select 4 seats and 2 registrants who select 3 seats and 2 registrants who select 1 seat
- ... and various other combinations.
I'm sorry if I'm wrong but I don't think I can accomplish this in
Yes, I did read your last comment, but I'm not sure how I would accomplish this with the following settings.
Maybe I'm missing something.
I'm sorry for replying this late.
What I'm actually trying to accomplish is for example a registration form where visitor can register a number of attendees for an event. The field to indicate the number of attendees would be a select field.
In this case I would use a select field with the options 1,2,3,4 and the NumberLimitWebformHandler.
So instead of a webform element Number, I would like to use a select element just to enter a number.
Would you mind I reopen this issue for this specific case?
Probably I'll have to extend the patch and check if the select only contains numeric options before it is marked as a valid field instance to use in the NumberLimitWebformHandler.
tostinni, the removed lines in the patch are moved to seperate function handleCustomFields.
I think it's just a matter of updating the requirement in the composer.json file to:
"dompdf/dompdf": "^1.0 | ^2.0 | ^3.0"