Opened 11 years ago
Closed 9 years ago
#2529 closed defect (bug) (fixed)
Single topic description counts not updated after permanently deleting a reply
Reported by: | netweb | Owned by: | johnjamesjacoby |
---|---|---|---|
Milestone: | 2.6 | Priority: | normal |
Severity: | normal | Version: | 2.5 |
Component: | Component - Replies | Keywords: | has-patch commit |
Cc: |
Description
Repro Example (front end)
A Topic:
This topic contains 8 replies, has 1 voice, and was last updated by admin 3 days, 23 hours ago.
Mark the last reply as 'Trash' (Using the last reply checks latest topic freshness functionality)
This topic contains 7 replies (+ 1 hidden), has 1 voice, and was last updated by admin 4 days, 1 hour ago.
Permanently Delete that reply
This topic contains 7 replies (+ 1 hidden), has 1 voice, and was last updated by admin 4 days, 1 hour ago.
Expected the the sigle topic description to now be only 7 replies
, to get the counts accurate again you need to run the repair tool "Count spammed & trashed replies in each topic"
This topic contains 7 replies, has 1 voice, and was last updated by admin 4 days, 1 hour ago.
The same behaviour when performing the above from the back end.
See bbp_single_topic_description
, bbp_deleted_reply
and bbp_update_reply_walker
Attachments (7)
Change History (23)
#4
@
11 years ago
- Milestone changed from Awaiting Review to 2.6
Thanks for this. Curious why it's not already happening, though.
On the deleted_post
action, bbp_deleted_reply
calls bbp_update_reply_walker
with similar default parameters as this, so it should already be happening.
I'll do some checking to confirm the call stack. Do you mind doing the same on your end?
#5
@
11 years ago
Oh... because by the time deleted_post
fires, the metadata has already been removed via delete_metadata_by_mid()
Duh.
We'll likely need an additional action on before_delete_post
to store the necessary meta in the bbpress()
instance so we can pass them into a special action to handle deletes.
#6
@
10 years ago
Spent some more time with this. Came up with two basic solutions, each with a version targeted only for bbp_deleted_reply
(so... basically 4 solutions). All are based on the fact that _bbp_forum/topic_id meta is essentially derived from the post_parent field of the reply, and the post_parent of the reply's topic. Since deleted_post
is called directly before the post cache is cleaned, we can dip into the cache to help us get our topic_id/forum_id. With that in mind, the 4, below, patches fix the issue.
The first set works by patching the bbp_get_reply_topic/forum_id
functions to pull from post cache. This also includes a more targeted version that only runs on bbp_deleted_reply
.
The second set works by patching bbp_update_reply_walker
to pull from the post cache. It too, includes a more targeted version that only runs on bbp_deleted_reply
.
Personally I think 2529.2.diff is the best approach, because I could be a very helpful fallback. Going this route would also raise the question of whether or not to do this with any other bbp_get_*_topic/forum_id
functions.
This ticket was mentioned in IRC in #bbpress-dev by netweb. View the logs.
10 years ago
#8
@
10 years ago
Came across this again while working on the tests for #2801. The new attached patch should be sufficient.
This ticket was mentioned in Slack in #bbpress by jjj. View the logs.
10 years ago
#10
@
9 years ago
- Owner set to johnjamesjacoby
- Resolution set to fixed
- Status changed from new to closed
In 5859:
#12
@
9 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
All WordPress 3.7 and 3.8 versions PHPUnit tests fail with this change
PHP Fatal error: Call to undefined function current_action() in /tmp/wordpress/src/wp-content/plugins/bbPress/src/includes/replies/functions.php on line 932
Function current_action()
was added to WordPress in 3.9 in [wp27294]
#13
@
9 years ago
Harrumph. I suppose so. That's unfortunate.
I'm comfortable bumping the minimum WordPress version whenever the core team EOL's it, maybe around the 4.3 RC?
#15
in reply to:
↑ 14
@
9 years ago
- Keywords commit added
Replying to thebrandonallen:
We could just switch to
current_filter()
for now.
Works for me, tested 2529.7.diff per original repro steps and works as expected.
Those repro steps of mine are horrible, glad my writing has, hopefully improved ;)
I wasn't able to reproduce the problem from the back end, but the attached patch fixes the issue when permanently deleting from the front end using the admin links.