You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 29, 2022. It is now read-only.
EZComments currently has a "type" field, but it cannot be configured.
If I remember correctly, the type field is used to distinguish between different comment types (e.g. normal comments, or trackback comments).
Currently it's not possible to add custom types.
Use cases: I currently run 2 EZComments installations in parallel, to handle different types of comments. Using the type field, I could do with one install.
Excellent module otherwise - thanks.
stefaan
Attachments
Change History
comment:1 Changed 3 years ago by Stefaan
Summary changed from Use "type" field to support multiple types of comments to Use "type" field to support configurable types of comments
comment:2 Changed 3 years ago by quan
Milestone set to EZComments 2.0
I do not know for what use case the type field was introduced once - perhaps you can explain how YOU would use the type fields?
comment:3 Changed 2 years ago by StefaanV
My current use case:
I have about 25 sections in my website, with different types of content. Let's take two examples:
one section contains user blogs
one section contains factual articles
This leads to two type of comments:
Blogs: typical comments are permanent - they are part of the discussion, offer additional info. Here it's important to keep the comments
articles: typical comments point out factual errors. Typical workflow: comments are processed, corrections are applied to article, comments are deleted.
To make it easier for editors, I've set up two EZComments systems in parallel: one for the permanent comments, one for the "errors and omissions" (here editors have permsissions to delete comments).
Other use case (probably more widely relevant):
I have about 20 different publication types in pagesetter. These include News, Blogs, etc.
As far as I can tell, EZComments can only classify these as "pagesetter" EZComments (no distinction between publication type). Besides the distinction between comment types mentioned above, I think the following use cases would be really useful:
Allow Editors to manage comments for a specific module or pagesetter publication( e.g. News editor can moderate News comments, "Recipes" editor can moderate recipe comments...
Allow Bloggers to manage comments on their own blog - so bloggers can moderate comments on their own posts.
I see pagesetter/pagemaster as the main module to benefit for this, but I can image it would be useful in photo gallery modules as well (people could manage ezcomments for "their" gallery).
Please correct me if I'm wrong, but I think at this moment EZComments can only distinguish between modules. So my idea was to use the "type" field as an easy way to distinguish between whatever is necessary - I can just add the type field whenever I call the hook.
Hope this makes sense :-)
Practically, it only requires minor modifications to the code.
The "type" field exists, but is currently limited to 2 values (hardcoded). Simply removing those hardcoded values would work already.
optionally, Providing a configuration option allowing admins to enter a list of values would work as well,
optionally, providing a filter in the admin list to only show a specific type would be nice as well.
optionally, Including the type field in the security scheme would make it complete.
thanks,
stefaan
The text was updated successfully, but these errors were encountered:
EZComments currently has a "type" field, but it cannot be configured.
If I remember correctly, the type field is used to distinguish between different comment types (e.g. normal comments, or trackback comments).
Currently it's not possible to add custom types.
Use cases: I currently run 2 EZComments installations in parallel, to handle different types of comments. Using the type field, I could do with one install.
Excellent module otherwise - thanks.
stefaan
Attachments
Change History
comment:1 Changed 3 years ago by Stefaan
comment:2 Changed 3 years ago by quan
I do not know for what use case the type field was introduced once - perhaps you can explain how YOU would use the type fields?
comment:3 Changed 2 years ago by StefaanV
My current use case:
I have about 25 sections in my website, with different types of content. Let's take two examples:
This leads to two type of comments:
Blogs: typical comments are permanent - they are part of the discussion, offer additional info. Here it's important to keep the comments
articles: typical comments point out factual errors. Typical workflow: comments are processed, corrections are applied to article, comments are deleted.
To make it easier for editors, I've set up two EZComments systems in parallel: one for the permanent comments, one for the "errors and omissions" (here editors have permsissions to delete comments).
Other use case (probably more widely relevant):
I have about 20 different publication types in pagesetter. These include News, Blogs, etc.
As far as I can tell, EZComments can only classify these as "pagesetter" EZComments (no distinction between publication type). Besides the distinction between comment types mentioned above, I think the following use cases would be really useful:
Allow Editors to manage comments for a specific module or pagesetter publication( e.g. News editor can moderate News comments, "Recipes" editor can moderate recipe comments...
Allow Bloggers to manage comments on their own blog - so bloggers can moderate comments on their own posts.
I see pagesetter/pagemaster as the main module to benefit for this, but I can image it would be useful in photo gallery modules as well (people could manage ezcomments for "their" gallery).
Please correct me if I'm wrong, but I think at this moment EZComments can only distinguish between modules. So my idea was to use the "type" field as an easy way to distinguish between whatever is necessary - I can just add the type field whenever I call the hook.
Hope this makes sense :-)
Practically, it only requires minor modifications to the code.
thanks,
stefaan
The text was updated successfully, but these errors were encountered: