🇧🇪Belgium @kensae

kensae → created an issue. See original summary → .

kensae → created an issue.

I've updated the MR

It seems to be an issue in \Drupal\xero\TypedData\Definition\ItemDefiniton, where the class DataDefinition for

$info['PurchaseDetails'] = DataDefinition::create('xero_detail')->setLabel('Purchase Details');
$info['SalesDetails'] = DataDefinition::create('xero_detail')->setLabel('Sales Details');

should be:

$info['PurchaseDetails'] = DetailDefinition::create('xero_detail')->setLabel('Purchase Details');
$info['SalesDetails'] = DetailDefinition::create('xero_detail')->setLabel('Sales Details');

In my case, this error is happening when trying to add a Xero Reference with the xero autocomplete widget to a Xero Item. It fails when trying to getProperties on the xero Detail Datatype.

@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.

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.

kensae → created an issue.

kensae → created an issue.

@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

kensae → created an issue.

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.

1. We've used the last version of the branch stripe-3316114
2. 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,
          ];
      

3. Enabled Card, Bancontact and Paypal as a payment methods in Stripe Sandbox Dashboard
4. It shows the following form element:
   
5. The card payment is handled onsite, and returns to a confirmation page, we redirect to in the form submit handler
6. 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 → made their first commit to this issue’s fork.

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.

kensae → created an issue.

kensae → created an issue.

kensae → created an issue.

kensae → created an issue.

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.

kensae → made their first commit to this issue’s fork.

kensae → created an issue.

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 → made their first commit to this issue’s fork.

kensae → made their first commit to this issue’s fork.

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

kensae → made their first commit to this issue’s fork.

kensae → made their first commit to this issue’s fork.

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

kensae → created an issue.

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.