Ajax not working when using non-default view mode.

This is an incomplete patch but fix our problem.

Hope this helps

Solved a problem when accessing ajax_comments settings panel.

The patch from @mithenks works. Thank you so much.

#8 is a reroll, because #3 did not apply cleanly.

I tried to fix the patch to make it work properly. But I haven't had any success yet. I now think that the AJAX setting should be in comment ciew mode and not in the field formatter. Due to render caching in Drupal 8, it is not possible to obtain formatter settings from comment view mode. It works for the default view mode because Ajax Comments uses always the default view mode.

This could fix #2778061: Ajax Comments In Views Issue as well.

@qzmenko I would like to hear your opinion on this, because its a bigger architecture change.

#3 works, #8 not for me

#8 worked for me, on 1.x-dev#30b790a5921f04e8887a69594920650c53b01362

#8 works for me as well. Even when I use it in a modal :)

I can confirm that patch #8 works for me as well. In my research for this problem i came across this probably related issue https://www.drupal.org/project/drupal/issues/1852090

The patch #8 seems working for me too.

My variant of patch.
Added possibility to use custom view_mode with Display Suite template.
Changed the method of adding a wrapper class for a comment.
Tested with default view mode, with custom view mode and DS template for the custom entity.
I guess, should work with layout builder as well.

Fixed view_display route generation on SettingsForm.

What helped me out is to allow users to hook in to the getWrapperIdFromEntity

added a patch as example based on #20 :)

This wouldn't apply to the latest dev for me. Here is a re-roll of #22 against the latest dev. This seems to be working correctly for me.
Thanks.

Here it is with the codesniffer fixes

This patch applies for me but it doesn't work. Comments previously working with #8 no longer work.

I was hit with this again. Here is a new patch.

@megan_m I see now what you mean, What appears to be happening is if you are using comments in the default view mode, but on a full page view it couldn't find the correct view mode settings unless you have 'full' view mode set up, which most of the time people just let fall back to the 'default' view.

This patch should fix that.

Patch works beautifully on 1.x-dev.

Only error: comment out `dsm($view_mode);` on line 132 of AjaxCommentController.php

+1 rtbc

Hello guys!
These patches don't work with #lazy_builder, because of pager

After removing pager for comments it works well with #lazy builder.
Based on #22

Hi guys,

Thanks for the help here.
I have created a new patch based on #30 and added the changes from #33
Also removed the dsm as per #31.

Also attached two interdiffs coming from #30 and from #33 hopefully this will help :)

@ronaldtebrake:

I just run into this error, when setting up a spanisch Open Social community:

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[HY000]: General error: 1267 Illegal mix of collations (ascii_general_ci,IMPLICIT) and (utf8mb4_general_ci,COERCIBLE) for operation '=': SELECT 1 AS expression FROM {key_value_expire} key_value_expire WHERE (name = :db_condition_placeholder_0) AND (collection = :db_condition_placeholder_1); Array ( [:db_condition_placeholder_0] => 1:view_mode_entity_type_Envío [:db_condition_placeholder_1] => user.private_tempstore.ajax_comments ) in Drupal\Core\TempStore\PrivateTempStore->set() (line 148 of core/lib/Drupal/Core/TempStore/PrivateTempStore.php).

Resulted in the translation of entity type "Post".

Reason why is you used $entity->getEntityType()->getLabel() on several places and geLabel() returns translatable strings.

You should modify all occurences of $entity->getEntityType()->getLabel()->getUntranslatedString() in your patch and in social_ajax_comments.module to be save on translations.

Included comments as per 36, feel free to retest @slowflyer
Will also try and get a patch that applies to the latest beta2 release out

Small update in patch #36:

-        $tempStore->setViewMode($entity->getEntityType()->getLabel()->getUntranslatedString()->getUntranslatedString(), $acting_view_mode);
+        $tempStore->setViewMode($entity->getEntityType()->getLabel()->getUntranslatedString(), $acting_view_mode);

Also added a beta1 ported patch, curious to hear your feedback

Similiar to @slowflyer, I, too, ran into problems where ajax_comments just stopped working in an Open Social distribution that was heavily modified. In my case, $tempStore->getViewMode returned null in renderCommentField of the AjaxCommentsController. Using methods similiar to those seen in one hunk of #37, a default value was provided if none could be extracted and this solved the render problem for me when used in conjunction with #37. A patch of what I added is attached.

Actually, I just did an update to Open Social 9.5.0 which did updates to Core and this messed with my patches and in the fallout, I discovered that my site was now running ajax_comments 1.0-beta2 and it worked just fine with only the beta-1 patch from #37 applied as it is distributed in Open Social 9.5.0. So, I'm now uncertain of the conditions requiring #38.

Although I've just discovered that the ajax_comments_entity_view_mode_alter function added in #37 will cause WSODs with certain types of entities such as "Dashboard" entities like those created by .

Specifically, you get the following error:

The website encountered an unexpected error. Please try again later.

LogicException: Getting the base fields is not supported for entity type XXXXXX. in Drupal\Core\Entity\EntityFieldManager->buildBaseFieldDefinitions() (line 209 of core/lib/Drupal/Core/Entity/EntityFieldManager.php).

This can be fixed by adding a simple check to ajax_comments_entity_view_mode_alter. Patch attached.

Hi guys,

Small update in patch #37:

-  if ($field_settings_helper->isEnabled($comment_formatter)) {
+  if (!empty($comment_formatter) && $field_settings_helper->isEnabled($comment_formatter)) {

It will fix related issue:
https://www.drupal.org/project/social/issues/3198706

#41 worked great for me on 8.9.13

Shouldn't this be against latest .dev? (And at least beta3 not an older beta?)

Patch applied successfully on beta2. Failed on Beta3 though. Likely need an updated patch.

beta3

#41 works for me on drupal/ajax_comments (1.0.0-beta2)

beta4 reroll

Thanks @devitate - #49 works great on beta4. Commit!!!! :)

#49 working for me! Thanks You!

I have Beta 4 and applied the #49 patch, but it does not work.

I have a view which shows content and has a field view showing the comments.
The problem is that when I reply, and press "save", nothing happens, but the comment is saved and visible only after page refresh.
Also If I add a new comment, same thing, nothing happens the page is not updated and the comment text field stays open after pressing "save".

I have plain Bartik theme.

What works, is if I just view the node (without views) then the ajax comments are working, and the page is updated after replying or adding a new comment.

So is there a trick, or is it even possible to use this module with views while showing the comments using a field view (from another view)?

(also I have this patch: https://www.drupal.org/files/issues/2021-04-09/3208008-2.patch )
Drupal 8.9.16

Well, the patch did fix my problem with refreshing the list of comments when view mode not equal to default (even within a views page) BUT the comment list that is used to replace, uses again the default view mode template.

In the method renderCommentField, when passing the display options to the field view, it returns the default one.
I have made a custom patch that changes the line:
From:

    $view_mode = $tempStore->getViewMode($entity->getEntityType()->getLabel()->getUntranslatedString());
    $display_options = $this->entityTypeManager
      ->getStorage('entity_view_display')
      ->load($entity->getEntityTypeId() . '.' . $entity->bundle() . '.' . $view_mode)
      ->getComponent($field_name);
    $comment_display = $comment_field->view($display_options);

To:

  $view_mode = $tempStore->getViewMode($entity->getEntityType()->getLabel()->getUntranslatedString());
  $comment_display = $comment_field->view($view_mode);

But I am unsure of what impact it could have on other projects, so I didn't want to post the patch here but first ask about this solution.

I'm not sure why, but the patch in #49 has changed the following condition:

-  if (empty($comment_formatter) || !$field_settings_helper->isEnabled($comment_formatter)) {
+  if (!empty($comment_formatter) && !$field_settings_helper->isEnabled($comment_formatter)) {

This doesn't seem correct, why would we want an empty formatter through? This is causing:
Warning: Undefined array key "id" in ajax_comments_form_comment_form_alter()

Patch to fix from #54 (applied on beta4)

This patch adds a session to anonymous users and breaks page cache on any entity that allows comments, at very minimum we should be checking if they can post comments.

Patch #56 is fixing the problem for us and prevents opening a session for anonymous users.

Not working here, using the last patch the form is still not updating after adding a new comment. Not overriding any comment related templates.

💩, it needs a beta5 patch now.

Attaching patch for beta5

Could we please have MR for this and perhaps someone could contact an active maintainer to have this fixed finally? Looks like a lot of people run into this trouble? :)

Thanks!

As of #61

Approach looks good, but this issue will need some test coverage before commit.

Created MR and hid patches.

Thank you parisek, your MR works as expected.

Now It works for a different view mode for me.

I am not sure if it is related. But Edit button now does not work. I am using modal window and using different view mode to display. Everything works fine after i applied that MR, however edit button does not work - whole screen become greyed out. Once I click ESC and open dialog window again + edit button - it works fine.
But every time refresh of page needs to be done.

Delete button works fine because there is normal link comment/nid/delete but edit link is now ajax_comment/nid/instead....

However when I loggin as different user who doesn't have permission to delete comment - everything works fine for edit button.

So somehow delete button which has link comment and not ajax_comment conflifts with edit button...

console says:

An element doesn't have an autocomplete attribute
A form field has an id or name attribute that the browser's autofill recognizes. However, it doesn't have an autocomplete attribute assigned. This might prevent the browser from correctly autofilling the form.
To fix this issue, provide an autocomplete attribute.

#71 - it does not work also for the normal view, so it is not related to this issue. Hence I created a new one here.

3394119 - Edit button in Dialog window

@parisek, @coaston still no test coverage, sadly. It's needed to get this issue fixed finally.

Anybody, do you think it is possible to disable ajax for operation actions like edit/delete (or simply add target "_blank" to this links ?)
This would solve the issue for dialog.

Updating #60 to convert display option to empty array if it is null

Patch #75 works for me using Drupal 10.1.7 + CKEditor 5 on a full display mode.

The problem with the above patches is they assume every entity is fieldable, but if not it throws WSOD!

@globexplorer, please remove changes to ajax_comments.info.yml and could you provide an interdiff?

Could we perhaps switch to a MR which is easier to review and "interdiffed automatically"?

Still this has no tests to ensure it doesn't break again in the future.