Ajax error ajax.$form.ajaxSubmit() is not a function

On a new D9.5.x site with a Radix 5.0.8 backed sub-theme, and Bootstrap Layout Builder module.

For me, the error alert comes up after I attempt to edit a block in a layout; so, previous attempts to add blocks work. Have not attempted to reproduce this in a vanilla Drupal instance.

Patch #12 addresses the error from Layout Builder off canvas Block editing.

This fix looks appropriate as it applies the fix to the common drupal.ajax library dependency.

The last submitted patch, 12: drupal-ajax-error-2755791-12.patch, failed testing. View results →

core/jquery.form has been deprecated. For long term maintainability, this patch would likely need to be updated.

Good catch. To recap what they did, to maintain compatibility, core added an internal.jquery.form library, a duplicate of jquery.form, and updated its usage throughout core.

Additionally, 00991b9 says not to add new usage to core:

# Internal library. Do not depend on it outside core nor add new core usage.

Active support for 9.5.x ended June 21, 2023, so this is not likely to be adopted since it is not a security issue.

Unless someone agrees this should be changed and re-rolls a patch using internal.jquery.form, this can be closed (won't fix). Any Drupal 9 developers wishing to use the patch #12 supplied may do so until they upgrade to Drupal 10.

However, I am curious to know if this issue exists in Drupal 10. Note: Drupal 10 still uses this library.

If it does, then this simple fix with internal.jquery.form would be appropriate, except for the directive not to add new core usage.

Otherwise, a non-jquery fix would be necessary.

Can someone confirm whether this issue occurs in Drupal 10?

I encountered the same error while updating to d10.1.1. I have a custom form that includes a select field with an "#ajax" key and a "change" event. When I attempt to change the select value on the page that contains the form, I receive an error as mentioned in the issue description: ajax.$form.ajaxSubmit is not a function. As a result, I had to write a patch for internal.jquery.form.

I attempted to load the library through a custom module and even tried altering the weight to load the library earlier, but neither approach was successful. Would anyone be willing to try and provide a comprehensive fix?

Re-roll

This error also occurs in Drupal 10.1.2 when trying to delete a menu link:

An error occurred while attempting to process /admin/structure/menu/item/#/delete?destination=/admin/structure/menu/manage/main&_wrapper_format=drupal_ajax: ajax.$form.ajaxSubmit is not a function. (In 'ajax.$form.ajaxSubmit(ajax.options)', 'ajax.$form.ajaxSubmit' is undefined)

This issue still occurs in latest 10.2.x version. But the patch from #19 doesn't fix it.

To reproduce this issue, Install Stripe → Module and enable its submodule stripe_examples and navigate to https://d10.local/stripe_examples/form/simple_checkout after adding stripe test API keys at https://d10.local/admin/config/stripe and try to submit the form. You will be getting this error.

Issue summary should follow standard template. Have added it but TBD sections will have to be filled out.

Also having this issue in version 10.1.8 when trying to add a handler to a webform. I applied the patch from #19 but am still getting the ajax error. Do I need to do something to make the patched file load?

Are steps to reproduce still needed? In Webform (on Drupal 10.1.8), these steps do it for me:

1. Install webform module and add a test form
2. Go to admin/structure/webform/manage//handlers
3. Click "+ Add handler" button.
4. Choose any handler, e.g. Action or Remote post, and click the "Add handler" button @ right
5. Put any values in, and click "Save" at the bottom of the dialog.
6. See the Ajax error.

Re #28 Adding any elements to a form also gives the same error.

Steps:

1. Install webform module and add a new form.
2. Click the "+ Add element" button.
3. Pick an element type, and fill in the form to create a new element.
4. Click the "Save" button.

I will add this to the issue itself.

The patch in #24 works for me, after clearing all the caches.

In \Drupal\Core\Render\Element\RenderElement::preRenderAjaxForm() we do:

      $element['#attached']['library'][] = 'core/internal.jquery.form';
      $element['#attached']['library'][] = 'core/drupal.ajax';

So one question I have is how are we rendering a form and added stuff that causes an ajax submit without hitting this code?

Also if we are going to add the dependency to core/drupal.ajax then we should remove it from the views library dependencies (after checking that it is not directly used) and RenderElement::preRenderAjaxForm()

I have a Drupal 9.5.11 installation, and I've developed a custom module with a form that utilizes the '#ajax' property. While it works in Chrome, it doesn't function properly in Firefox and Edge. I resolved the issue by adding 'core/drupal.ajax' to the dependencies in my (custom theme) theme.libraries.yml file.

I'm getting sporadic reports from a customer of this error on a hosted site with a webform using a file upload field, but can't reproduce the error myself, either locally or in production. Can others provide information about:

• Do the errors happen in all browsers?
• Are you logged in or not? Do the errors happen for anonymous users?
• What AJAX settings are enabled in the webform?
• Is the site local or hosted? If hosted, which provider?
• Is JavaScript aggregation enabled?
• Is a CDN in front of the site? If so, which one and are there special caching rules in place?

hi in drupal 10.3.1 this patch solve my problem.
#36

thank you.

#36 is identical to the MR 6052 https://git.drupalcode.org/project/drupal/-/merge_requests/6052.patch

MR 6052 is identical to patch #18 which is what all these latest ones are based on.

to pin on the MR commit you could specify the hashtag as follows:

https://git.drupalcode.org/project/drupal/-/commit/c2b4fd62.patch

Or use the diff instead.
https://git.drupalcode.org/project/drupal/-/commit/c2b4fd62.diff

Still encountering this problem after upgrade to 10.3.3.

What are the steps after updating core/core.libraries.xml?

Attempting to use simple-oath to generate keys - uses an ajax call.

Thanks.
==============
ajaxTrustedUrl: {}
dependencies:
- core/jquery
- core/internal.jquery.form
- core/drupal
- core/drupalSettings
- core/drupal.progress
- core/once
- core/tabbable
- core/loadjs
- core/drupal.message

#36 fixed the issue for me in Drupal 10.3.6

Re #33 🐛 Ajax error ajax.$form.ajaxSubmit() is not a function RTBC :

@alexpott I was debugging this because of 🐛 Create a new blog post JS error Active which was thought to be caused by autosave_form. From my observations the attach behaviors (including the ones from <code>ajax.js and autosave_form.js) are executed before the $.fn.ajaxSubmit function is being initialized / set by jquery.form.js.

However as suggested in the issue I add core/internal.jquery.form as a dependency to drupal.ajax then first the $.fn.ajaxSubmit function is being initialized and then the Drupal attach behaviors called.

This indicates that there is difference in how stuff called and

$element['#attached']['library'][] = 'core/internal.jquery.form';
$element['#attached']['library'][] = 'core/drupal.ajax';

is not equal to declaring core/internal.jquery.form as a dependency to drupal.ajax.

I was able to achieve the behavior of initalizing the function without declaring an explicit dependency but just by setting a similar weight to the jquery.form.js file as to the jquery.min.js and now the function is initialized before the attach behaviors are called.

Attaching a patch for that as I think this is the less intrusive change and would not load the core/internal.jquery.form when it is actually not needed.

If we want to still add a test for this then it might have an ajax behavior that checks the ajaxSubmit function being already registered when it is called. Without this patch the test will be failing. Someone wants to write it? :)

Fixes should be in MRs to see tests run.

If you are another contributor eager to jump in, please allow the previous poster at least 48 hours to respond to feedback first, so they have the opportunity to finish what they started!