[wp-trac] [WordPress Trac] #27111: Turning off global comments should include existing content

[WordPress Trac]

#27111: Turning off global comments should include existing content
-------------------------+-----------------------------
 Reporter:  jenmylo      |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Future Release
Component:  Comments     |     Version:  trunk
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  administration
-------------------------+-----------------------------
Changes (by nacin):

 * milestone:  3.9 => Future Release


Comment:

 This is not an easy problem to solve. The main issue comes down to the
 fact that comment_status is really more than two states. Rather than just
 comments being open and closed for a particular post, they can also be:

  * Closed after a set period of time, something we already handle.

  * Closed site-wide. What happens to existing posts? It's easy to just
 close all of them (using a filter, not even a DB query) but then what
 about future posts? Comments should be off by default, but what if someone
 wanted to enable comments for a particular future post? And then how does
 that affect existing posts?

 I hate the idea of a checkbox that triggers an irreversible DB action. But
 without the DB action there wouldn't be a way to do this, without an
 additional state. (Which is possible but probably not doable from a
 compatibility perspective.)

 So at that point here is the implementation I kind of envision:

  * You currently have a mix of posts. Some are 'open', some are manually
 'closed', some are in the DB as 'open' but are treated as 'closed' by a
 filter after a set period of time.

  * You want to disable comments by default for all future posts. Great,
 those posts get a default of 'closed', rather than 'open'. No problem,
 that works now.

  * You want to disable comments by default for all current posts, too. How
 can we do that without forcibly updating all of them to be 'closed'? Store
 a timestamp in the option. If the post date is earlier than that
 timestamp, then it's 'closed'.

  * What if you then want to go back and set one of those posts to 'open'?
 This, I am not sure about. This is where forcibly updating the DB would
 have been easier, as there's no transient state then. We would need to
 come up with a new status 'override-open' which forces it to be open, even
 though a filter has dictated it to be closed.

 An alternative is actually running a DB query to set all existing posts
 (of a particular type, surely) to comment_status = 'closed'. There would
 be no "undo" for this unless we query for every post ID we're about to
 update (for which there could be hundreds of thousands or millions) is
 then saved somewhere. A new meta value on every post is probably
 prohibitive; it'd need to go into an un-autoloaded option that can then be
 used for some sort of "undo". Or, they get a "This cannot be undone
 without doing a really annoying bulk edit" or something.

 I would love, love, love to re-do discussion settings, clean it up,
 separate things out by type, and make all of this happen. But it's not
 going to happen for 3.9.

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