Comment architecture question

[artfulrobot]

I'm implementing my first site in ProcessWire and I will be migrating some content from a Drupal 7 site. I've just come to considering the blog + comments.

I've read @ryan's tutorial post (from 2011!) and I've experimented with the ProcessBlog module, but I'm not convinced. Here's what I don't like

• It creates a lot of special pages which then become intermingled with what I might call "content pages", e.g. actual blog posts. This makes the Pages menu quite problematic - on an empty install there must have been around 10 items, and if I'm importing a blog with hundreds of posts that menu is just going to be unhelpful as it's clearly not a sensible way to navigate huge content lists.
• It uses PageReference for a simple options field. So we have "pages" for things like "Always show comments". I realise that in ProcessWire "everything is a page", and in my head I try to say "it's ok, they just mean entity or object or thing, don't think of it as page. Then why use a word that has such strong meaning in the context of a CMS? Oh just accept it. Hmph. Alright." but it seems that this is going to be very confusing for my clients who will use the site I build for them. Perhaps the Select Options field was not available when the ProcessBlog module was created.
• Needing to edit a page to get to moderate the comments is not natural to me, and it seems that the edit page form brings in an edit form for every single comment. We have hundreds of comments - this is going to be thousands of DOM nodes, and lots of data being loaded every time. Just doesn't seem sensible, as Ryan said in his 2011 post!
• Comments as a field definitely has a logic, but also seems to bring problems (above) and also makes comments not easily searchable because they - unlike everything else - are not a page.

So I'm thinking I might step out in the following direction instead:

So, in words:

• We'd have templates: comments-template and comment-template, with suitable "Family" settings. And blog-listing-template whose children will all be pages using the blog-post-template.
• The comment-template:
  • uses a PageReference field to point to which page the comment belongs to.
  • can hold any fields we need for comments - the message, the poster's display name and email, optional user ID, date posted, and potentially other user-entered fields.
  • can use normal page hierarchy for comment hierarchy (i.e. replies to comments).
  • could have moderation field(s), although I might be happy with just published/not published for my use-case.

I'm not sure about the /admin/ part of the hierarchy but I really just want to indicate that those parts are not publicly accessible.

This to me means:

• Can load comments as pages, so can easily fish out unmoderated comments and link to their posts in-situ.
• Can continue to edit a blog post without needing to load all the comments.

I'd be grateful to anyone who had time to sense-check this idea, or tell me why it's better to do it another way. Thanks ?

 

 

[WillyC]

art fulbot,
usea that select-options field type.if you not want pages fer select opts.
 
thats blog tut.very olden days, they are was not select-options type then {{ but I still like to uses pages most times }} 

for comment
  donut use pages 4 comments
  install ProcessCommentsManger module in Modules>Core>Process
  edit.comment field .. clicka Input tab .. choose "yes" for "use comment manger rather then in-page editor"

for findning comment use comments find() methoda 

n.joy youwill or ask more
love,
$willy

[Pixrael]

Check: https://processwire.com/docs/modules/guides/comments/

[flydev]

7 hours ago, artfulrobot said:

I realise that in ProcessWire "everything is a page", and in my head I try to say "it's ok, they just mean entity or object or thing, don't think of it as page. Then why use a word that has such strong meaning in the context of a CMS? Oh just accept it. Hmph. Alright." but it seems that this is going to be very confusing for my clients who will use the site I build for them.

Short answer as I'm slumped on the couch.

It seem you already read the structure documentation page and got the idea.

About explaining the concept to the client, just use a real analogy. For example, think of a website as a book. In a book, you have chapters, sections, and pages. Similarly, a website is organized into sections, and each section contains individual pages that hold different pieces of content.

In ProcessWire, a "page" is a container that holds all the data and content for a specific part of your website. It's not limited to what you see on the front-end as a traditional webpage. Instead, a page in ProcessWire can represent various types of content or data, such as blog posts, products, images, or contact forms.

Once that said, and once you got the « Wow this is flexible! » then you can go further and say that using this tool (some of us call it a framework more than a simple CMS) allow you to build other types of applications than a website. I mean no frontend, no colors, no (web)Pages.

You can find somes use case threads arround the forum. Ask for more.

Just adding that once your clients become familiar with the page-based concept and the benefits of it, they will find it easier to manage their website content.

Enjoy ?

[wbmnfktr]

10 hours ago, artfulrobot said:

I realise that in ProcessWire "everything is a page", and in my head I try to say "it's ok, they just mean entity or object or thing, don't think of it as page. Then why use a word that has such strong meaning in the context of a CMS? Oh just accept it. Hmph. Alright." but it seems that this is going to be very confusing for my clients who will use the site I build for them.

tl;dr - see below

As @flydev pointed out... a page is more than just only a page. The confusion is real. Totally real for... at least me back in the days when I started using ProcessWire, coming from b2cafelog (nowadays WordPress), Drupal, Nucleus, Textpattern and many more "solutions". Yet... I never ever tried to explain a client what a "page" is in ProcessWire.

For my clients a page is the last point/instance, in terms of hierarchy in delivering output, aka a real page. I never tried (after the first 10 clients or so) to explain the steps in-between. Even most designers and developers (outside of PW) get this part - and I don't even try to explain it most of the time anymore. For reasons.

While everything is a page... you might want to explain it to your client in different terms.
I most often use terms like unit, container, wrapper, entity, part of, fracture... or else depending on whatever I talk about. While I use a page as reference in a recipe, it's still an "ingredient, I can reference" for a client. Makes life easier.

This "page concept" is NOT about communicating it to the client (for me!), it's for understanding the concept. When you get this... PW is not only your friend, but your best friend, wingman, best man, godfather of... you get the idea.

These are/could be all the same - depending on the context and your setup.

$page->title

$ingredient->title

$city->title

$user->title

Even though one is a page (endpoint) and all others are a page reference, comment, repeater... whatever.

You seem to be very new to PW and came from Drupal, which is totally fine, and therefore you might JUST need to explore more parts of how the API and page handling works.

This is not a newbie tip at all! It's what I did and I enjoyed it!

You worked with Drupal so... you know more complex setups and concepts - I guess.
I came from super limited CMS (see above) back then and learned a lot about PHP and whatever you could achieve with ProcessWire. For me it was freedom to do whatever I wanted to do. Till today.

tl;dr/Conclusion:
Think about 'page' as a concept and not a page.

Or... let us know. We are here to assist and help to find a way.

[artfulrobot]

Thanks for the responses so far, everyone, really appreciated!

• "page" - fine / thanks for the analogies and sympathy! I think if anything my questions are around why are comments not pages? They seem an ideal candidate and the comments field seems to reinvent an already good wheel.
• Docs: Thanks for the links, always useful in a forum post to have links to something evergreen, but I have already read them all.
• @WillyC thanks for the tip re the comment manager, that moves comments out of the page edit form, I'll check that out.

My main reservation about comments as a field is that fields are not field-able, right? Say I need to ask for an Organisation from commenters. It looks like I would need to:

• Create a custom CommentForm
• Replace the Comment class since this hard-codes a preset list of possible fields.
• Replace the ProcessCommentsManager class since this also hard-codes the fields.
• Create a new table to hold the comment, and by various hooks, intercept the save/load to use that table. Or ALTER the core-provided table by adding a column.

This then creates a lot of maintenance work since I'd be replacing the core Comment class, and the custom CommentForm whose markup/logic tweaks would need to merge in future core markup and logic tweaks - just to add a field. And if in future someone adds organisation to the core comment and I'm unlucky enough that they use the same column name, then it will be a right faff.

Had a comment been a Page, I would simply add an Organisation field to that Template - the design of the classes could mean that no hacks would be required at all. I can see that comments have a lot of functionality attached - looks like a lot has been bolted on over the years - so maybe this design decision was the only sensible option in 2011 and now it's set in stone. But coming anew to this, comments overlap a lot with pages; there's lots of features implemented in the comment field type that would be brilliant if abstracted (e.g. notification, voting, spam submission, etc.) and extensible, rather than tightly bound to the Comment class.

Please understand I'm not here to criticise with any ill-intent, I'm just probing and questioning to find out if there's anything I've missed/mis-understood. All long running projects inherit some decisions that could do with a refactor at some point, which is normal and very understandable. I'm a noob to ProcessWire but I have dozens of years' experience implementing, extending, coding other CMSes, which is why I'm particularly interested to understand the architecture decisions, and limits to extensibility early on in a project.

To focus the thread: am I right above about what would be required to add a field to a comment? Thanks for your interest.

[ryan]

@artfulrobot Comments are a kind of turn-key fieldtype focused just on comments (like you might use in a blog) or reviews, and their purpose is pretty specific and different from that of a page. So the point is more to be focused on solving a specific thing than to be flexible in the way that pages are. And actually, this is the purpose of most Fieldtypes. If what you are needing is the ability to build your own custom type then that's what pages, templates and fields are for, and maybe that's what you need, I'm not sure. But if you are needing specifically comments, then FieldtypeComments is also quite flexible for comment-specific needs. When it comes to custom data that you want to store along with the comment, there is the meta() method which you might find useful: https://processwire.com/api/ref/comment/meta/. This is what I use for storing photos and other Q&A with comments/reviews, like you see here: https://www.biketours.com/reviews/ 

[artfulrobot]

Thanks @ryan  I'm glad to hear that you hit this problem too. The client in mind uses comments as ... well ... just blog comments! ... and their need of asking for an Organisation field does not seem to take that use-case away from it primarily being comments.

I'm glad also that you implemented a solution 10 months ago, too!

So you implement a custom comment form class, and use `getMeta()` in the template output, as you describe in your July 2022 update (and when it comes to me implementing this, I'll figure out where to hook to call `setMeta()`) [EDIT: Ah, looks like I'd just override processInput()]

That sounds like the way to go. Thanks for your time and support.

Edited April 17, 2023 by artfulrobot
quick update

[ryan]

@artfulrobot There's different ways you could go about it, but what you described should work. The way I built the comments form (here) for the example I linked earlier was to use a FormBuilder form for the comments/reviews form and just used the comments API to add comments. (In that example the "Rate more details" link at the bottom opens a bunch more fields). I mainly used FormBuilder because there were so many different fields and photo uploads, etc., that it went beyond what I wanted to do with extending a CommentForm class. Though a manually written regular HTML form would have also worked fine. I use CommentForm more often when it's more typical blog-type comments with the built-in optional stars, votes, etc., as it can save a lot of time since it's nearly turn-key. If you only need to add a field or two, that's probably the quickest route. Btw, I also see no harm with using pages for comments either, but just that you'd be building a lot from scratch with regards to spam prevention, comment approval, etc., and also just as a personal preference, I like to keep anonymous user generated content out of the page tree.