Skip to:

Opened 10 years ago

Closed 10 years ago

#5811 closed defect (bug) (fixed)

Ajax crashes on new reply to comment

Reported by: sgr33n's profile SGr33n Owned by: r-a-y's profile r-a-y
Milestone: 2.1 Priority: normal
Severity: normal Version:
Component: Appearance - Template Pack Keywords: has-patch commit



It's since a few svn versions that if you reply to a comment the ajax sender crashes. When you click on the send button, the class loading is added to the submit button, but the comment is never added, and the loading class remains there until you reload the page.

Attachments (1)

5811.01.patch (764 bytes) - added by r-a-y 10 years ago.

Download all attachments as: .zip

Change History (11)

#1 @r-a-y
10 years ago

Do you have WP_DEBUG set to true? If so, what error messages are in wp-content/debug.log?

If you have WP_DEBUG set to true, set it to false and see if AJAX works again.

#2 @SGr33n
10 years ago

Hi r-a-y!

I disabled WP_DEBUG but still don't works. I don't have that file, and the firefox debug console doesn't show me any error. The strange thing is that the error occurs just replying to a comment... commenting an activity works pretty good.

#3 @r-a-y
10 years ago

Can you outline the steps that you're doing to get the AJAX crash? Explain every step, what page you're on, what textbox you're typing in, etc. so I can try to duplicate this.

#4 @SGr33n
10 years ago


I click on reply button:

<a id="acomment-reply-148227-from-148260" class="acomment-reply bp-primary-action" href="#acomment-148260">Reply</a>

Then buddypress.js adds the form:

<form id="ac-form-148227" class="ac-form" method="post" action="" style="display: block;">
<div class="ac-reply-avatar">
<img class="avatar user-1-avatar avatar-80 photo" width="80" height="80" alt="Foto del profilo di SGr33n" src="">
<div class="ac-reply-content">
<div class="ac-textarea">
<textarea id="ac-input-148227" class="ac-input bp-suggestions" name="ac_input_148227"></textarea>
<input type="submit" value="Send" name="ac_form_submit">
<a class="ac-reply-cancel" href="#">Cancella</a>
<input type="hidden" value="148227" name="comment_form_id">
<input id="_wpnonce_new_activity_comment" type="hidden" value="23ace042f5" name="_wpnonce_new_activity_comment">
<input type="hidden" value="/" name="_wp_http_referer">

I write the comment then I push on the submit button and then it stops working.

#5 @r-a-y
10 years ago

  • Milestone changed from Awaiting Review to 2.1


For anyone else reading, this occurs when you attempt to reply to an activity comment in the sitewide activity stream.

It appears to be hanging here:

Will take a closer look.

Version 0, edited 10 years ago by r-a-y (next)

#6 @boonebgorges
10 years ago

r-a-y - Check out - it could be that this needs to be ported into this AJAX callback as well.

10 years ago

#7 @r-a-y
10 years ago

  • Component changed from Core to Template Pack
  • Keywords has-patch added

The explicit check here was causing the problem.

01.patch casts the $parent_id as an integer, which fixes the problem.

This problem did not occur in BP 2.0.2 though. Will try to use git bisect to see where this bug started happening.

#8 @r-a-y
10 years ago

git bisect to the rescue! r8708 broke this while attempting to fix unit tests caused by r8697.

What is the best way forward?

#9 @boonebgorges
10 years ago

  • Keywords commit added

Thanks for the research, r-a-y. I'd go with your focused patch in 5811.01.patch. The changes in r8708 are an improvement that we do not want to roll back if we can help it. If they've had any other ramifications, I'm sure we'll find out about them eventually.

#10 @r-a-y
10 years ago

  • Owner set to r-a-y
  • Resolution set to fixed
  • Status changed from new to closed

In 8828:

bp-legacy: Fix 'Maximum Execution Time' fatal error when attempting to reply to an activity item.

Changes in r8708 caused an infinite loop to occur while manually
determining the activity comment's depth. This is due to the type casting
in r8708.

To fix this in bp-legacy, we also type cast the various item IDs to prevent
the infinite loop from occurring.

Fixes #5811.

Note: See TracTickets for help on using tickets.