Removing comments from core

philwareham · 2015-07-09 07:10:13

I would strongly oppose removing comments from core too. The ‘off’ button works fine.

The only other change we could make would be to remove the protected (un-deleteable) requirement from comments form templates – not sure what any complications arising from that would be though?

wet · 2015-07-09 07:19:24

ax wrote #292929:

Therefore I believe…

This is a fair opinion. Nevertheless, I believe in not hurting existing users.

Additionally, as a developer I consider laziness a virtue.

As I assume that is is not that easy to both amputate the built-in comment part and write a drop-in replacement plugin, I would therefore prefer a solid pull request from an interested party which we can then chew on over a philosophical discussion about “What is a CMS?” Aside: Even the ginourmous Wordpress community strives to clarify the “CMS vs blog” question with varying degrees of success ;)

gaekwad · 2015-07-09 07:28:57

Strong -1 for removing comments.

Bloke · 2015-07-09 09:02:17

A related discussion from a few years ago with an associated Github issue to address the ‘turn off comments paraphernalia when Comments pref is off” gives further perspective. We’re partway there, but the Forms thing is a little sticky since there may be other user-submitted Forms under the Comments twisty (not sure why, but y’know, there might).

In this commit from the Themes branch I changed the get_essential_forms() function so it has a notion of which twisty group each of the “fixed” forms are in. That could be utilised to hide just those forms that are related to comments, but we’d need to wait for Themes to land or cherry pick that commit into master before we could do anything about it.

jakob · 2015-07-09 09:43:14

Like in many of these recent threads, I find myself agreeing and disagreeing at the same time.

Comments could easily be moved to a plugin if somebody still wants them.

There’s the perennial discussion about whether contact forms should be part of the core or in a plugin and for better or for worse, it’s been a plugin all these years (albeit with the silliest of names). I think that comments falls into a similar camp. There are times and sites where you absolutely need them, but also plenty of times where they are not used at all, and they could completely vanish from the admin area (including from the menu).

So, I think there’s a case for making comments a separate module or plugin. The proviso here is that commenting is essential for some sites, so as a plugin it would need to be consistently supported. That has been a problem in the past.

Honestly, for comments, there’s so many services nowadays, Disqus being one of the first.

Sure, there’s lots to love about Disqus – it has a neat UI, nice threading and comments on comments, single sign-in options, likes, social networking and revenue-generating features. But there are quite a few downsides for both site owners and site users:

It is financed through advertising, and even if you switch them off, you’re still being profiled across sites. Disqus also retains your profile information „for a commercially reasonable time“ even after you quit the service. Guest commenting is possible but a) the site owner has to enable it and b) the cookie is still operative. I like contributing to discussions but I dislike my opinions being aggregated (out of context) for other purposes. Consequently, I frequently do not respond to disqus comments.
It sends cookies, which in (most of) Europe requires setting up a cookie notice and creating a cookie policy page (= more work, albeit work you may have to do anyway because you’re using some other service). Disqus will function without cookies, but AFAIK you can’t prevent it using cookies when you load it, so if the site visitor declines the cookie policy, you must disable commenting entirely (for all EU visitors). With txp, you only need to disable the „remember me“ option.
Admin users have to moderate comments on a third-party site and have to set up a corresponding account for a third-party service. That means they have two backends to take care of. If there’s no guest commenting activated, site users have to sign up too to take part in a conversation. Site owners with a ton of sites to manage would probably prefer managing comments all together in one place, many other private site owners would prefer to edit comments where they edit they own site.
AFAIK, aside from the appearance changes you can make via disqus, you’re limited by the iframe that’s loaded when embedding via js. That means if you’re making a theme, its (with some exceptions) un-themable.
It adds more page weight than txp’s own comments.
I see conflicting infos about whether you gain an SEO benefit from comments or not (should you want it). Some say the iframe is indexable, then again if it’s initiated via javascript, how can it be indexed if the crawler doesn’t load javascript.

Ergo: choice is good :-)

A default install has only 11 forms, 4 are comment forms, we could ship with 7, easier on the first time user.

As with so many things, there’s a balance between leanness and flexibility.

If you’re making a public theme, you are (hopefully) making it flexible enough for other people to use in other constellations than your own. That may well include that other people may want to use comments with your theme. As a theme designer, you can opt to help them, or opt to offload it and leave it to them. In this particular more complex case, your expertise as a theme designer is likely to be better than that of your users, and you may find it easier to go the extra mile and style it up than deal lots of requests for help…

At the other end of the scale, a general criticism I have of many WP themes, is that they are all-singing all-dancing. As the gap between “really simple theme config options” and “making own structural changes to a theme” is so large in WP, themes vie with each other to provide a thousand customisation options, with the result that themes are terribly overbloated and the editing options are fragmented across multiple plugins and edit areas in the admin area.

@ax: This being the internet, it’s not possible to tell whether you were being ironic or not in your post, but either way you edited out the causal relationship, so that it implies another… At best, that’s unhelpful, at worst disingenious.

However, the charme of Textpattern is not having a very elaborate default theme that makes it look like just another blogging system, with comments, archive, and so on …

I agree with much of your second post (except for your concluding “therefore…”). I think txp’s virtue is its versatility and that’s not reflected by the default theme. Personally, I think txp occupies a nice niche already between the WPs and joomlas at one end of the scale and php frameworks at the other. Rather than making txp more like {whatever}, I think we should be making this niche, this quality of txp, more accessible to less experienced users.

I think a key benefit of the themes discussion of late, could be the possibility of perhaps making a family of different startup themes of different kinds. If they are well-designed (both visually and structurally in terms of understandable txp:tag structure), it would provide many points of entry for new users and highlight txp’s versatility. A series of community-written articles / blog posts that help people across the threshold of dabbling in the txp:tags to modify the site to their own needs (e.g. typical situations) would help make txp’s key quality more accessible to interested beginners.

hcgtv · 2015-07-09 10:15:17

Bloke wrote #292942:

A related discussion from a few years ago …

That’s the thread where the comments forms were improved, 5 years ago, dang.

You bring up excellent ideas, consolidating forms, making things simpler, easier to style. Aside from finding the time, what’s kept you from pulling the trigger?

jakob wrote #292945:

I think a key benefit of the themes discussion of late, could be the possibility of perhaps making a family of different startup themes of different kinds. If they are well-designed (both visually and structurally in terms of understandable txp:tag structure), it would provide many points of entry for new users and highlight txp’s versatility. A series of community-written articles / blog posts that help people across the threshold of dabbling in the txp:tags to modify the site to their own needs (e.g. typical situations) would help make txp’s key quality more accessible to interested beginners.

:)

CeBe · 2015-07-09 10:34:07

-1000. At least.

Please don’t remove comments from core. They aren’t useless and I use them in more than half of the sites I made. I don’t want to use a third-party system because 1 – it is better to keep full control on data, and 2 – if this service disappears…?

If comments migrate in a plugin, I’m afraid it would be a pain to re-build the functionality and I’m not sure it would work as well as now.

It is fine the way it is.
If someone doesn’t want comments or use an external service, it is fine too. Just disable Textpattern comments, and plug another system if appropriate.
It works, don’t fix it.

Destry · 2015-07-09 10:40:35

jakob wrote #292945:

So, I think there’s a case for making comments a separate module or plugin.

+1. And considering how devs have always advocated for keeping non-critical functionality to plugins, then this just makes sense.

Commenting functionality should be an opt-in option, and when not opted for, there should be nothing visual in the UI about them.

The proviso … as a plugin it would need to be consistently supported. That has been a problem in the past.

I don’t think this would be an issue in this case. Wet’s saying he’s not going to stop using comments. (He’s also said he’ll maintain Txp as long as he’s alive, or something.) So, if this is one of wet’s plugins — my vote — case closed as far as support goes.

This approach doesn’t mean relying on third-party either. It just gives those who don’t need/want comments for a given site a clean break from them.

Of course, I’m not a developer, so there might be engineering constraints/issues I’m unaware of.

Last edited by Destry (2015-07-09 10:46:15)

Bloke · 2015-07-09 10:59:22

hcgtv wrote #292950:

Aside from finding the time, what’s kept you from pulling the trigger?

Just the time aspect. It’s such old code, and so poorly implemented it’s a real struggle to get my head round it.

I made a start (somewhere, could maybe dig out the code, though it might not apply now given all the many other changes around the patch), but any willing volunteers who want to wade through the comments system would be doing Textpattern a massive service.

colak · 2015-07-09 11:17:20

Although I do not use the comment system, many txp users in this forum do and we also receive feature requests to extend them.

So I also think that for the common good (and backward compatibility) we should keep them.

We mainly received two types of requests for them

nested comments
extra fields

So, it is one thing to keep them, but, is there a way to make them more flexible?

Bloke · 2015-07-09 11:28:48

colak wrote #292961:

extra fields

Unlimited custom fields… yeah! :-)

zero · 2015-07-09 11:43:58

Taking away comments would make Textpattern less flexible, imho. Wet gives good reasons to keep them. Jakob gives good reasons to avoid popular third-party comments. Bloke gives good reasons why working on comments would cause another roadblock: time. As others have said, comments work and you can turn them off. So please spare a thought for the developers and turn your comments about comments off for the time being. When custom fields and themes are all nicely embedded, the world will have moved on again, and perhaps then will be the time to revisit this debate.

Textpattern CMS

Textpattern CMS support forum

#13 2015-07-09 07:10:13

Re: Removing comments from core

#14 2015-07-09 07:19:24

Re: Removing comments from core

ax wrote #292929:

#15 2015-07-09 07:28:57

Re: Removing comments from core

#16 2015-07-09 09:02:17

Re: Removing comments from core

#17 2015-07-09 09:43:14

Re: Removing comments from core

#18 2015-07-09 10:15:17

Re: Removing comments from core

Bloke wrote #292942:

jakob wrote #292945:

#19 2015-07-09 10:34:07

Re: Removing comments from core

#20 2015-07-09 10:40:35

Re: Removing comments from core

jakob wrote #292945:

#21 2015-07-09 10:59:22

Re: Removing comments from core

hcgtv wrote #292950:

#22 2015-07-09 11:17:20

Re: Removing comments from core

#23 2015-07-09 11:28:48

Re: Removing comments from core

colak wrote #292961:

#24 2015-07-09 11:43:58

Re: Removing comments from core

Board footer