bbPress Reply [Title+Slug+Link] Logic !

[alex-ye]

Hi, I think the title is so general but it's good for what I want to discuss.

I really like bbPress and many staff in it, I love it simplify and performance but I am not feel good with the current bbPress replies title/slug/permlink logic !

Why ?

At first I want you to understand the bugs that I faced with the current logic.

1- Reply title is not dynamic:
As you know the current bbPress replies structure is "Reply To: %topic_title%" and saved in the database, but what if I change the topic title ? The reply title should be change too, but this what it doesn't happened because it will cost the sever performance a lot !

2 - Post a new reply is too slow :
It's true, when you post a new reply in a topic it might be too slow because it runs many queries, as n example did you tried to post a new reply in a topic had a "1000" reply ? you will be surprised !!

as you know the reply title is the same for every reply in each topic, the reply slug is the same !, So WordPress loop thought all replies just to make the reply slug unique !!

and this makes bbPress stuck when it handle a topic with many replies !

3 - The reply permalink isn't cool
I am thinking that the current reply URL structure isn't excellent, It's good that it's support the pretty permalinks , but do we need this, really?

/?reply=reply-to-topic-46
/reply/reply-to-topic-46

I think it's fine to be just like that:
/?reply=109
/reply/109

So when you move the replies or change the topic title the reply URL will not be broken !, The reply URL should be more flexible :)

How I suggest to solve all this ?

After all, I believe that we should take care of backward compatibility and the respect the user choices, so the fix should be so easy.

The key to solve all this is to have an empty reply title in the database ! WordPress support now the empty post title, So this can help us to make the replies logic better, and having an empty reply title will help us to do this:

1- The reply slug will be the reply ID (WordPress do this automaticly) so posting a new reply will be more faster and reply permlinks will be shorter !

2- The reply title could be dynamic :)

3- Search result will be better !
Try to search by a topic title in the bbPress search form, You will find that all the topic replies is in the results !, and the topic it self is in the last page !

hope to listen to your opinions :)

[alex-ye]

For who like the idea please test the first-draft patches above :)

[alex-ye]

Done in the second patches:

1- Remove the $fallback_to_topic_title parameter, I think it was so tricky !

2- Remove the hidden reply title input form the edit screen.

3- a less codes :)

I left the $_POSTbbp_reply_title? checks because compatibility, and for any theme/plugin need to make a custom reply title.

[johnjamesjacoby]

Seems like a neat change for 2.4. Moving to 2.4 to look into this more then. Thanks for the patches. These all make sense, and seem like good ideas for the future.

[johnjamesjacoby]

No time. Moving to 2.5 and tagging early.

[alex-ye]

Third Draft

[alex-ye]

The patch is refreshed now, I think we will have enough time to test in the beta versions.

[johnjamesjacoby]

Updated for latest trunk

[johnjamesjacoby]

Patch looks good to me. Undecided if we should make this change, but the code works well.

[johnjamesjacoby]

In 5177:

When creating new replies, do not force them to have a title. This is new as of WordPress 3.7, to be more accommodating to post formats that don't cater to titles very well (image/status/video/etc...)

Until now, replies to topics have always shared the topic title (and incremental slugs) in common with each other. With this change, replies will now mostly be identified via their post ID. This helps with search results, and avoids some reply-slug confusion as to why they need to have titles or slugs at all.

Props alex-ye for the clever solution. Fixes #2291.

[johnjamesjacoby]

In 5178:

Move filter adding higher up in filters.php. See #2291.

[johnjamesjacoby]

In 5179:

Bump priority from 1 to 2, to give some wiggle room for third party developers. See #2291.