WordPress.org

Make WordPress Core

Opened 17 months ago

Last modified 3 weeks ago

#27111 new enhancement

Turning off global comments should include existing content

Reported by: jenmylo Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.9
Component: Comments Keywords: has-patch
Focuses: administration Cc:

Description

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

Attachments (2)

global-comments-off.diff (4.0 KB) - added by jackreichert 17 months ago.
Provides functionality for global comments flag.
27111.1.diff (2.9 KB) - added by obenland 16 months ago.

Download all attachments as: .zip

Change History (31)

comment:1 @ircbot17 months ago

This ticket was mentioned in IRC in #wordpress-dev by jenmylo. View the logs.

@jackreichert17 months ago

Provides functionality for global comments flag.

comment:3 @jackreichert17 months ago

  • Keywords has-patch added; needs-patch removed

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.

comment:4 @nacin17 months ago

#12521 was marked as a duplicate.

@obenland16 months ago

comment:5 follow-up: @obenland16 months ago

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?

comment:6 @ircbot16 months ago

This ticket was mentioned in IRC in #wordpress-dev by obenland. View the logs.

comment:7 in reply to: ↑ 5 ; follow-ups: @celloexpressions16 months ago

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

comment:8 @SergeyBiryukov16 months ago

#17478 was marked as a duplicate.

comment:9 in reply to: ↑ 7 @SergeyBiryukov16 months ago

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

comment:11 in reply to: ↑ 7 @celloexpressions16 months ago

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

comment:12 @ircbot16 months ago

This ticket was mentioned in IRC in #wordpress-dev by DH-Shredder. View the logs.

comment:13 @DH-Shredder16 months ago

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.

comment:14 follow-up: @nacin16 months ago

  • Milestone changed from 3.9 to Future Release

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.

comment:15 in reply to: ↑ 14 @jackreichert16 months ago

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.

Last edited 16 months ago by jackreichert (previous) (diff)

comment:16 @knutsp16 months ago

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.

comment:17 follow-up: @mor104 months ago

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.

comment:18 @slackbot4 months ago

This ticket was mentioned in Slack in #core-flow by mor10. View the logs.

comment:19 in reply to: ↑ 17 @6templates4 months ago

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.

comment:20 @SergeyBiryukov8 weeks ago

#32375 was marked as a duplicate.

comment:21 @Another Guy8 weeks ago

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.

comment:22 @Another Guy8 weeks ago

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.

comment:23 follow-up: @Stagger Lee8 weeks ago

  • 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');

comment:24 in reply to: ↑ 23 @jackreichert7 weeks ago

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!

comment:25 @Another Guy7 weeks ago

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

comment:26 @Stagger Lee7 weeks ago

I dont know how to test it.

comment:27 @Stagger Lee7 weeks ago

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"

Last edited 7 weeks ago by Stagger Lee (previous) (diff)

comment:28 @Stagger Lee7 weeks ago

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.

Last edited 7 weeks ago by Stagger Lee (previous) (diff)

comment:29 @Another Guy3 weeks ago

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.

Note: See TracTickets for help on using tickets.