Rearming comments, changing comment status after expiry date

gaekwad · 2020-07-21 17:04:34

(It’s a toss up whether this is the right forum, please move it if I’ve got it wrong.)

I’m dealing with a mangled 4.2.0 site with many tens of thousands of spam comments interspersed with good comments.

When an article has comments enabled, and the global settings are configured to expire comments after a certain time, there doesn’t appear to be a way to rearm or force enable new comments after this time. Is this intentional? I’m a bit confused as to why this isn’t doable.

For example, say an article is written on January 1st with a 2 week comment expiration. We can expect new comments to be prohibited after January 15th. Now, say the article is shared and gathers some attention toward the end of that time period (e.g. January 13th), and the author wishes to extend the comment period for a further week or two – I can’t see a way to do this.

Likewise, on the article list, articles with comments marked as Expired seemingly cannot have their comment status set to Off, so where a bulk comment policy might need to be applied (e.g. no more comments displayed on the front side), those articles where comments were On but now Expired will now always be Expired. It is possible to switch an article’s comments from On to Off (and On again) if it’s during the comment grace period, but that global setting doesn’t permit a change after comment expiry.

My instinct says I should be able to turn comments Off on one or more articles where comments have been On, but are now Expired. It’s non-destructive insofar as the comments remain behind the scenes, but the front side will not show the comments. An edge case example might be an article overrun by comments of both good and bad origins, and the author needs some time to sift through and moderate (I know there’s an option to set comments to moderated, but hear me out). Turning the comments to Off in the article would prevent all comments being shown, hide the comment form, and then provide some time to housekeep, and reenable the good comments when that process is complete…but with an expired comment form so no more can come in.

…or am I missing something, somewhere?

(I will suffix this wall of text with a note that I never use comments in my own sites, and rarely in client sites, so consider me new at this.)

Last edited by gaekwad (2020-07-21 17:31:56)

colak · 2020-07-22 04:27:21

Hi Pete, If I remember correctly 4.2 was the second txp release after the beta and rc versions. It’s a museum piece now! Is there a reason you are not upgrading it?

In response to your question, I’m not using comments but I’m bumping the thread in the hope that someone will have the answer.

phiw13 · 2020-07-22 06:27:15

It has been a while, since I don’t use comments a lot, and when we do, 6 weeks is enough for some useful babble to come in. But if I recall correctly, the only way was to save the article again with “Reset Timestamp to now”, and then reopen the comments.

And I’ll echo Yiannis, a museum piece.

gaekwad · 2020-07-22 06:44:02

phiw13 wrote #324750:

And I’ll echo Yiannis, a museum piece.

I didn’t phrase my OP particularly well – the (charity) site I’m dealing with is currently on 4.2.0 and has the bajillions of comments, along with a lot of core code changes and other custom stuff.

I have started stepping it through minor version upgrades locally, I wouldn’t consciously leave it at 4.2.0 on the internet, that’s just irresponsible.

I had considered the publish date bump, but that affects feeds. There’s some hobo Magpie RSS code to share and retrieve press release and blog-style posts to other charity / governance endpoints, and I’m wary of breaking that.

jakob · 2020-07-22 08:02:30

gaekwad wrote #324742:

When an article has comments enabled, and the global settings are configured to expire comments after a certain time, there doesn’t appear to be a way to rearm or force enable new comments after this time. Is this intentional? I’m a bit confused as to why this isn’t doable.

I think you’re right about there being no way to re-active receiving comments once the comments expiry deadline has passed.

What you can do is switch the global expiry setting to “Never” and then switch off comments for the ones you want to still expire to “off” on a per-article basis.

… articles with comments marked as Expired seemingly cannot have their comment status set to Off … it is possible to switch an article’s comments from On to Off (and On again) if it’s during the comment grace period, but that global setting doesn’t permit a change after comment expiry.

You can also switch comments on/off using the multi-select on the article list (the latter has no effect on the comment expiry status) … BUT that may give you access to that switch when comments are expired, i.e. when the on/off switch is no longer shown on the edit article pane.

That may make it possible to first switch off comments for all or all relevant articles, then switch the global setting to “never” and then individually re-activate the comments for the articles you want. A long-winded way I agree.

It’s non-destructive insofar as the comments remain behind the scenes, but the front side will not show the comments…

(I know you mean a conjectural situation here but …) as far as I recall, the on/off switch for comments only stops the comment form from being presented. Any existing comments are still shown. That may be template dependent, i.e. the behaviour could be changed using a template (if it’s not caught by the main tag, then using the if_custom_field name="annotate" value="0" trick).

gaekwad wrote #324753:

I didn’t phrase my OP particularly well – the (charity) site I’m dealing with is currently on 4.2.0 and has the bajillions of comments, along with a lot of core code changes and other custom stuff.

I’m dealing with a mangled 4.2.0 site with many tens of thousands of spam comments interspersed with good comments.

If the spam is flagged, you may be able to simply remove them via the database but judging by the numbers you’re talking about, manual sieving doesn’t sound feasible.

There’s some hobo Magpie RSS code to share and retrieve press release and blog-style posts to other charity / governance endpoints, and I’m wary of breaking that.

That was used by some early plugins as a way of bringing and displaying content from other rss feeds (see txp.org). You should be able to replace that with smd_xml.

along with a lot of core code changes and other custom stuff

I’ve been guilty of this before (but that site doesn’t sound like one of mine) but I did start marking my core mods (beginning and end points) in the source so I could find them again later. A lot of my early core code modifications have become unnecessary over time because they became part of the core (a major case back then was that images, files, links etc. could not have authors).

The other way of tracing them, is to diff your installation against a clean version of 4.2 grabbed from the v4.2 tag on GitHub. It’s more difficult when the site was using a dev version with a revision number from the old trac/subversion system.

Bloke · 2020-07-22 11:07:22

I’d have to delve into this in a bit more detail to grok the issue, but yes I think the comment expiry all hinges off the corresponding article posted date. So short of manipulating that (and messing up the feeds as you mention) there’s not much we can do here right now.

There’s an argument to be had that we could somehow allow comments to be hooked off article modification date rather than posted date. That way, you could extend (or reactivate?) the life of the comment form on an article by simply changing/resaving the relevant article(s).

Granted, it’s still a bit of a faff, but less faff than outlined in the above suggestions. I don’t think modification time affects syndication (or if we have a pref for governing that? – can’t find one) so that might work nicely.

The simplest way I can think to do that would be an attribute to the <if_comments_(dis)allowed*> conditionals, e.g.

<txp:if_comments_allowed>
   Comments are allowed based on testing a) the global pref flag, b) the article 'annotate' flag, c) whether the posted date of the article is within range of the expiry time. In other words, same as today.
</txp:if_comments_allowed>

<txp:if_comments_allowed type="pref">
   Comments are allowed based solely on whether the pref is on or not
</txp:if_comments_allowed>

<txp:if_comments_allowed type="article">
   Comments are allowed based solely on whether the article annotate flag is on or not. Implies type="pref" too.
</txp:if_comments_allowed>

<txp:if_comments_allowed type="posted">
   Same as the default case today.
</txp:if_comments_allowed>

<txp:if_comments_allowed type="lastmod">
   Comments are allowed based on last modification time of article. Implies type="pref" and type="article" are enabled.
</txp:if_comments_allowed>

In other words, you can choose the cascade granularity at which the check is performed, i.e. one of:

Check everything, starting with global pref, then article pref, then expiry window based on article Posted timestamp.
Check global pref only.
Check global pref and article annotate status only.
Check global pref and article annotate status and posted timestamp is within expiry window (same as case 1).
Check global pref and article annotate status and modified timestamp is within expiry window.

Note to self and devs: do we deprecate <txp:if_comments_disallowed> in favour of <txp:if_comments_allowed not>?

Either way this is probably not for 4.8.2 but there’s a rethinking comments thread from a few (Jeeez, 10?!) years ago that we could tag this thread from so it stays on our radar, and add it to the GitHub issue to track it.

Last edited by Bloke (2020-07-22 11:11:01)

phiw13 · 2020-07-22 12:28:54

I haven’t thought much about comments lately, I’ll refrain from commenting on your ideas for now (must read them again…)

Just one thing to note:

I don’t think modification time affects syndication (or if we have a pref for governing that? – can’t find one) so that might work nicely

The article will not be republished to the feed, but the date stamps will be updated. Some feed readers will eventually mark the article as “unread” based on the new timestamp. The feed reader might (will ?) indicate this “unread” status differently.

For example, Vienna, my feed reader of choice, has pref (‘mark updated articles as new’) that controls this, off by default. if checked, an updated article will have a green dot in front of the title instead of a blue one to indicate the unread status.

Bloke · 2020-07-22 13:07:04

phiw13 wrote #324768:

Some feed readers will eventually mark the article as “unread” based on the new timestamp. The feed reader might (will ?) indicate this “unread” status differently.

Okay, so not as clear cut as I’d hoped. But I expect feed readers will pretty much all have such an option so at least people can opt out of this behaviour on a per site/per feed/global(?) basis.

Still, I don’t think this practice of resetting modification timestamp to retrigger comments will be common. And there are a host of other reasons to modify an article, which will trigger this behaviour in feed readers anyway.

Not sure how (or whether) this affects Pete’s situation.

gaekwad · 2020-07-22 15:21:55

Bloke wrote #324771:

Not sure how (or whether) this affects Pete’s situation.

Let’s ignore it. More pressing concerns! I’ve done some handy regex stuff with about 97% accuracy on the spam and 100% (so far) on the ham, so let’s look at something else instead.

Thank you all for your perspectives – most helpful.

jakob · 2020-07-23 08:28:47

gaekwad wrote #324777:

Let’s ignore it. More pressing concerns!

I kind of agree, but your original point on being able to more easily reactivate comments for an article where commenting has expired is still valid.

gaekwad · 2020-07-23 09:25:05

jakob wrote #324788:

I kind of agree, but your original point on being able to more easily reactivate comments for an article where commenting has expired is still valid.

Commenting needs a rethink on various fronts. I noticed Bloke has tagged this thread into the catch-all issue on GitHub so it won’t be forgotten.

(But let’s get 4.8.2 out first.)

Textpattern CMS

Textpattern CMS support forum

#1 2020-07-21 17:04:34