Textpattern CMS support forum

You are not logged in. Register | Login | Help

#31 2015-07-09 19:38:56

etc
Developer
Registered: 2010-11-11
Posts: 3,427
Website

Re: Removing comments from core

hcgtv wrote #292981:

Allright, I will trace a comment through the system, see where it goes, what it does. We have better tools at our disposal these days, and the Textpattern core code is not Magento.

FWIW, I don’t mind if comments are delegated to plugins (provided bw-compatibility is respected), but please don’t consider disguising some Disqus-like service as txp tags. Otherwise all I will see is “Please enable JavaScript to view the comments powered by Disqus”.

Offline

#32 2015-07-09 21:18:55

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,841
Website

Re: Removing comments from core

hcgtv wrote #292981:

Allright, I will trace a comment through the system, see where it goes, what it does.

Brilliant, thanks. fwiw, these were my notes last time I trawled through it:

  • Make the comment tags proper tags in taghandlers.php. Currently they’re a curious mix of some in there, and the rest in publish/comment.php which don’t act like proper tags (and they break if you omit the trailing space before the closing slash).
  • Give <txp:comments /> container ability.
  • Consolidate comment tags into two main tags:
    • <txp:comment_display type="email | id | anchor | message | help" wraptag class break>.
    • <txp:comment_input type="email | message | name | preview | remember | submit | web" label wraptag class break>.
  • Deprecate:
    • comment_anchor.
    • comment_email.
    • comment_id.
    • comment_message.
    • comments_help (note: in comment.php so not a real tag yet. Implications?)
    • comment_email_input.
    • comment_message_input.
    • comment_name_input.
    • comment_preview.
    • comment_remember.
    • comment_submit.
    • comment_web_input.
  • Update the built-in forms / theme to use the new tags.
Anomaly tags that probably need to be retained for convenience:
  • comment_name (takes link attribute).
  • comment_web (single or container, but could probably be renamed something more sensible).
  • comment_time (takes format attribute).

Other things to look into:

  • Minor improvements to the admin-side comments panel. The ability to comment on an article directly from the admin-side would be super handy for those people that moderate them (which means having a preview textarea).
  • The conditional comment tags: if_comments / allowed / disallowed / error / preview. Try to consolidate the functionality into one or two tags.
    • Dedicated allowed / disallowed tags is just daft: use something like <txp:if_comments_allowed> ... <txp:else /> ... </txp:if_comments_allowed> instead.
    • Also think about a way to differentiate between comments enabled (at the article level) and enabled overall (from prefs).

That last point is something that’s bugged me in the past. There’s currently no simple way to differentiate between “comments disabled, site-wide from the prefs” and “comments disabled just for this article” so it makes conditional logic messier. Sometimes you just want to say “Sorry, comments are not available on this article. If you feel strongly about the subject matter, send me an email instead”. If at some point later you turn off comments entirely, the same message will show up, which is not strictly true as comments have been disabled site-wide so it’d be nice to be able to display a different message (example: <txp:if_comments_allowed type="article"> vs. the version without the attribute to check for site-wide comment ability).

Lots to do, and it could probably be done piecemeal if we figure out what depends on what.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#33 2015-07-09 23:14:50

hcgtv
Plugin Author
From: Miami, Florida
Registered: 2005-11-29
Posts: 2,634
Website

Re: Removing comments from core

Bloke wrote #292991:

Brilliant, thanks. fwiw, these were my notes last time I trawled through it:

Awesome, copy/pasted will read it tonight.

Thanks Stef, you’re a good bloke ;)

Offline

#34 2015-08-25 11:20:27

Destry
Moderator
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,295
Website

Re: Removing comments from core

/* hopes this exploration is still on a low burner */


Wordworkin’ for you.

Offline

#35 2015-08-25 14:34:21

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,841
Website

Re: Removing comments from core

Destry wrote #294349:

/* hopes this exploration is still on a low burner */

Ruud’s done a sterling job on part one already. The half-breed comments tags are now proper tags as of the other day. As for the rest: well, one day…


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#36 2015-08-25 16:01:16

ruud
Developer emeritus
From: a galaxy far far away
Registered: 2006-06-04
Posts: 5,068
Website

Re: Removing comments from core

The second bullet may soon be fixed as well

Offline

#37 2015-08-25 21:47:00

Destry
Moderator
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,295
Website

Re: Removing comments from core

I believe the “R” in Ruud’s profile stands for “Rocks!”

What made me think of this situation again was editing this page for new docs, notably the “Wrongly assumptive” entry I added today, and it’s footnotes under core feature caveats. All rather apt, I think.


Wordworkin’ for you.

Offline

#38 2015-09-04 11:58:43

moon blake
Member
From: near Hannover, Germany
Registered: 2009-07-16
Posts: 74

Re: Removing comments from core

Destry wrote #292954:

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

hcgtv wrote #292983:

At no time have I advocated leaving current users without a home grown alternative, I’d just like to make it optional.

Sorry, I don’t get your point: Comment system is optional (in the preferences). And replacing it by a plug-in breaks existing sites. Nothing to discuss anymore, IMHO.

jakob wrote #292945:

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:

Another downside Jakob did not mention is that Disqus often loads pretty slow, in my experience.

And the mentioned “time problem” of our few devs is another argument for not changing the comment system. We should focuse on more important things. I agree 100% to what Jakob wrote:

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.

Offline

Board footer

Powered by FluxBB