[wp-meta] [Making WordPress.org] #6443: /page/2/ being adding to reply links incorrectly

[Making WordPress.org]

#6443: /page/2/ being adding to reply links incorrectly
----------------------------+---------------------
 Reporter:  sterndata       |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  high            |   Milestone:
Component:  Support Forums  |  Resolution:
 Keywords:                  |
----------------------------+---------------------

Comment (by dd32):

 Unfortunately `bbp_update_reply_position()` doesn't completely do the
 trick here it seems.

 It turns out this is a deeper problem than I thought.. In addition to the
 problem where a reply simply no longer exists (ie. fully deleted), when
 threads are spam or archived, they still occupy a reply ID, and so the
 problem is that the URL pagination generation is unaware of some replies
 not being visible to non-moderators.

 https://wordpress.org/support/topic/smileys-not-working-on-mobile/ is now
 an example of that. The 15th reply is archived, and so when it's not being
 viewed by a moderator with `?view=all` the 15th reply (last reply on the
 first page) has a `/page/2/` url.

 Either
  1.
 [https://github.com/bbpress/bbPress/blob/30e07f8415e5eab14cd08b042a1b394bbbc654df/src/includes/replies/template.php#L425-L458
 bbp_get_reply_url()] needs to handle the reply id being incorrect OR
  2.
 [https://github.com/bbpress/bbPress/blob/bbde786798c47b61f1ef87bd049224f351458b7b/src/includes/replies/functions.php#L2317-L2357
 bbp_get_reply_position_raw()] needs to change to not give reply IDs to
 hidden replies.

 The problem with these is that with `1` it means iterating over all
 replies prior to the reply in the thread to determine how many are hidden
 (..or missing?), and lower the reply_id by that many, and with `2` is that
 when a moderator is viewing it, the reply_ids need to be in the correct
 order to render the replies in the correct order. `1` would also mean that
 the links would be incorrect for moderators (but that's okay I guess).

 As much as it seems like a performance hit, `1` is the obvious choice by
 filtering `bbp_get_reply_url`, I guess we can get away without much of an
 impact by only checking when the URL is `>= /page/2` as replies on the
 first page aren't affected. The replies should be being displayed anyway
 so should also be cached in memory already.

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/6443#comment:20>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org