Turning off global comments should include existing content

[jenmylo]

People get confused when they turn off comments on a site, but continue receiving comment notifications. When a user sets the discussion setting to no longer allow comments to be posted to articles, it should turn off new comments on existing posts as well, not just new ones.

​http://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2014-02-12&sort=asc#m790178

[SergeyBiryukov]

Previously: #4222

[jackreichert]

Provides functionality for global comments flag.

[jackreichert]

While the IRC discussion seems to imply that fulfilling this ticket should implement function that goes and turns off comments for each post, I thought that perhaps, instead, a new options flag may be cleaner. I tend to prefer to provide options that are not irrevocable. Switching all comments off, one post at a time, is hard to undo.

The attached patch sets up a new option in the options table similar to 'default_comment_status' but would be global.

The only thing missing from the patch is the line:

INSERT INTO  `wordpress`.`wp_options` (`option_name` , `option_value`)
VALUES ('global_comment_status',  'open');

I wasn't sure where/how to add that to the patch.

[nacin]

#12521 was marked as a duplicate.

[obenland]

Added a patch that piggybacks off of _close_comments_for_old_post|s as mentioned in IRC a while back. Additionally makes the label indicate that it toggles status for all articles, not only new ones.

I was not sure how handle the old brace style in new patches. Do we update only in new code, or in the entire function we change?

How set are we on disabling other settings based on the value of default_comment_status?

[celloexpressions]

Replying to obenland:

How set are we on disabling other settings based on the value of default_comment_status?

Based on the direction this is going, I think we can do the following:

• Toggle-hide the rest of the comment-related settings on the discussion settings page.

I'm not totally clear on this, but I believe it makes sense for this setting to NOT be able to be overwritten on individual posts/pages. If that's the case, in addition to removing the note that says that it can be changed on a per-post basis, we should also hide:

• "Allow comments" checkbox in QuickEdit
• Allow comments in Discussion metabox

If there are also no existing comments, then we can hide:

• The comments admin menu item
• The comments toolbar item
• Comments metabox

This essentially hides the entire commenting feature from core, which would be very nice for all those that don't use it (quite possibly a majority).

[SergeyBiryukov]

#17478 was marked as a duplicate.

[SergeyBiryukov]

Replying to celloexpressions:

Based on the direction this is going, I think we can do the following:

• Toggle-hide the rest of the comment-related settings on the discussion settings page.

Related: #22198

[SergeyBiryukov]

Related: #12991

[celloexpressions]

Replying to obenland:

How set are we on disabling other settings based on the value of default_comment_status?

Actually, I think there are two possible approaches: making this option actually turn comments completely off in WordPress (hiding everything; some conditionally if there are existing comments), or allowing them to be turned on for individual posts, in which case I don't think we can hide anything. I think being able to completely turn everything off is the much more common use-case, and allows us to hide a lot of unnecessary UI too. That does go somewhat against the current system, though.

The question, really, is whether it's more useful to have a global default status for comments, or to have a global setting to enable comments at all, where individual posts could disable them as needed. If you're turning off comments on everything, should you be able to turn them back on for certain posts, or should we hide the feature entirely?

Once we figure out the direction here, adding per-post-type support would be a great next step (#12991).

[kirasong]

I like the idea of hiding interface if we do make it a global toggle.

That said, since we're this close to 3.9 beta, if that's consensus, I'd suggest a punt so that we can get it right.

obenland: My understanding on the new braces rule is to handle them similarly to whitespace/formatting corrections. If it's a section that's getting modified by a patch, fix 'em up. If it's entirely outside, then avoid changing and causing churn.

[nacin]

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.

[jackreichert]

Replying to nacin:

• 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.

It the patch I submitted above (#comment:3), instead of changing the functionality of default_comment_status, I added an extra option to the options table: global_comment_status. This way you can close off all comments but it wouldn't effect the specific comment's status.

That solves two problems:
1) Changing the functionality of something that people are expecting to something else.
2) Allowing an undo option.

Just a thought.

[knutsp]

When comments are globally off it should just disable the comment functionality all together. No other comments options visible, no built-in comments widget, no post-boxes for comments or discussion. Only exception: The then hidden default comment status will be used as before when determining if the comment status should be open or closed in the DB.

When turned on again, all is back as is was before turning it off. Posts added while comments was turned off would have their status determined by the setting of default comment status as seen before comments was turned off.

[mor10]

We've discussed this at length in the #core-flow NUX group and there is strong consensus that a toggle switch for turning comments hard on and off is needed for new users. Currently there is no clear way for a new user to simply say "I don't want any comments on my site at all". That is problematic.

I agree with all of Nacin's points above, but I don't see an inherent conflict between a global on/off switch and any of the scenarios outlined. In my mind this global switch would sit at a higher level and simply either block all commenting functionality, past and future, or open the options for further detail control. It should not change the status of any existing posts but rather block the ability to add comments at a higher level.

This of course begs the question if disabling comments means actively hiding all previous comments as well as disabling the comment submission form. I'm inclined to say yes. The user need seems to be a simple method for not having comments at all. If they want to be nitpicky about which posts/pages have comments or not they are not looking for a global disable but rather detailed control which is what we have now.

And yes, this might be a bit OT for this ticket. If so let me know and I'll create a new one.

[6templates]

I totally agree with this. For those who don't want any comment functionality at all on the site, there needs to be a kill switch. It's not a complicated thing as people make it out to be, when you are talking about users who want a site to be free from comment functionality.

Replying to mor10:

We've discussed this at length in the #core-flow NUX group and there is strong consensus that a toggle switch for turning comments hard on and off is needed for new users. Currently there is no clear way for a new user to simply say "I don't want any comments on my site at all". That is problematic.

I agree with all of Nacin's points above, but I don't see an inherent conflict between a global on/off switch and any of the scenarios outlined. In my mind this global switch would sit at a higher level and simply either block all commenting functionality, past and future, or open the options for further detail control. It should not change the status of any existing posts but rather block the ability to add comments at a higher level.

This of course begs the question if disabling comments means actively hiding all previous comments as well as disabling the comment submission form. I'm inclined to say yes. The user need seems to be a simple method for not having comments at all. If they want to be nitpicky about which posts/pages have comments or not they are not looking for a global disable but rather detailed control which is what we have now.

And yes, this might be a bit OT for this ticket. If so let me know and I'll create a new one.

[SergeyBiryukov]

#32375 was marked as a duplicate.

[Another Guy]

I enter ticket 32375 and was noted as a duplicate. I agree it may be a duplicate, but I considered that this ticket (27111) has been dragging on for a couple of years and a new approach is really needed to deal with this one.

Nacin raises good points, but honestly, they are a bit of a red herring. A global On/Off switch (and matching API call for comments_disable in the loop) is much more for either a fresh install or for someone (or some company) deciding that they do not want to deal with comments on their site at all. Perhaps they have a different feedback system in place (submit feedback page, example) and just don't want the confusion.

That someone would turn off comments on an existing blog with valid comments could be an issue, but it brings up the bigger question of "why would they do it?". They are perhaps yearning for a second way to turn off all comments on old posts or to otherwise freeze existing comment streams so people cannot add onto them. It's not very intuitive to turn off comments on old post and pages at this point, and I agree with 6Templates, that is perhaps a different discussion and a different ticket.

I would also want to make a global on off switch go one step further, which is to shut off all of the incoming comment processing. If someone attempts to post a comment directly (by directly posting to wp-comment or similar) they should just be "denied". It would be very beneficial for display style sites (sites with no provision for comments in their designs or mission) to be able to not have to deal with any comments, track backs, or other connections to their server that are unwanted. Right now, turning off comments (by setting them to lock comments after 1 day, example) still leaves a site open to handle all of the income spam... and no matter how good Akismet is, enough of it gets through to clog up most sites. If your site isn't intended to have comments, there should be a way to make it so that attempts to add unwanted comments are denied before they happen.

It's really something that needs to happen, it's a demand I am seeing more and more from commercial users who don't want to have to maintain their sites on an hourly basis.

[Another Guy]

I just to add for discussion this point: Akismet (on a commercial level) is one of the ways that wordpress "commercializes" the free wordpress product. I can understand that disabling comments by definition also renders that plug in moot. It is perhaps a bigger question they just turning off comments, it'a also about how that effects the business model of Wordpress. At the same time, the comment issue (comment spam and handling) is enough of an issue that commercial clients are asking for alternate solutions to wordpress. I would rather use wordpress for all sorts of reasons, but the point of turning off comments and otherwise disabled any third part access beyond viewing the site is coming up more and more often.

[Stagger Lee]

• Post listing
• Screen Options
• Increase "Number of items per page"
• Mark all posts
• Bulk Actions - Edit
• Comments - Do no allow

One way process. Is it so difficult ? Is it better they lose time on something else improving in the core.

This snippet remove all comments, even old comments, and any comment instance, form. etc:

// Disable support for comments and trackbacks in post types
function df_disable_comments_post_types_support() {
	$post_types = get_post_types();
	foreach ($post_types as $post_type) {
		if(post_type_supports($post_type, 'comments')) {
			remove_post_type_support($post_type, 'comments');
			remove_post_type_support($post_type, 'trackbacks');
		}
	}
}
add_action('admin_init', 'df_disable_comments_post_types_support');

// Close comments on the front-end
function df_disable_comments_status() {
	return false;
}
add_filter('comments_open', 'df_disable_comments_status', 20, 2);
add_filter('pings_open', 'df_disable_comments_status', 20, 2);

// Hide existing comments
function df_disable_comments_hide_existing_comments($comments) {
	$comments = array();
	return $comments;
}
add_filter('comments_array', 'df_disable_comments_hide_existing_comments', 10, 2);

// Remove comments page in menu
function df_disable_comments_admin_menu() {
	remove_menu_page('edit-comments.php');
}
add_action('admin_menu', 'df_disable_comments_admin_menu');

// Redirect any user trying to access comments page
function df_disable_comments_admin_menu_redirect() {
	global $pagenow;
	if ($pagenow === 'edit-comments.php') {
		wp_redirect(admin_url()); exit;
	}
}
add_action('admin_init', 'df_disable_comments_admin_menu_redirect');

// Remove comments metabox from dashboard
function df_disable_comments_dashboard() {
	remove_meta_box('dashboard_recent_comments', 'dashboard', 'normal');
}
add_action('admin_init', 'df_disable_comments_dashboard');

// Remove comments links from admin bar
function df_disable_comments_admin_bar() {
	if (is_admin_bar_showing()) {
		remove_action('admin_bar_menu', 'wp_admin_bar_comments_menu', 60);
	}
}
add_action('init', 'df_disable_comments_admin_bar');

[jackreichert]

Replying to Stagger Lee:

I was inspired by your code snippet and created this plugin: [Global Toggle Comments](​https://wordpress.org/plugins/toggle-comments/) Enjoy!

[Another Guy]

Stagger Lee, would that code disable wp-comments.php and make it return 404, 403, or similar?

[Stagger Lee]

I dont know how to test it.

[Stagger Lee]

Math Captcha plugin is using this code in .htaccess to block it.

# BEGIN Math Captcha
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post.php*
RewriteCond %{HTTP_REFERER} !.*localhost.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) ^http://%{REMOTE_ADDR}/$ [R=301,L]
</IfModule>
# END Math Captcha

"localhost" needs to be changet to domainname: "www.some-website.com"

[Stagger Lee]

Math Captcha has functions.php snippet for this .htaccess code. I could not see it is for overwriting own code inside .htaccess.

Is it possible to use .htaccess code inside functions.php ? How it goes with priority ?
I am asking because it would be nice to use this snippet in functions.php. Hate when .htaccess gets overwritten when you click Save in permalinks options.

This is code from Math Captcha:

public function block_direct_comments($rules)
	{
		if(Math_Captcha()->options['general']['block_direct_comments'])
		{
			$new_rules =
<<<EOT
\n# BEGIN Math Captcha
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post.php*
RewriteCond %{HTTP_REFERER} !.*{$_SERVER['HTTP_HOST']}.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) ^http://%{REMOTE_ADDR}/$ [R=301,L]
</IfModule>
# END Math Captcha\n\n
EOT;

			return $new_rules.$rules;
		}

		return $rules;
	}

More here:
​https://github.com/tamagokun/pomander-wordpress/blob/master/lib/generators/htaccess.php
​https://github.com/artzstudio/hoshinbudo.com/blob/master/wp-content/plugins/w3-total-cache/lib/W3/SharedRules.php

---

Edit: I see now $rules is in the core for .htaccess management. Yes, would it be very stupid if functions.php had priority over .htaccess.

[Another Guy]

I think that the ability to turn off "direct" comments would be a very good start, and perhaps is something that could be looked at to try to trip up the most obvious abusers of the comment system. It would be a benefit to everyone (including Automattic) as they would not have to filter out anywhere near as much direct post spam.

[SergeyBiryukov]

#53185 was marked as a duplicate.

[jb510]

Two plugin solutions for disabling comments ​https://wordpress.org/plugins/disable-comments/ and ​https://wordpress.org/plugins/disable-comments-rb/ have been taken over by new developers and quickly turned into a bloated mess. Nobody needs a web app built into their dashboard just to "disable comments".

Usually, these ancient tickets seem like a lost cause though. Is there any hope for a patch for this actually making its way into core at this point?

[peterwilsoncc]

Replying to jb510:

[snip]
Usually, these ancient tickets seem like a lost cause though. Is there any hope for a patch for this actually making its way into core at this point?

Honestly, I think it unlikely.

My view is that the option is fairly clear that the setting is the default for new posts.

Changing how the option works to apply to all posts would break backward compatibility and become problematic for sites deliberately choosing to enable comments on some posts. My specific thought is news-type sites which enable comments on analysis articles but not general news articles.

Adding an additional "all posts" option seems unhelpful for a couple of lines of code. I'll see if I can get ​this in the repo to leave neglected and forget to update the supported version for. ;)

I'm going to close this as wontfix to match the reality given there has been no movement for seven years.

[jb510]

@peterwilsoncc this was marked a duplicate of #32375 and #53185 which is why I commented here. Although those tickets are a bit more clear about what I think is generally needed: A check box to disable all comment functionality sitewide.

The point here is there ought to be a core method to completely disable comments on a site (brand new site or otherwise) and not rely on the increasingly spammy plugins to do so. The other tickets were a bit more clear about this need than this ticket.

I think we all understand a huge number of sites these days have zero need for comments at all. This means no need to accept comment spam requests to the API, no need to count comments, no need really to load even 1 line of comment-related code or make queries looking for comments. I'd assume there would be a decent performance gain from some of this.

On many sites, comments are more of an attractive nuisance than something anyone wants to manage. Or they're disabling WP comments in favor of sass solutions like Disqus.

Comments were unquestionably a unique and huge benefit in the early blog-focused days of WordPress. They're not obsolete on all sites (like links became), just obsolete on a lot of sites.

[audrasjb]

#57735 was marked as a duplicate.