[_ck_]

Okay we need to see if the query is failing somehow.

try this (assuming the table is bb_posts)

SELECT topic_id, COUNT(post_status) as topic_posts FROM bb_posts WHERE post_status=0 AND topic_id=12

See if that gives 80 or 81

Then try this if that gives 81

SELECT topic_id, COUNT(*) as topic_posts FROM bb_posts WHERE post_status=0 AND topic_id=12

(sorry I forgot to add AND topic_id=12)

[_ck_]

Interesting – did you say you know how to use phpmyadmin? or no?

The “no deleted posts to count” is disturbing – that is wrong.

You definitely deleted post 24 on that topic right?

[_ck_]

You’ve definitely done a recount in the admin section?

Because the 81 on the topic list is very wrong.

Do a recount in the admin.

If it still shows 81, I want you to delete one of those last filler posts you made and then undelete it. That will force a recount.

[_ck_]

Okay I see the problem now with the next page link on page 4, which takes it to an empty page.

That in theory is a slightly different problem.

We can see that bbpress thinks there are 81 posts (visible) in the topic.

And there are 20 posts per page on the default setup.

So yeah, there should be a page 5.

Somehow post 81 is showing on page 4

page 1: 1-20

page 2: 21-41 <<<< mistake, post-position 24 is missing

page 3: 42-61

page 4: 62-81

Something started going wrong on page 2 I think?

It should start at 21 and go to 40.

Let me go back and look at that.

Yup, there is a gap for 23-25

That means that number count is showing post-position and 24 has been deleted.

So the example I show above with the pages, imagine post 24 is post 4 from the example.

bbPress is being stupid and rounding up for some reason.

There aren’t 81 posts in the topic, there are 80.

[_ck_]

I have a little trick to workaround this problem, at least when bbpress requests a link for the post that happens to be the last post in the topic.

I will write a filter for when get_post_link is requested, it will check the post id# – if it happens to be the last post in the topic (stored in topic_last_post_id) it will instead route the request to the more accurate get_topic_last_post_link

[_ck_]

Here’s a simplified example of what I think is happening internally.

Let’s say for ease of understanding there are TWO posts per page.

And there are 7 posts in this particular topic example

|1 2| – |3 4| – |5 6| – |7|

so there are 4 pages (each | | is a page)

In this example, the post numbers are also the post-position.

Now let’s say a mod deletes post number 4

|1 2| – |3 5| – |6 7|

Should only be three pages.

But bbPress is stupid by default, post-position is never recalculated so those post numbers still represent post position in this example.

bbPress DOES track number of posts in a topic, even when deleted.

So requesting a link to the last post in the topic, regardless of post-position, WILL be calculated correctly, and return page 3.

However, if it specifically asks for a direct link to post 7 and not the last post in the topic, this is what happens.

Post 7 is post-position 7

posts per page is 2 per page

ceil( $post_position / $per_page )

7 / 2 = 3.5, ceil of 3.5 = 4

So it will ask for page 4

Page 4 does not exist in the topic.

The link may be created but the link is bogus and will not work, it will either return you to the first page of the topic, or maybe the front page of the entire forum.

[_ck_]

I need to see this problem in action.

If you can, put another post on there to trigger it?

[_ck_]

You know what, this is an inherit flaw with bbpress that I think I mentioned elsewhere years ago.

It never recalculates post-position when there are deleted posts, yet it relies on that post-position to find a specific posts’s page.

See this is how it calculates the page

function get_post_link( $post_id = 0 ) {

$bb_post = bb_get_post( get_post_id( $post_id ) );

>>>>>>	$page = bb_get_page_number( $bb_post->post_position );

return apply_filters( 'get_post_link', get_topic_link( $bb_post->topic_id, $page ) . "#post-$bb_post->post_id", $bb_post->post_id );

}

and this is how it calculates that page

return intval( ceil( $item / $per_page ) );

so it’s $bb_post->post_position / $per_page

always, regardless if there are deleted posts in the way, which is why it can be “short” when calculating the last page(s) on a longer topic with deleted posts.

The solution is that post-position has to be recalculated when a post is deleted. The only side effect is that for admin, jumping directly to a deleted post would not work, you’d have to find it manually.

bbPress never, ever, re-calculates post-position, even on a recount, if I am not mistaken.

There is one tiny work-around we can do.

For the LAST POST calculation, we can intercept that and subtract the number of deleted posts from the post-position. Hmm, actually wait, is it subtract or add. I have to investigate this a bit and think out the logic.

[_ck_]

I must be missing the problem here.

The “latest reply” link works.

When I am on page 3, the page 4 link works.

What specifically is not working?

Are you saying the problem is intermittent?

ps. I use an ebike with a custom lifepo4 battery

Oh wait, I see what you saying now

he problem vanished when one reply was written.

It will reappear when someone writes a reply last on that page.

so it’s an even/odd problem

if there are an even number of posts, it works,

if there is an uneven number, it does not work

Did you try the trick of deleting one post and then undeleting it?

There must be a bug in the way bbPress calculates post-position when there are deleted posts. I wonder if it’s specific to 1.x

[_ck_]

Are you using the topics per page plugin?

[_ck_]

Did you do a recount?

[_ck_]

Yes but what happens when you try to jump directly to a specific post.

bbPress doesn’t know the order of the posts so unless you change it with a filter, it will never return the person back to their own post.

If you only have a single page of posts the problem is avoided, but try it on a topic with three pages of posts.

[_ck_]

Mods have no control over that and I highly doubt admin will bother because of display names giving you the ability to rename anyone to anything else.

Asking on bbpress.org is probably also a bad idea, use the more highly trafficked wordpress.org

[_ck_]

For those not familiar with BuddyPress or how it uses bbPress, let me give you a quick example.

Here is a typical BuddyPress group’s discussion area (without forums it’s just a group of bloggers which also can be done with basic buddypress but it’s boring)

http://culturadigital.br/groups/banda-infinnita/forum/

Here it is natively inside the bbPress engine:

http://www.culturadigital.br/forum/forum.php?id=151

If you look back on their bbpress front-page you can see how all the groups are exposed as individual forums. This is how buddypress needs bbpress.

(I have no association at all with that site, it’s just a rare example of behind the scenes – unfortunately this kind of demo is not possible on most buddypress sites because JJJ has learned over time to “lock down” bbpress to prevent direct examination)

BuddyPress doesn’t need the bbPress front-end, at all. But it desperately needs the backend. And JJJ needs that backend to be faster and not have to load it’s own core. So by switching it to use WordPress’s core, buddyPress will be faster.

ps.the buddypress version of the forum takes FIVE times longer to render than the bbpress version – I’m not talking about the time to send the extra images on the page, I’m talking just server time to render the page. And that’s against bbPress 1.0, not 0.9

[_ck_]

@frooyo

Yes that is why forks of bbpress would be wise to start with 0.9

[_ck_]

Same question by two people on the same day?

https://bbpress.org/forums/topic/making-the-newest-posts-show-up-first

[_ck_]

Let me clarify for those that don’t follow.

BuddyPress is JJJ’s pet project.

Buddypress relies on WordPress, currently it’s technically a “plugin” to WordPress.

Buddypress (pre-1.3) uses bbpress standalone to manage it’s groups by using bbpress’s engine to manage forums (buddypress “groups” technically are forums with specific memberships to limit who can post to where).

JJJ sees that there are far too many layers and way too much code being loaded which is making buddypress too slow. So his plan is to more closely tie bbpress into WordPress, making buddypress faster.

His motivation is not to improve bbpress for the sake of making bbpress better. He doesn’t need the front end of bbpress at all for buddypress. He already manages it through buddypress.

So by reinventing bbpress to use wordpress’s core, he can cut out some of the bulk and make buddypress faster. BuddyPress is currently very slow and bulky unless you have a decent server and good caching setup.

Taking control of bbPress is a side project to help buddypress for JJJ and he’ll never convince me otherwise about his motivations.

Note I am NOT saying you won’t be able to run bbPress without buddypress, of course you will be able to (because that’s even less complicated) But that’s not his motivation or priority, at all.

@frooyo

0.7-0.9 bbPress standalone, high speed core independent of WP

1.0-1.1 bbPress relies on backpress core, which uses WP functions (150% larger)

1.2/2.0 bbPress relies on WordPress 3+ for it’s core (200% larger)

If you think hooking into the bulk that is WP 3.x is going to make bbPress faster, well there’s going to be a mighty big wake up call sometime soon. It will make page caching easier, but that’s good because it’s practically going to be a requirement.

JJJ’s only motivation to do this is because his pet buddypress project relies on the bulk of WP so the logic is might as well force bbPress to also.

TL;DR bbPress rewrite makes buddypress faster but bbpress by itself slower than 0.9/1.1

[_ck_]

Y’all don’t seem to notice that JJJ is mostly rewriting bbPress so it will work better with buddyPress specifically.

So bbPress 1.2 (please call it 2.0) being reinvented is tied directly to buddyPress 1.3

If you want clues, I’d be looking at buddyPress 1.3 release dates, not any specific commitments to bbPress itself.

https://trac.buddypress.org/milestone/1.3

Unless they are going to sweep a great deal of tickets under the rug (which happens often with WordPress so it’s not impossible with BP either) you’ve got a bit of a wait.

The key to understanding what is happening is that buddyPress is his pet project and bbPress is used as the internal engine for buddyPress groups. So if he rewrites one, has has to rewrite the other.

I didn’t completely realize this until I recently started studying what had changed in buddypress to understand why JJJ wanted to hijack bbPress. buddypress right now is essentially bloatpress and what he is doing to bbpress is specifically for his own ends to reduce BP bloat, not for the general good of bbpress users.

There are about 1000 (active) sites using bbpress inside of buddypress, so bbpress standalone is essentially being waylaid for those sites.

[_ck_]

Note however you can easily make a link to the last post in any topic and for example make the “last poster” column link directly to that post.

That question has been asked and answered several times around here.

[_ck_]

While I won’t say it’s impossible, doing this currently with bbpress is difficult because of how everything internally is geared for newest last.

The post_position and other issues make this tricky. Even something as basic as jumping to the current post becomes a problem and has to be worked around.

Matt just didn’t think of anyone desiring it any other way when he first coded things in bbpress and now it’s legacy.

This is something I plan to address in a future (forked) version as well as parent/child threading. I’ve actually already accomplished it using plugins for a specific client but it’s overly complex and non-standardized.

[_ck_]

The wordpress plugin would have to be adapted for bbpress.

[_ck_]

https://bbpress.org/plugins/topic/mass-delete-users/

and this plugin will let you create domain blacklists I think

https://bbpress.org/plugins/topic/restrict-registration-for-bbpress/

or blocklist allows you to block based on email as well

https://bbpress.org/plugins/topic/blocklist/

[_ck_]

also, this is a better way to link your PDF, even foxit has security issues from time to time and people have to be insane to use adobe with it’s exploit-of-the-month

https://docs.google.com/gview?url=http://kevinjohngallagher.com/downloads/I_want_to_fork_bbPress.pdf

[_ck_]

I totally agree that _ck_’s involvement is crucial.

Y’all don’t need me. I highly encourage you to keep going with the fork and there doesn’t have to be just one fork.

Remember, WordPress itself is just one (big) fork (of b2evolution).

I’ll be taking a sabbatical for the rest of the year starting next month or so as I have serious real-life things to deal with, and then *maybe* announcing my own project next year in the spring. Instead of a fork it will be a 50% or more rewrite of the entire core, fixing a few legacy problems. But it would not be available to the public for at least a year from now at the soonest and it won’t be fully backwards compatible.

It literally took me three years but I kinda figured out an indirect way of doing something like this. Part of the solution is so simple that I guarantee WordPress will “steal” the idea within six months of me publishing the code because it’s backwards compatible and a great idea that no-one else apparently has thought of yet for some mysterious reason. I’ve already tested a proof-of-concept and it’s one of those things that once you see it, everyone says “well that’s so simple anyone could have thought of it”. But no one has, yet.

[_ck_]

Looking good!

Now just put some margin on your #content box (for bbpress) and it will be set, ie.

#content {margin:0 50px;}

unless you want it to touch the sides.

Isn’t it great how easy bbpress can be shoved into existing pages?