[wp-trac] [WordPress Trac] #18603: Comments on pages which exceed paginate settings create erroneous permalinks

WordPress Trac noreply at wordpress.org
Sun Dec 6 22:00:10 UTC 2015


#18603: Comments on pages which exceed paginate settings create erroneous
permalinks
-------------------------------------------------+-------------------------
 Reporter:  msagman                              |       Owner:
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  Future
Component:  Comments                             |  Release
 Severity:  normal                               |     Version:  3.2.1
 Keywords:  needs-patch needs-testing good-      |  Resolution:
  first-bug                                      |     Focuses:
-------------------------------------------------+-------------------------

Comment (by ambrosiawt):

 I uploaded a patch to demonstrate what I thought would solve at least part
 of the problem, but I've changed my mind about this... I was thinking that
 it looked pretty simple and the purpose of what I was removing was not
 necessary due to code before it.  Now I think that it's not so simple.  :)

 I do want to explain where my head is at, however, since I was after a
 specific purpose here.  The situation that we're having here is certainly
 that in some cases we can have values in the parent column, for example if
 you have threaded comments on, and after a while decide to turn them off.
 When the setting is changed, none of the rows with a value in the parent
 column are changed, just the behavior of how the comments are treated (all
 threaded items become top level).

 I don't think it makes sense to change those rows.  For example, if
 someone turns threading off, and then realized they didn't mean to make
 that change, turning it back on should retain the original threading data,
 which means the parent column in those rows needs to be retained.  If
 others think differently, please comment.

 That said, it seems like for this piece of code we could just drop the
 parent=0 from the query, but it doesn't solve the whole problem and seems
 to be problematic still.  I may try another patch shortly.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/18603#comment:21>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list