Thanks for the thorough investigation and explanation @Ammaletu! I was very confused as to why my debugger was breaking on the comments view builder 2 times. This is also good knowledge to keep in mind that every field which remains rendered in the default entity view mode goes through the render process.
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've finally resolved my site's issue. I found a new line before the open PHP tag in a module...my own custom module! Thanks all.
@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 delivered 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 🐛 Regression from #3295790 content-length header set earlier than expected Fixed . 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.
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.
I just tested the MR in 🐛 Only set content-length header in specific situations Fixed 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.
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?
Further investigation into this issue.
As I mentioned in comment #10 🐛 Uncaught ajax.js error / exception Active 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 issue.
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.
- 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.
- 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.
- 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 ']'.
- 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 that the JSON is leaving this function differently than it arrives to the browser.
- 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 ResponseText JSON reaches 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. Layout Builder was the only Ajax affected on my current site where traced the problem. On that site I could not replicate with other Ajax behaviors like in Views.
Gitlab MR made.
ikphilip → created an issue.
I'm currently working through this problem. Although I'm simply trying to output a list of Groups that the User belongs to (via group_membership). There are a few ways to approach this and I think the best solution depends on how you want content rendered by the View.
Fields: Users view
In my opinion the simplest solution to this problem is creating a User view which displays a list of fields. Because this is a User content view the Contextual filters will offer to link User Content by default. Create this contextual filter first for the User ID.
In order to get Group Content fields we need to add two relationships. First add a Category: Group Relationship, Group relationship for User: Relates to the group relationship entities that represent the User. and Filter by Plugin Group membership plugin and Require the Relationship. I've named this "User Group Relationship." Apply and add the second relationship Category: Group Relationship, Group: The group containing the entity. Set it to use your first relationship and Require it. I've named this second relationship "Group" in Administrative title for simplicity since data from this relationship pertains to the Group entity.
Entities: Group view
If your goal is to display group entities then you'll need to create a View which displays Group content. In order to use User as the Contextual Filter first create a Relationship to Group Membership. Create a Relationship find Category: Group, Group Relationship: Relate to the group relationship entities. From there you can relate to the actual grouped entities.. Filter by Plugin Group Membership and Require this relationship. I've named this Relationship "Group Membership."
Now you can add a Contextual Filter based on your Group Relationship. In my settings I wish to specify the User ID in the URL so I select Provide default value and Type: Content ID from URL. Now the numeric ID in your URL can be pulled in to filter on the User ID.
The final thing I've done is ensure that the Group membership relationship only applies to the membership content. Note that in Contextual Filter options we didn't get to specify what content ID so we can theoretically pull in other content/entities with the same numeric ID. I've added this filter to prevent this from happening.
Hope this has been helpful. This isn't the only way I can imagine. You could also try rendering things using Group Membership entities but I think these two examples show the patterns you need to solve this problem.
Patch #5 should fix the my_invitations view to correctly create the routes.
OK. Further investigation reveals ginvite is using a built-in access check in the group module. That check in Drupal\group\AccessGroupInstalledContentAccessCheck->access() requires a 'group' parameter be passed or else it fails the condition !$parameters->has('group') and returns AccessResult:neutral(). As currently constructed only group_relationship parameter is found. Adding the group id to the route appears to pass enough information to the group access check to pass.
This patch adjusts the routing and edits the My Invitations view which generates operation links.
ikphilip → created an issue.
ikphilip → created an issue.
Issue is ported to 5.x branch. Change will be included in next release version.
I've tested this on 5.1.3 and branch 5.x and this patch (#2) works.
Updated patch #6:
- Uses PathMatcher::matchPath() method.
- Adds and utilizes a preparePath() method in src/Event/PagesRestrictionSubscriber.php which in addition to filtering and trimming the URL now prefixes the path with a forward-slash. This should suffice so that URLs which match the instructions work properly. This method is also called in src/Event/PagesRestrictionSubscriber.php in cases where paths were filtered and trimmed.
When all paths are prefixed with a forward-slash (/) the matchPath function works as expected. Therefore the documentation for user input should be updated.
Upon further investigation I've found with release 2.0.0 (no patch) paths that aren't prefixed with forward-slash do not work correctly. I think that the input description (src/Form/PagesRestrictionSettingsForm.php:64) is incorrect. It also conflicts with the example configuration screenshot on the project landing page.
All this to say, we'll want a new patch that updates the description and either upgrades the stored paths or prefixes paths with a forward slash if none is found.
Patch in comment #2 🐛 Unable to save configuration for webform handlers with conditionals support disabled Fixed is working for me. Drupal 9.5.2. Thank you.
Adding a new patch Core patch to fix another issue I found. It will be better if Seven's CSS can eventually override Core's stylesheet but I've built this based on the previous Drupal core patches in the thread.