- Issue created by @greatmatter
- πΊπΈUnited States greatmatter
An update: the payment is not being stored, and the browser is receiving an error:
"Oops, something went wrong. Check your browser's developer console for more details."The console:
"Failed to load resource: the server responded with a status of 500 ()"
and
Drupal.AjaxErrorThis is no corresponding error message in watchdog, despite this being a 500 error.
The server log is showing an "out of memory" error, with 256MB allocated via php.ini.
- πΈπΎSyria hodba Dubai
Thanks for reporting this. Can you share some more details about the scenario, webform configurations, other details of your Drupal setup?
I am using the module in multiple websites and never had such an issue. - πΊπΈUnited States greatmatter
Of course. Here's the form:
https://sanmarinomotorclassic.com/vehicle-applicationThe payment is on the second page.
Regarding Drupal: Latest (10.2.4), Webform is latest stable.
Note that this hasn't happened again since 2024-02-27 - so maybe it was temporary? I wish I had more to give you.
- πΊπΈUnited States jackfoust
I've found that the element on a second page does not appear to work at all. No errors that I can see, just goes back to the first page with your information intact. Drupal 10.2.4 and Webform 6.2.2.
- πΊπΈUnited States jackfoust
So, after some testing it does seem to work with AJAX enabled.
- πΊπΈUnited States jackfoust
I've done some further testing and found... With AJAX enabled - you can submit the form, but you cannot use the previous button to go back to the first page since it is requiring the payment information to be completed. With AJAX disabled you can go back to the previous page to update data, but you cannot submit the form.
- πΊπΈUnited States greatmatter
Hrm--I wonder if the issues are related. (I did have AJAX enabled on my form)
- ππΊHungary dr. gubΓ³
We have a few submissions with the same problem, that the payment got through but no form submission was registered. These happened on a form that used cards.
After removing all cards elements from the form and making it just a regular form with no going back and forth through pages, and doing a few rounds of manual testing, here's what I found.
With AJAX disabled for the webform
- filled out some details, but left some required fields empty
- entered my (test) card details and clicked the submitt button
- the title of the submit button changed to "Processing payment" and the button became disabled, but the form wasn't submitted, and threw me the (inline) form errors for the missing required fields
- at this point, the card payment has gone through, I can see it as completed on the Stripe dashboard
- the submit button text is still "Processing payment" and the button is still disabled, so I'm not able to actually submit the form
- in the end I have a successful payment without a corresponding form submission
Same form and test process with AJAX enabled
- on the first submit with missing required fields but filled out card details, no actual payment happens
- until I have missing required fields, the submit button title doesn't change to "Processing payment" on submit attempt even if card details are already entered, and I get the error messages for the missing fields
- BUT the page doesn't scroll back up to the first missing field, which it does when I submit with AJAX disabled. I think this would be crucial because otherwise the visitor has no feedback about what's wrong, they only see that the submit button at the end of the form does nothing.
- still, after modifying form values (filling out missing fields) I can submit the form, and the button title changes to "Processing payment"
- payment goes through, I'm redirected to the confirmation page, all good
So it looks like AJAX has to be enabled for proper functionality, but enabling AJAX comes with the serious downside of preventing scrollback to the missing required fields.
Hope this helps in tracking the problem down.
- πΊπΈUnited States greatmatter
We enabled the "Allow your users to save and finish the webform later" and "Automatically save as draft when paging, previewing, and when there are validation errors" to help track issues, but honestly, we still can't seem to replicate the issue consistently.