More New Comments Upgrades

Last week we told you about major upgrades we're making to ProcessWire's comments system thanks to the support of update AG. This week we continued those upgrades (on the dev branch) and have added the following:

• Admin approval of comments from email
• New admin notification email options
• New user notification emails
• Other comments updates

Admin approval of comments from email

Previously whenever a new comment was posted the administrator would get an email notification. But it wasn't anything more than a notification. If the comment needed action, such as approval or deletion, then they would have to go and login to the site and take care of it. That was kind of a hassle.

Now the admin notification emails actually let you approve comments directly from a link in the email. Further, you don't have to be logged in to the site to make it happen. Each comment now incudes a very long random password/code of sorts that makes this possible, and that code is bundled into the URL in the email so that the action can be performed without doing anything more than clicking on it. Note that it's a one-time action– once used, the comment can no longer be modified without being logged-in.

This also makes it easy to approve comments on-the-go, as you could do it from your mobile device as easily as from your desktop. When a notification email arrives, it indicates the current status of the comment. If the status is pending then you'll have an action link to approve the comment. Once approved, the comment appears on the site. If the status is approved already, then you'll have an action link to label the comment as spam, which removes it from the site.

New admin notification email options

Previously the comments field settings let you defined one or more email addresses that could receive notifications of new comments. Typically this would be the administrator email. With the latest update, you can now specify not only emails, but user names or page fields (where it should pull an email address from). This enables it to determine what email the notification should go to at the time the comment is posted.

An example of where this is useful is in our modules directory. Module authors previously had no way of knowing when a new comment was posted short of regularly checking back in on the page. The result is that a lot of questions/comments posted on a module page go unanswered. But with the latest core update, I can specify that I want it to pull the admin notification email from the page it was submitted on. This sends the notification email to the module author, rather than me. It also enables the module author to approve (or label as spam) comments for their own module page. Note: I haven't actually installed this on the modules directory just yet, but will be shortly.

New user notification emails

Any visitors that post comments can now opt-in to receive email notifications when someone has replied to their comment, or when any new comment is posted on the page. This should help greatly with keeping conversations active. For an example, take a look at the comments on this page. You'll see a new select box that lets you choose your notification preference.

Note that notifications don't get sent out until the comment is approved. This ensures your server won't be spamming people. Each notification email also includes a "disable notifications" link that lets the user later opt-out of receiving comments if they want to.

Something that I think we need, but isn't yet there is a double opt-in for this. While it may not be technically necessary, given that a new visitor typically has to go through an approval before any notifications are sent, I still think it's a good idea. So that's something I've setup locally, but just haven't yet pushed to dev. When the visitor indicates they want to receive notifications, they get sent an opt-in email asking them to confirm it, and notifications don't get sent until they do.

Currently the notification emails do not include the actual comment itself for a few reasons. First is just a matter of security and spam protection. If a user's first comment is approved, then their later comments are auto-approved (a config option you have in your field settings, which is the most common option). That means email notifications go out immediately. It works the same way in WordPress, and spammers are aware of this. They will usually post some comment that says something like "thank you for this helpful information" or something friendly to get you to approve it (don't do it!). Following that approval, they can post their spam. If we're sending comments in email, then at that point the email notifications would themselves be spam. That's something I'd like to avoid. Next is the issue of users replying to the emails rather than going to the page where the comment exists. Replying to the email doesn't make it appear in the comments, so we want to prevent the chance that the user will do that. Lastly, we want people to interact with your site (increasing your pageviews), not absorb everything in their email. I recognize there may still be value in bundling the comment directly in the email, so if need be we can always make it a setting.

Note that user notifications are disabled by default. You have to enable these in your comments field settings.

Other comments updates

• Re-do of the comments field settings screen (Settings > Fields > comments).
• You can now set the notification "from" email address from the comments field settings.
• Remembering a user's name/email from request-to-request is now handled fully in javascript with cookies, rather than with PHP sessions. This is much more cache friendly if you are using ProCache or template cache.
• Notification emails are now HTML rather than plain text. Though a plain text version is still bundled in.

Next week we'll be adding support for up/down votes for each comment. We'll also be adding double opt-in for email notifications.

There are a lot of updates here to the comments system, and they may not be fully ready for a production environment. As a result, if you are using comments on your site, you may want to give it another week or two before upgrading to the latest version of FieldtypeComments present on the dev branch. Or if you want to run the latest dev branch, you can give it a try (and let us know how it works for you) or just replace /wire/modules/Fieldtype/FieldtypeComments/ with the FieldtypeComments from the stable branch.

Comments

• 

  WillyC

  • 6 years ago
  • 52

  thank u for this.healpful infomatinos

  Reply

• 

  ryan

  • 6 years ago
  • 72

  If you want to limit comments to logged-in users, then you just don't render the comments (or the comments form) to users that aren't logged in. So rather than: echo $comments->renderForm(); you'd do a if($user->isLoggedin()) echo $comments->renderForm(); When a user is logged in, then their info is taken from their profile and pre-populated in the form. There is also an option present to prevent them from modifying that info if that is your preference. Look in the CommentForm class near the top, as the available options you can pass to it. Any of the options can be passed in via an array to renderForm(array).

  Reply

• 

  gurumeditation

  • 6 years ago
  • 11

  Ok thanks for that. So it can't be done via the API? i.e if the current user == the author of the comment, pull the comment via the Api and place it in a textarea, so that they can make a change and then save it back again?

  Thanks again.

  Reply

  • 

    ryan

    • 6 years ago
    • 31

    Anything is possible via the API. :) But you'd have to write your own code to handle front-end output/input rather than using the built in comment markup/rendering functions included with PW.

    Reply

• 

  owzim

  • 6 years ago
  • 21

  Great explanation, thanks Ryan!

  Reply

• 

  Renobird

  • 6 years ago
  • 32

  Awesome! We use the comment system to manage internal communications related to processes like travel. These new features will make them a lot easier to maintain.

  @WillyC - real LOL's out of that comment.

  Reply

• 

  Ryan

  • 6 years ago
  • 72

  Regarding your other questions. Comments are not pages, instead they are their own data type. Currently a user cannot go back and edit a comment after it's been posted. However, comments can be edited by an administrator.

  Reply

  • 

    owzim

    • 6 years ago
    • 11

    Is there a reason why comments are not pages?

    Reply

    • 

      ryan

      • 6 years ago
      • 91

      Pages would accommodate comments very well no doubt, but I see individual comments as being a part of a page rather than a page themselves. That essentially describes the nature of a field. So comments fit this definition and purpose.

      Another aspect is that comments represent anonymous user generated content. This may be personal preference, but I don't like my page ID space getting taken up with that type of content. For every legit comment there might be dozens of spam comments. They never get approved, and get removed automatically after a couple days, but they do increment the page ID counter permanently, as would any new page. As a result, my preference is to keep anonymous user generated content isolated from my pages table.

      Lastly, but perhaps most importantly is the security aspect. The nature of anonymous user generated content is a bit different from other administered content on a typical site. It's better to hold it at a distance, isolate it, and lock it down. A good security practice is to avoid supplying more capabilities that what will be needed or used. Pages are downright powerful, having far more capabilities than what is necessary for comments. Granted, I don't see any security problems with using pages for comments at present. But just as a security best practice I think it's better to isolate anonymous user generated content, even at the access and storage level, when possible.

      Reply
• 

  Darrin

  • 6 years ago
  • 11

  Ahhh, gotcha. Thanks Ryan.

  Reply

• 

  GuruMeditation

  • 6 years ago
  • 41

  A couple of questions....

  I am developing a site that will use comments throughout. The comments will be available to registered members only. Guests will not see the comments form, there will simply be a message for them to create an account, or to log in instead.

  So, will it be possible to automatically send the current logged in member's name when the comment is posted, rather than them having to fill it in like on here? Essentially I will only need to display the comments box, and submit button.

  Also, will it be easy enough to pull a comment so that the user can edit it if they wish from a front-end form, obviously with sanitization etc. I am assuming comments are simply just pages, or do I have that wrong? This is the first time I have used the comments system.

  Thanks.

  Reply
• 

  ryan

  • 6 years ago
  • 31

  Darrin, in your comments field settings (Setup > Fields > comments > Details), see the setting "Notifications from email". If left blank, it will use the "processwire@mydomainname.com" email. But if populated, it will use the email address you specify.

  Reply

  • 

    Darrin

    • 6 years ago
    • 11

    Thanks for the reply Ryan! I don't seem to have that option. I have a "Notification email" for the To: address, but nothing for the From: addy. I have v1.0.3 of the FieldtypeComments.module and v2.5.3 of ProcessWire. Was that option added later?

    Reply

    • 

      ryan

      • 6 years ago
      • 21

      Darrin, these blog posts are primarily specific to PW's dev branch. Version 2.5.3 is the master branch. To take advantage of these features, you'd need to be on the dev branch (currently 2.5.26). Though they will likely be merged to the master branch in a matter of weeks.

      Reply
• 

  Darrin

  • 6 years ago
  • 11

  Hi Ryan,
  I just got through trouble-shooting an email send failure in the comments system. It turns out that the comments module is hard-coding a from-address as ProcessWire. Is this by design? Or have I missed where this is configured? From what I can see in FieldtypeComments.module, the only thing dynamic about the from-address is the $this->config->httpHost grab for the domain.

  I would rather have a blank from-address so that I can specify it in the WireMailSmtp module. I've bypassed it for now by editing the .module file (or alternatively I create a processwire@mydomainname.com email address so the server allows it through). Obviously, editing the core file is not recommended or desired on my end. :)

  Reply