Uncaught ajax.js error / exception

The steps to reproduce seem like ordinary actions so there must be more steps to reproduce the error condition.

Is there more information about what happened in the PHP error logs?

I have the same problem after 10.2.0.
After submitting every ajax form sends an error to the developver console.
I deactivated almost every non core module but the error still appears.

same here after update to 10.2.0

I've looked at your issue and I think I encountered a similar error using Layout Builder. I identified what's happening in my instance so I will comment here in case this helps. I am unsure where this error originates.

What happened in my existing site:

1. Using Layout Builder in 10.2.0. Try to add block to existing layout. Console error. Uncaught AjaxError. No Watchdog errors. This is because the Return status is 200 so the response is generated on Drupal without errors. So I investigate web/core/misc/ajax.js library to see what's going on.
2. Trace things to object ajax.options.complete function (line 611) check to see what type of error it is. I find it's a 'parsererror'. So jQuery is unable to parse the JSON response.
3. Inspect the Response from Drupal/server. Notice that the JSON is malformed. In fact you can see this in your ResponseText object in the code you pasted in the issue. The JSON array opens with a '[' and there is no closing ']'.
4. At this point I try to trace the problem to Drupal. Check out Symfony\Component\HttpFoundation\JsonResponse::setData() and attempt to see why it's being malformed. However I find no errors in the generated JSON text. JSON response is leaving this function differently than it arrives to the browser.
5. I don't try to trace this anymore. Backtrack to ajax.js and process responses as 'text' (instead of 'json') and check for this particular error.

That's all the time I've spent on this problem. If you believe my problem is similar to yours perhaps this patch workaround for 10.2.0 will alleviate the current issue. It doesn't fix the root of the problem which is why does ResponseText JSON reach the client without the closing bracket ']'.

I will note that I didn't encounter this problem on a new Drupal 10.2.0 site using standard profile and layout builder. I didn't encounter this issue in 10.1.7. Only after my upgrade to 10.2.0 did it appear. Downgrading from 10.2.0 to 10.1.7 appeared to help.

Contextual links (/contextual/render) were also affected by this problem. That feature sends an application/json response which was missing the final "}" character. So I'm beginning to believe this isn't strictly a problem with the ajax.module.

Further investigation into this issue.

As I mentioned in comment #10 I didn't encounter this problem in 10.1.7. I was able to downgrade my site and LayoutBuilder Ajax worked properly again. The JSON content response was formed correctly in 10.1.7.

I began experimenting with sending Content-Length header, which I noticed was missing from the Ajax responses. I found that the Content-Length didn't appear on my malformed application/json responses despite trying to add it in 10.2.0 site. Then I added the content header to my 10.1.7 site before Response::send() and I discovered the response was malformed! So I determined that setting Content-Length for certain applicaton/json responses appears to cause the issue where the JSON content arrives malformed to the browser/client.

I've attached another patch for testing. It doesn't address the root cause and is a naive attempt at removing Content-Length from the AjaxResponse class, no others. You'll either want to adjust or remove the condition if you need to target other types of Responses. However I hope this is starting to illuminate the underlying Drupal issue.

Next step will be to determine if somewhere between Drupal 10.1.7 and 10.2.0 a "Content-Length" was appended to this type of response when it wasn't previously.

@ikphilip that's good investigation, and means this issue is likely a duplicate of #3396559: Only set content-length header in specific situations - could you try the MR from there?

I have a commerce add to cart form that fails like this. The MR in #3396559: Only set content-length header in specific situations does not solve the issue, I guess because the AJAX response has a 200 status for which Content-Length is still added after applying the MR.

I just tested the MR in #3396559: Only set content-length header in specific situations and it did not work for me. My site's failing AJAX responses are 200 and therefore deserving of a Content-Length header.

What I noticed is that my Content-Length byte count appears to be off by 1. If I modify this line in FinishResponseSubscriber.php the responses begin to work. Something like

$response->headers->set('Content-Length', mb_strlen($content) + 1, TRUE);

Because I'm unable to replicate this problem on a fresh install of 10.2.0 I'm beginning to wonder if there is something the matter with specific data from the site's content.

In 10.1.x this function does not exist which is why I can rollback to that version and my Layout Builder and quickedit.attachments Ajax work again.

So for me adding +1 to the byte length helps. This is likely why in the browser/curl/client the response appears truncated. But why is strlen() failing?

In my case it turned out to be extra white space in front of a <?php tag. I used the regexp \s+<\?php to find such occurences in my codebase.

@ikphilip Looks like you have a similar issue.

I'm experiencing a similar issue after upgrading to D10.2.0 where I get the Ajax-error in the browser-console.

No problems locally though where this is the setup:

• MAMP Pro,
• PHP 8.2.0 (also tried 8.1.13 - no problems)
• Apache/2.4.54 (Unix)
• MacOs 14.1.1

But on prod (on a subdomain) I get the error when trying to:
- Add an image via Media library
- Add media in a node.
- Edit Paragraphs in a node
- Filter Views in frontend (also when logged out)

Ajax seems to be down all the way around.

The set up is like this:

• Apache/2.4.29 (Ubuntu)
• PHP 8.1.26

I tried turning off cache and aggregation, as well as Big Pibe.
I also checked for spaces infront of <?php
Tried in Chrome,Firefox,Edge and Safari.

UPDATE: The patch in #10 made things work for me again

Checking for extra spaces in the the file is a good idea, thank you @czigor. I've checked for the existence of spaces before my opening PHP tags. No luck finding a culprit file...

I think the simplest work-around until the source of the issue is identified is to disable Content-Length header via patch on a site-by-site basis with something akin to my example patch in #11. Should I find anything related I'll report it here.

#3410022: Regression from #3295790 content-length header set earlier than expected could be another cause here.

I experienced another symptom of the problem when synchronizing configuration - the patch in #10 IS put on and fixes my initial problems, but not this one.

When I click import the sync progress bar appears and after a little while I get the "Oops, something went wrong etc." and the following in a message above (but the synchronization has been completed correctly though):

An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /batch?id=9&op=do_nojs&op=do
StatusText: parsererror
ResponseText: {"status":true,"percentage":"75","message":"Completed step 3 of 4.","label":""

@William H. Olesen could you try applying the diff from #3410022: Regression from #3295790 content-length header set earlier than expected ?

@William H. Olesen as the author of the patch in comment #10 I don't recommend you rely on it. Notice that the patch only checks for unclosed JSON arrays "[]" not objects "{}" and as a result your ResponseText in #19 won't be fixed.

You could probably modify Patch #10 to check for unclosed JSON objects, if you wish. Since the problem is server-side with the Content-Length I don't believe a patch like #10 is appropriate. Consider #11 or a similar patch to unset Content-Length from the AjaxResponse for the time being since it wasn't set in http responses prior to version 10.2.0.

As for me, no luck with 10.2.x patch from https://www.drupal.org/project/drupal/issues/3410022. My goal is to review the impact of various contrib modules to see if there is something akin to the solution in #15 but I've nothing to report yet. Since I can't replicate this in a fresh install of Drupal I'm wondering if it's something from contrib.

@catch I'm a simple site builder and on pretty deep water here, so I'm not quite sure what you mean - I'll be happy to try if you can explain.

@ikphilip Thanks for the heads up - it allowed for editors to continue throwing in content before launch of the site, so as a temporary solution it did the job - I'll try to avoid putting it on live prod ;)

I just installed Drupal 10.1.2 where "#3410022: Regression from #3295790 content-length header set earlier than expected" was said to be fixed, but the issues I have persist if I don't use Patch #10.

I'm having this issue in a new installation of Drupal.

1 drush si
2 Try opening Announcements

I tracked the response body while calculating the content length, the response body is valid.
If assume that the length calculated is incorrect and add +1 this will solve the issue.

Drupal\Core\StackMiddleware\ContentLength:
$response->headers->set('Content-Length', strlen($content) + 1, TRUE);

I have no idea where to look for the bug next )

I wonder if you have a space before an opening PHP tag somewhere

I checked the only file I created settings.php without a space.
I also deleted the installation and reinstalled it and now I can’t get this bug again.

In any case, I now think this is not connected with drupal, but with the IDE (PHPStorm) or the environment

Thanks for the advice.
In my case it was a whitespace in the bat module.

@sunfire-design is there an issue against the bat module for the extra whitespace?

I wonder whether phpcs picks this up already and those modules don't have gitlab pipelines enabled, or if we're missing a rule somewhere.

I've finally resolved my site's issue. I found a new line before the open PHP tag in a module...my own custom module! \n<\?php was a more helpful regular expression to discover the problem in my code. Thanks for the suggestions to look around for these instances.

That looks good.

A slight adjustment to \n+<\?php will match in cases where there is more than one new line.

@catch i created an issue report. The whitespace is only in the 2.1 branch.

On Drupal 10.2.1, patch on #10 works for me, patch #11 doesn't apply and patch #14 breaks my site.

If I take the code from #11 and manually apply it ,it fixes ajax issue but quick edit issue is still there.
I have reported this issue here. I am facing ajax as well as contextual links not appearing issue.
https://www.drupal.org/project/drupal/issues/3414753

Also how to apply this patch using composer.json?

 "patches": {
          "drupal/http-foundation": {
            "Ajax issue": "https://www.drupal.org/files/issues/2023-12-23/symfony_http-foundation_unset-content-length.patch"
          }
        },

I've created 2 more patches for Drupal for users who are having issues with Content-Length headers in Drupal responses in 10.2. These patches disable setting the header so that the responses resemble those from prior versions (<10.2). I discourage the usage of my patches #10, #11, #14 as they existed to fix a specific response and to illustrate the problem I was facing.

In 10.2.0 Content-Length response header was introduced and set in FinishResponseSubscriber.php. In 10.2.1 the logic was moved to a StackMiddleware class ContentLength which is enabled in core.services.yml. You must use the appropriate patch for your current version.

I do recommend checking to see if there is extra spacing anywhere before the opening PHP tag <?php as that appears to be the problem for many of us. However I understand that combing a codebase can take time and it took me some time to identify the problem file so these patches can help until the problem is identified.

I used the 10.2.1 patch on 10.2.2, and it worked. It seems impractical to worry about spaces before an opening php tag, given how many of the vendor files contain these. Also, this was only an issue on my local Lando, not on my production servers.

What helped on my end: Remove all php closing tags from your source code (?>). This is especially important when migrating older php code to Drupal 10.2.

I had been experiencing this Ajax error also, while creating a view. To be clear, the error was:
"Oops, something went wrong. Check your browser's developer console for more details."
what resolved the issue for me was to shorten the machine name of the view display. It had been 40+ characters long and I reduced it to something less than 16 characters.

We used the 10.2.1 patch on 10.2.3 with no issues. Very weird issue as it only happened on one of our production servers but could not be reproduced anywhere where, including local. Thank you for this patch, it got us back up and running after 4 days of searching for an answer.

I have used #35 10.2.1 patch and it worked.
Updating comment .
On doing some more testing on the site, it fixes the issue but when I click on the configure or add section on layout builder second time ,it again gives error
An error occurred during the execution of the Ajax response: TypeError: Cannot read properties of null (reading 'style')
Steps to replicate:
1)Go to layout
2)Click on configure link on any section
3) It will open the window
4)Close the window,again click on configure link
5)Blank window will open and error in console.
Tried patch given in #16 https://www.drupal.org/project/drupal/issues/3414753 but did not work.

I applied the 10.2.0 patch on a 10.2.3 install and no luck.

I have this problem on all my sites, everywhere now. Mostly layout builder (can't add sections, can't add certain blocks) but also elsewhere (can't set default images for fields).

SOLVED: Drupal, "Oops, something went wrong. Check your browser's developer console for more details."
Yep, same here (line-break on line 1 of custom module).
To fix:
Go to a plain text editor, create new file, hit enter (to create a line-break), select all, copy.
Go to code editor, search entire site for:
Paste the line-break in, then type "<?"

It should find any line-breaks in line 1 of code. Note: I use the copy and paste technique because hitting enter in the search bar of the code editor means that you want it to search, not insert a new line.

This was hard to see, as VSCode had a helper icon blocking line #1.

The Ajax issue is still present on 10.2.4. In a custom module I have a very simple form, I simplified the ajax response to jus say "Hello", I switched to the default Olivero theme to be sure there is no interference with any other jquery or ajax call. This form was working with no problem on 10.1.2.

What I noticed in the console display of he error is that whatever the context of my form is used (and so producing variable ajax responses), it always has a "settings"; nul' in the response text. This quote after nul sounds suspect to me.

message: '\nAn AJAX HTTP error occurred.\nHTTP Result Code: 200\nDebugging information follows.\nPath: /path_to_the_calling_page?ajax_form=1\nStatusText: parsererror\n

ResponseText: 

[

{"command":"update_build_id","old":"form-rjF70Nh6-v5uOijTmG0ZX6MHU8dDqTYYjLsJzf79Stk",
"new":"form-LHnajKIYq8szIGH0kkk-4vqtqzU_FsZmY2tLXUHqkqc"},

{
"command":"insert",
"method":"replaceWith",
"selector":"#my_ajax_form_element",
"data":"Hello",
"settings":nul'
​
name: "AjaxError"
​
stack: "@https://my_site.com/core/misc/ajax.js?v=10.2.4:196:32\n@https://my_site.com/core/misc/ajax.js?v=10.2.4:1916:3\n"
​
<prototype>: Error: 
ajax.js:196:32 etc.

Extra line-breaks are mine to make it evident that there is a malformed json array, probably due tho the nul'.

I tried patch 10.2.1 from #35, it worked on the first call of the form (a click on submit button), but it didn't work on the next calls although there was no error displayed on the console.

I would be happy to help further if I understood the details of this, but this issue is probably preventing many websites from updating to 10.2

Similar to #42, I am also unable to add a default image. In fact I can't save any image field (new or re-used). The following error is logged:

InvalidArgumentException: Placeholders must have a trailing [] if they are to be expanded with an array of values. in Drupal\Core\Database\Connection->expandArguments() (line 896 of /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php).

#0 /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php(822): Drupal\Core\Database\Connection->expandArguments()
#1 /var/www/html/web/core/lib/Drupal/Core/Database/Query/Select.php(525): Drupal\Core\Database\Connection->query()
#2 /var/www/html/web/core/lib/Drupal/Core/Entity/Query/Sql/Query.php(271): Drupal\Core\Database\Query\Select->execute()
#3 /var/www/html/web/core/lib/Drupal/Core/Entity/Query/Sql/Query.php(84): Drupal\Core\Entity\Query\Sql\Query->result()
#4 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(607): Drupal\Core\Entity\Query\Sql\Query->execute()
#5 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityRepository.php(63): Drupal\Core\Entity\EntityStorageBase->loadByProperties()
#6 /var/www/html/web/core/modules/image/image.module(355): Drupal\Core\Entity\EntityRepository->loadEntityByUuid()
#7 [internal function]: image_entity_presave()
#8 /var/www/html/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(409): call_user_func_array()
#9 /var/www/html/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(388): Drupal\Core\Extension\ModuleHandler->Drupal\Core\Extension\{closure}()
#10 /var/www/html/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(408): Drupal\Core\Extension\ModuleHandler->invokeAllWith()
#11 /var/www/html/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(343): Drupal\Core\Extension\ModuleHandler->invokeAll()
#12 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(529): Drupal\Core\Config\Entity\ConfigEntityStorage->invokeHook()
#13 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(483): Drupal\Core\Entity\EntityStorageBase->doPreSave()
#14 /var/www/html/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(257): Drupal\Core\Entity\EntityStorageBase->save()
#15 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityBase.php(352): Drupal\Core\Config\Entity\ConfigEntityStorage->save()
#16 /var/www/html/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php(609): Drupal\Core\Entity\EntityBase->save()
#17 /var/www/html/web/modules/contrib/field_permissions/field_permissions.module(137): Drupal\Core\Config\Entity\ConfigEntityBase->save()
#18 [internal function]: field_permissions_field_config_edit_form_builder()
#19 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityForm.php(307): call_user_func_array()
#20 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityForm.php(171): Drupal\Core\Entity\EntityForm->buildEntity()
#21 /var/www/html/web/core/modules/field_ui/src/Form/FieldConfigEditForm.php(278): Drupal\Core\Entity\EntityForm->afterBuild()
#22 [internal function]: Drupal\field_ui\Form\FieldConfigEditForm->afterBuild()
#23 /var/www/html/web/core/lib/Drupal/Core/Form/FormBuilder.php(1084): call_user_func_array()
#24 /var/www/html/web/core/lib/Drupal/Core/Form/FormBuilder.php(579): Drupal\Core\Form\FormBuilder->doBuildForm()
#25 /var/www/html/web/core/lib/Drupal/Core/Form/FormBuilder.php(325): Drupal\Core\Form\FormBuilder->processForm()
#26 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityFormBuilder.php(48): Drupal\Core\Form\FormBuilder->buildForm()
#27 /var/www/html/web/core/modules/field_ui/src/Controller/FieldConfigAddController.php(62): Drupal\Core\Entity\EntityFormBuilder->getForm()
#28 [internal function]: Drupal\field_ui\Controller\FieldConfigAddController->fieldConfigAddConfigureForm()
#29 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array()
#30 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(627): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#31 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(121): Drupal\Core\Render\Renderer->executeInRenderContext()
#32 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext()
#33 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(181): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#34 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw()
#35 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle()
#36 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle()
#37 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle()
#38 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\ContentLength->handle()
#39 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass()
#40 /var/www/html/web/modules/contrib/shield/src/ShieldMiddleware.php(270): Drupal\page_cache\StackMiddleware\PageCache->handle()
#41 /var/www/html/web/modules/contrib/shield/src/ShieldMiddleware.php(155): Drupal\shield\ShieldMiddleware->bypass()
#42 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\shield\ShieldMiddleware->handle()
#43 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
#44 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
#45 /var/www/html/web/modules/contrib/remove_http_headers/src/StackMiddleware/RemoveHttpHeadersMiddleware.php(49): Drupal\Core\StackMiddleware\AjaxPageState->handle()
#46 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\remove_http_headers\StackMiddleware\RemoveHttpHeadersMiddleware->handle()
#47 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(704): Drupal\Core\StackMiddleware\StackedHttpKernel->handle()
#48 /var/www/html/web/index.php(19): Drupal\Core\DrupalKernel->handle()
#49 {main}

I'm not able to add a dynamic 'Content' reference field:

Drupal\Core\Entity\EntityStorageException: 'field_storage_config' entity with ID 'node.field_content_reference' already exists. in Drupal\Core\Entity\EntityStorageBase->doPreSave() (line 519 of core/lib/Drupal/Core/Entity/EntityStorageBase.php).

And also not able to add a regular 'Content' reference field:

InvalidArgumentException: Field field_new_content_reference is unknown. in Drupal\Core\Entity\ContentEntityBase->getTranslatedField() (line 616 of core/lib/Drupal/Core/Entity/ContentEntityBase.php). Drupal\Core\Entity\ContentEntityBase->get() (Line: 116)

All of these issues are only in 10.2.x (including the 10.2.4). 10.1.8 and earlier work fine.

I did notice that the UI for this functionality has changed in the 10.2 branch; so assume this is related.

#46 looks unrelated to the original issues reported here (which are about whitespace in PHP files) - it looks more likely to be a contrib module altering a form that needs an update to 10.2 or similar. First check that your modules are all up-to-date.

@marc.groth are you using DER? https://www.drupal.org/project/dynamic_entity_reference

hi all,

I'm on Drupal 10.2.4 with PHP8.2.17 I tried #35 10.2 and 10.1 (tried both) and got error cannot apply patch.

Am I missing something in my composer? Thanks in advance!

 "drupal/core": {
                "#35 https://www.drupal.org/project/drupal/issues/3409885": "https://www.drupal.org/files/issues/2024-01-16/disable-ContentLength-http_middleware_10.2.1.patch"
            }

Thanks @catch. That is a really good point! We have a number of outdated contrib modules. In the past we have been able to update Drupal core first; but it makes sense to get the contrib modules updated first.

And to answer your question, yes we are using the DER module.

Thanks for your suggestions and sorry for the temporary noise in this ticket :)

Everyone please disregard #46

#15 worked for me. Thank you. Spent all day reading and researching this.

I had just updated our TEST server to 10.2.5 and was having AJAX errors caused while trying to run manual updates, add media, add images, remove images, edit fields in Views... Didn't have these issues on our DEV server which was running the same version. However we did copy our LIVE server over to our TEST server, so at first I thought it was something else.

Thank you for the regexp so I didn't have to look that up myself.

The culprit was in the web/sites/default/settings.php file. A lonely blank line above the opening <?php tag. The version on our DEV and LIVE servers did not have this line so I'm still trying to figure out who/how this appeared.

Having this issue as well after upgrading to 10.2.2 from 10.1.6. Checked for spacing on <?php, no dice.

Patch #35 unfortunately did not work.

I am having same issue after updating Drupal. When I submit webform I get following error.
Oops, something went wrong. Check your browser's developer console for more details.

If anyone else encounters this issue, i had updated the Cloudflare WAF rules to the latest version.
'/cdn-cgi/challenge-platform' was in the response for all ajax requests. Disabling the items in screenshot fixed the issue.

Thanks guys!

A break line before <?php in a custom module was causing an ajax parse error, breaking the batch update process.

I am experiencing the same issue as ticket #54.
I followed up on #15 and found the issue pretty quickly.

I am running into this same issue. I believe this issue cropped up with a Drupal 10.2 upgrade, because I'm pretty sure it used to work on 10.1.

Basically, I can reproduce the issue by adding an entity reference field to any content type, and when I change options on the field (that do some Ajax operations) like changing the type of content to reference or changing limited/unlimited options, I get the Ajax error.

UPDATE: This is not only an issue with entity reference fields, it also happens with others like Link field or any other fields that have the "Limited/Unlimited" option. When changing that option, the issue happens.

"
An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /admin/structure/types/manage/author/add-field/node/field_refer?destinations%5B0%5D%5Broute_name%5D=entity.node.field_ui_fields&destinations%5B0%5D%5Broute_parameters%5D%5Bentity_type%5D=node&destinations%5B0%5D%5Broute_parameters%5D%5Bfield_name%5D=field_refer&destinations%5B0%5D%5Broute_parameters%5D%5Bnode_type%5D=author&destinations%5B1%5D=/admin/structure/types/manage/author/fields/add-field
StatusText: error
ResponseText: The website encountered an unexpected error. Try again later.InvalidArgumentException: Field field_refer is unknown. in Drupal\Core\Entity\ContentEntityBase->getTranslatedField() (line 616 of core/lib/Drupal/Core/Entity/ContentEntityBase.php). Drupal\Core\Entity\ContentEntityBase->get('field_refer') (Line: 116)
Drupal\field_ui\Form\FieldStorageConfigEditForm->form(Array, Object) (Line: 107)
Drupal\Core\Entity\EntityForm->buildForm(Array, Object) (Line: 85)
Drupal\field_ui\Form\FieldStorageConfigEditForm->buildForm(Array, Object, Object) (Line: 199)
Drupal\field_ui\Form\FieldConfigEditForm->form(Array, Object) (Line: 107)
Drupal\Core\Entity\EntityForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 536)
Drupal\Core\Form\FormBuilder->retrieveForm('field_config_edit_form', Object) (Line: 375)
Drupal\Core\Form\FormBuilder->rebuildForm('field_config_edit_form', Object, Array) (Line: 633)
Drupal\Core\Form\FormBuilder->processForm('field_config_edit_form', Array, Object) (Line: 325)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 48)
Drupal\Core\Entity\EntityFormBuilder->getForm(Object, 'default', Array) (Line: 63)
Drupal\field_ui\Controller\FieldConfigAddController->fieldConfigAddConfigureForm('node', 'field_refer')
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 50)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
"

It almost seems like some bug with the multi-step setup form of creating a new field where you first pick the field type, then you pick which option you want to use from available options on that field type. It seems like the timing of the processes may be off, where when its doing the Ajax events on the field, the field is not yet created and for some reason it's expecting it.

Also happens when trying to 'add another item' to a Selection list field (in my case 'List (text)') and when trying to change the allowed number of values.

A bit more exploration: I realised only one of my sites has this problem, so this implies a contrib or custom module causing the problem. Built a clean site a module at a time and sure enough one of my custom modules is causing the problem. At this point of exploration I don't yet know what is happening. Will report back if I find anything interesting.

If you come across this, check your theme debug settings and make sure the feature is turned off.

Thanks guys!

#15 save my life.

#10 worked for me!

In my case it was also a line break before <?php in a custom module which broke Ajax in many places.

Ran into this parse error, would happen on firefox and safari, but didnt occur with chrome

#10 also worked for me when working locally with DDEV, but it still wouldnt work on the stage site

In my case I noticed the response headers on the stage were missing the content-encoding: gzip

Tweaked our nginx.conf with some additional gzip settings and it finally worked

Today I upgraded from v9.5 to v10.3.6 and I also had the broken ajax issue. Solution #10 fixed the issue.

This may be related to https://www.drupal.org/project/drupal/issues/3494148. In the original issue, I can see where the last few characters of the AJAX response got cut off. If you are still experiencing this issue, please try the patch.

@czigor can you please let me know how used the regexp \s+<\?php to find such occurences in my codebase? i have the same issue and wanna be sure...

If anyone needs it, I've created the updated patch #35 for 10.4.x

#35 updated patch for 10.5.x

#10 and #67 worked, thank you.