VirtusLab-Open-Source / strapi-plugin-comments

A plugin for Strapi Headless CMS that provides end to end comments feature with their moderation panel, bad words filtering, abuse reporting and more.
MIT License
405 stars 63 forks source link

Strapi v4: Create Custom Field and enable in API Routes #128

Closed jaschaio closed 2 years ago

jaschaio commented 2 years ago

Similiar to #80 I would like to add an authorUrl field to my comments.

Strapi Version: 4.1.7 Strapi Comments Plugin Version: 2.0.10

Unfortunately it doesn't seem to work.

I created two files:

mkdir -p ./src/extensions/comments/content-types
touch ./src/extensions/comments/content-types/comments.js

mkdir -p ./src/extensions/comments/server/services
touch ./src/extensions/comments/server/services/client.js

In the /content-types/comments.js I added:

 authorAvatar: {
   type: 'string',
   configurable: false
 },
+ authorUrl: {
+   type: 'string',
+   configurable: false
+ },
 removed: {
   type: 'boolean',
   configurable: false
 },

In the /services/client.js file I added:

authorData = {
    authorId: author.id,
    authorName: author.name,
    authorEmail: author.email,
    authorAvatar: author.avatar,
+   authorUrl: author.url,
};

I restarted strapi but none of these changes seem to actually be picked up by it.

jaschaio commented 2 years ago

Well it works if I start replicating the whole file structure (or changing relative imports to strapi-plugin-comments) from the strapi-server.js file. But that's not very practical (I guess that's Strapi to blame for).

I would rather use a patch-package file:

diff --git a/node_modules/strapi-plugin-comments/content-types/comment.js b/node_modules/strapi-plugin-comments/content-types/comment.js
index 1eddd02..6462102 100644
--- a/node_modules/strapi-plugin-comments/content-types/comment.js
+++ b/node_modules/strapi-plugin-comments/content-types/comment.js
@@ -64,6 +64,10 @@ module.exports = {
       type: 'string',
       configurable: false
     },
+    authorUrl: {
+      type: 'string',
+      configurable: false
+    },
     removed: {
       type: 'boolean',
       configurable: false
diff --git a/node_modules/strapi-plugin-comments/server/services/client.js b/node_modules/strapi-plugin-comments/server/services/client.js
index 97a5b37..e37094c 100644
--- a/node_modules/strapi-plugin-comments/server/services/client.js
+++ b/node_modules/strapi-plugin-comments/server/services/client.js
@@ -73,6 +73,7 @@ module.exports = ({ strapi }) => ({
                     authorName: author.name,
                     authorEmail: author.email,
                     authorAvatar: author.avatar,
+                    authorUrl: author.url,
                 };
             }

diff --git a/node_modules/strapi-plugin-comments/server/services/utils/functions.js b/node_modules/strapi-plugin-comments/server/services/utils/functions.js
index 18d6d22..4d524ed 100644
--- a/node_modules/strapi-plugin-comments/server/services/utils/functions.js
+++ b/node_modules/strapi-plugin-comments/server/services/utils/functions.js
@@ -70,7 +70,7 @@ module.exports = {
     buildNestedStructure,

     buildAuthorModel: (item) => {
-        const { authorUser, authorId, authorName, authorEmail, authorAvatar, ...rest } = item;
+        const { authorUser, authorId, authorName, authorEmail, authorAvatar, authorUrl, ...rest } = item;
         let author = {};
         if (authorUser) {
             author = {
@@ -85,6 +85,7 @@ module.exports = {
                 name: authorName,
                 email: authorEmail,
                 avatar: authorAvatar,
+                url: authorUrl,
             };
         }
         return {
cyp3rius commented 2 years ago

Hello @jaschaio,

that seems as your use case rather than something common and widely used / requested. I've analysed the PR and I wouldn't like to introduce such use case focused solutions.

What I can propose for you is to keep this as a path-package as you already got and wait for a generic author population solution (#113), which we have got planned to implement.

Sorry to push you back, but as a plugin maintainers we must look from the higher perspective and avoid introducing use case focused solutions to keep plugin as generic as possible.

cyp3rius commented 2 years ago

Closing