[timsilva_]

Hi all, hope you’re doing well.

I noticed what I suspect is a bug a few weeks ago. After digging through the forums, disabling plugins, turning off custom functions and more, I cannot seem to identify the source of my following issue.

Basically, when the bbp_topic_freshness_link() function is called in loop-single-topic.php, for example, the URL should show something like:

domain[dot]com/forum/topic/topic-title/page/2/#post-12345

Note that the /page/2/ part is only meant for threads that have more than one page of replies. So if that same example topic only had 2 replies, for example, the URL would have been:

domain[dot]com/forum/topic/topic-title/#post-12345

So the issue I am having is that for some topics, when there are multiple pages, the /page/2/ part of the URL isn’t included. So when the link it clicked on, it goes to the first reply on the first page of the topic. What’s more baffling is that sometimes, the link without the /page/2/ bits included does go to the correct URL. I’ve tried this from multiple accounts and I cannot seem to uncover any meaningful patterns.

I did try to run the repair job titled “Recalculate last activity in each topic and forum” with no luck. All of the URLs are still randomly missing the page parts.

A few potentially relevant notes:
– I migrated my forum from SMF
– All of my forums are private
– I am using the “Go To First Unread Post” plugin but the issue still occurs when disabled

Does it sound like this issue related to this fix?: https://bbpress.trac.wordpress.org/ticket/2876

Many thanks,
Tim

[Pascal Casier]

Hi,
There were major pagination issues in WP 4.4.1.
WP 4.4.2 has corrected that.

Could you please upgrade to that version if not yet done ?

Thanks,
Pascal.

[timsilva_]

Hi Pascal, thanks a lot for the response, I appreciate your time. 🙂

I should have mentioned that I am all up to date with WP 4.4.2.

Here are some screenshots of the issue:

As you can see in the first image, the /page/#/ part is missing when it should be /page/103/.

Shortly after making these screenshots, I clicked on the “10 hours ago” link, and it returned me to the first post on the first page of the “Gaming” topic even though the URL loaded still has “/gaming/#post-683963” in it. In a few instanced where the /page/#/ part is missing, I have been able to click on the link and land on the correct page anyways. Still haven’t found a logical pattern, I will keep digging to try to identify it.

I will soon look to see if I can replicate the issue from a fresh install. I tried turning off all plugins (except bbPress + BuddyPress) with no luck.

[timsilva_]

So I went ahead and decided to launch my site with this bug still present.

I have been trying to isolate the cause of this issue, and I think I have found some common traits about the threads it seems to affect. It seems that only the threads that were migrated from my previous forum (SMF) that have been replied to after the migration are missing the “/page/##/” piece of the URL. So newly created threads always have the “/page/##/” piece of the URL, and old threads from before the migration that haven’t been replied to since the migration to bbPress also always have the correct URLs being generated.

I have tried running all of the repair tasks that should be related, but none of them seem to make any difference.

Does this sound like anything anyone has experiences with the bbp_topic_freshness_link() function?

[Robin W]

interesting

Do you have phpmyadmin access to your database?

If so then I think you need to be looking to compare the data in posts and postmeta between one that works and one that doesn’t to see what is different.

[timsilva_]

@robin-w I do have access to phpmyadmin. I have been looking around, and the only thing that looks fishy is that the “guid” varchar(255) row has my old local environment in the URL instead of my live domain. So it is http://localhost/forum/topic/title/ when it should be http://example.com/forum/topic/title/ – But after I tried to correct that for the post and the postmeta of the thread’s latest reply (in a safe environment) it didn’t seem to fix the problem. I did notice that my old local URL was hardcoded over 220,000 times in my database though, I wonder if this is something that needs to be corrected for each topic/reply.

I tried to get creative by changing the “Replies Per Page” in wp-admin > Settings > Forums to a different number. That successfully recalculated the correct number of pages required for the non-affected threads (I set it from 15 replies per page to 30 replies per page, so a thread with 10 pages was updated with 5 pages, and the latest reply link updated to point to page 5), but the affected threads still have no “/page/##/” segment in the URL.

[timsilva_]

Hmm, I also just noticed that some topics from the migrated database with only a few pages (4 pages in the one I just tested) don’t seem to have this issue.

I designed some the forum topics to be long, ongoing threads. For example, we have a “Music” thread that currently has 7,674 replies (15 per page, so 512 pages total). Could the issue simply be that the thread is so large, that bbPress somehow doesn’t do the calculation?

I have read in some support threads about issues with pagination on bbPress when dealing with large numbers, perhaps it is related to that?

Some additional details that may be related: I have nested replies turned off (and they were never turned on). Also, all of my categories are set to hidden.

[timsilva_]

Sorry for all of the replies, I am finding new leads to the root of the problem.

In both loop-single-reply.php and loop-search-reply.php, the bbp_reply_url function seems to also be outputting URLs without the pagination bits. I have been trying to dig in to the functions, but I’m way out of my league. I found on line 487 of includes/replies/template.php where the $reply_page variable seems to be calculating the pagination for a link, but I don’t know where to begin debugging with it. I also looked at bbp_get_reply_permalink and a few other functions, didn’t see anything obvious.

[Robin W]

sorry – not ignoring you – tied up elsewhere at the mo, but I’ll try and find some time to read and understand this evening !

[Robin W]

ok, I’ve had a quick look.

The page number is set by this line

$reply_page = ceil( (int) bbp_get_reply_position( $reply_id, $topic_id ) / (int) bbp_get_replies_per_page() );

I suspect that bbp_get_replies_per_page is not the issue, but that bbp_get_reply_position is.

so this function is as follows :

function bbp_get_reply_position( $reply_id = 0, $topic_id = 0 ) {

		// Get required data
		$reply_id       = bbp_get_reply_id( $reply_id );
		$reply_position = get_post_field( 'menu_order', $reply_id );

		// Reply doesn't have a position so get the raw value
		if ( empty( $reply_position ) ) {
			$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 lead topic is in the replies loop
		if ( ! bbp_show_lead_topic() )
			$reply_position++;

		return (int) apply_filters( 'bbp_get_reply_position', $reply_position, $reply_id, $topic_id );
	}

so given that you seem fine with accessing the database, and hoping you are fine with editing files and uploading these, let’s see what value are being set in this function. I presume you can edit files, and you say you have a ‘safe’ area in which to play.

so lets start with

$reply_position = get_post_field( 'menu_order', $reply_id );

which is set on line 1742 of includes/replies/template.php

Now we can filter and play with this function, but it is probably easier just to edit the file whilst we test – just take a copy of it before so you can restore at the end.

So I’d add a line after 1742 saying

update_option( 'encide', $reply_position ) ;

save and upload, and then display a page which works and one that doesn’t and each time you can access wp_options in the database and look for the encide option name.

That should tell you what it is set to.

I’d suspect that it is not correct for the faulty ones, and is returning 1 or 0 – hence no pagination.

Come back and let me know what it says, and we can progress from there.

[timsilva_]

Thanks so much for the detailed instructions Robin!

I was able to make that edit in a separate installation and I can see the value being updated in the database each time I load a topic on a certain page. I have been clicking around to various pages and topics trying to understand the patterns, and I think it might have something to do with the custom migration work that I had done.

One of the issues with the build-in SMF to bbPress importers had to do with posts that were created by users on SMF who later deleted their own accounts. After a handful of users did this on SMF, their old posts were still visible, but their usernames/display names wouldn’t link to their SMF profile page since it no longer existed. After I migrated my SMF site, these types of posts (the ones created by users that no longer existed) were all automatically attributed to the first WordPress user ID. The end result was a bunch of old posts from deleted accounts that looked like they were created by the admin account on my WordPress installation. So I hired a developer to transfer the old post author’s metadata over, along with some other data.

Anyways, I suspect that the posts by users who deleted their accounts are possibly not being counted as posts which is causing the pagination calculations to break. So I am showing 15 replies per page, and if 1 of those posts is by a deleted account, I think it is counting 14 instead. I’m not sure if this is correct, but it seems plausible. The more I click around to different threads, the less consistent this explanation seems to be.

But I am not seeing 1 or 0 for the faulty topics.

In newly created topics with pagination, the counting is much clearer. The value is 14 for the first page (subtracting 1 from 15 since the original post doesn’t count as a reply), and then page 2 is 29, page 3 is 44, page 4 is 59, page 5 is 74, and page 6, which only has 4 replies, is 78. This makes sense with 79 total (if you include the original post as a reply).

…30 minutes later…

After some more digging around, I have noticed that the count seems to have started over from 1 in the topics that have had new replies after the migration. So if a topic had 10 pages (let’s say 144 replies, not including the original post) before the migration, and then someone replied to the topic (which would be reply #145), the $reply_position would be 1. Another reply would make it 2, and so on…

So that appears to be the pattern. I did find and verify that at least one thread that was migrated with 702 replies (excluding the first post) is still working after it was responded to once after the migration, although I wouldn’t be surprised if another reply could cause the bug to come back.

It sounds like I will eventually have to repair the reply counts or something along those lines. :/ I’m gonna have my developer take a look as soon as he can, this info is really great to know!

[Robin W]

glad that I can help ! do come back and let us know how you get on – plenty of people search for similar issues, so these post help others

[Gomle]

Thank you for the detailed posting of this.
I am having the same problem now.
Forum is imported from SimplePress. All old threads from SP with new replies misses the /page/.

If anyone reads this and know how to fix it, please give me a heads up 🙂