I think the problem is in het menu_order property within the posts table in the database, which is not updated for posts after the deleted posts.
bbp_get_reply_position() within bbp_get_reply_url() is using this menu_order property. The result determines the page a post should be on, which is therefore wrong when posts have been deleted and other post’s ‘menu_order’ is in fact too high.
interesting, and thanks fro doing a lot of digging
try
dashboard>tools>forums>repair forums and run
Recalculate position of each reply in each topic
That does not fix the problem, it does not affect menu_order.
ok, just a thought
so is it JUST the recent replies widget that has this issue ?
No, it occurs also when viewing all topics on the main page of a forum: within the link to the latest reply.
Every link that links directly to a specific reply on a certain topic has this issue.
yes, the function seems to look up the reply position and if it exists, does not change it
Put this in your child theme’s function file – or use
Code Snippets
add_filter ('bbp_get_reply_position' , 'rew_redo_reply_position', 10 , 3 ) ;
function rew_redo_reply_position ($reply_position, $reply_id, $topic_id) {
// Get required data
$reply_id = bbp_get_reply_id( $reply_id );
// Get topic ID
$topic_id = ! empty( $topic_id )
? bbp_get_topic_id( $topic_id )
: bbp_get_reply_topic_id( $reply_id );
// Post is not the topic
if ( $reply_id !== $topic_id ) {
$reply_position = bbp_get_reply_position_raw( $reply_id, $topic_id );
// Update the reply position in the posts table so we'll never have
// to hit the DB again.
if ( ! empty( $reply_position ) ) {
bbp_update_reply_position( $reply_id, $reply_position );
}
// Topic's position is always 0
} else {
$reply_position = 0;
}
// Bump the position by one if the topic is included in the reply loop
if ( ! bbp_show_lead_topic() ) {
$reply_position++;
}
// Filter & return
return (int) apply_filters( 'rew_redo_reply_position', $reply_position, $reply_id, $topic_id );
}
and come back with whether that fixes, it may not retro fix, so you may need to delete another reply to get it to work.
I assume this ‘3’ and ’10’ should not be in there and the function should be defined like function rew_redo_reply_position ($reply_position, $reply_id=0, $topic_id=0) ?
In that case, the link to new pages does not work at all: /page/2 is not generated anymore and the link becomes /#post-id , which does not exist anymore on the first page since it is on page 2…
I have been looking at the function more closely, and think the correct code is as follows:
add_filter ('bbp_get_reply_position' , 'rew_redo_reply_position') ;
function rew_redo_reply_position ($reply_id=0, $topic_id=0) {
// Get required data
$reply_id = bbp_get_reply_id( $reply_id );
// Get topic ID
$topic_id = ! empty( $topic_id )
? bbp_get_topic_id( $topic_id )
: bbp_get_reply_topic_id( $reply_id );
// Post is not the topic
if ( $reply_id !== $topic_id ) {
$reply_position = bbp_get_reply_position_raw( $reply_id, $topic_id );
// Update the reply position in the posts table so we'll never have
// to hit the DB again.
if ( ! empty( $reply_position ) ) {
bbp_update_reply_position( $reply_id, $reply_position );
}
// Topic's position is always 0
} else {
$reply_position = 0;
}
// Bump the position by one if the topic is included in the reply loop
if ( ! bbp_show_lead_topic() ) {
$reply_position++;
}
// Filter & return
return (int) apply_filters( 'rew_redo_reply_position', $reply_id, $topic_id );
}
I’m sorry , it does not indeed.
Edit: I’m sorry, I now understand the 3 and the 10 are add_filter inputs to set priority and number of arguments…
Your code works, thanks a lot. I have been to fast in my replies without proper testing.
great – glad you are fixed !! 🙂