No CMS would be complete without the ability to comment on pages so that the team can get things just right before hitting publish. As you might have guessed by now, TinyMCE has a plugin for that too. Let's start by enabling it. It's called TinyComments.
Next, I'll add a couple of items to the toolbar to make it easy for users to read and write comments. Finally, we'll set the TinyComments mode. There are two different modes here, callback, which is the default, and embedded. The callback mode stores comments externally, such as in a database and requires callback functions to manage the comment data.
The embedded mode stores the comments directly within the content and makes it super easy to set up. This means that you can store the comments right along with the content in your database. They're encoded in an HTML comment so that they won't display on the finished page, or you can even remove them before sending the HTML to the end site visitor. Next, let's configure the user that is making the comment.
With the tiny comments author setting, we can provide some unique identifier for the user. This is useful for ensuring only the user who wrote a comment can edit or delete it. We can also provide a display name for the user. If it's not provided, the ID will be used instead.
Finally, we can also set an avatar to better identify the user who made the comment. It will be scaled to fit a 36 pixel diameter circle, so it should be a square. I'll just use my GitHub avatar. Also note that the URL for the avatar is saved for the comment.
So if you ever want to change the avatar's URL, you should upload a new image to the same URL or redirect the old image URL to the new. Okay, well, I think that was easy enough. Let's give this a try in the browser now. At first, the add comment button is grayed out, and I'm not able to click on it.
But as soon as I select some text on the page, it lights up, I can click on it, then add a comment specific to that portion of the page. There's my name, there is my avatar. and everything looks great. It looks like I can even reply to myself or other users.
Speaking of other users, what about dealing with comments from other people? Well, you could certainly handle that too, just by setting these to different values, depending on the login user that's visiting the page. Since we don't have auth set up in our application, Let's simulate switching users with a user picker component that I've added to the boilerplate code. I'll add the component here in the page heading, just so it's laid out nicely.
And I've written this component so that it supports vModel in order to manage an active user. Great. Let's define this active user now up inside of script setup. Notice that this component was imported for me by my IDE.
Okay, by default, I'm just going to paste in my personal user object. That is an object with a username, name, and avatar that matches the info we just hard-coded inside of the editor options. Now we can simulate multiple users commenting on this page by simply passing the selected user to the proper author setting. Okay, there is actually one other little thing that we'll need to do here.
Since the init prop to the editor is only applied when the editor is first created, we'll need to force the editor to re-render with the new init settings by adding a key attribute to the surrounding div. This key should be unique and change every time our user changes. username. Okay, let's see if that works.
I'll try changing to another user and click on this piece of text where Daniel commented earlier. If I open up the comments, you can see my comment is there and it highlights the portion of the page that I commented on. What if we add a comment to another section of the page with our new user? I'll select the text, press the add comment button, and then add a new comment.
Perfect. Now both comments appear and we can see exactly who thinks what. Now if I try to delete Daniel's comment without being logged in as Daniel Notice that I'm not allowed to delete this conversation because I didn't create the comment to begin with But if I try to delete my own comment, I can totally do that Also note that as I'm a switching between different users right now, the editor is refreshed That's due to that key that we placed on the surrounding div and was necessary to Reinitialize the editor with a new init object that had the new user in it But in a real system, you wouldn't be switching between users like this And so this wouldn't really be a problem. The solution still works great Plus even in this use case all of our comments and content are still preserved We just have to select the text and open up the comments again.
Finally, you can get even more control over who can edit, delete, or resolve comments by providing a callback function to the init option. For example, we could provide the tiny comments can delete callback function. Inside of this function, we can do any kind of logic that we'd like in order to decide if the current user can delete the conversation or not. same thing for resolve, and there's a callback for edit as well.
Before we close out this video, I'd like to mention one more plugin that you might find useful for your CMS. The accessibility checker plugin is great for ensuring that you ship accessible content to your audience. Here in the tiny MCE docs, there's an interactive example for us to look at. At the very beginning of the toolbar, you can see the accessibility checker.
And look how handy this is. It walks us through all the accessibility issues one at a time. First, it correctly detects that this introductory paragraph should be a heading and gives us a quick way to fix the issue. Next, it points out that we're missing an alt text description on this image.
But it also provides the helpful information that some images that are just decorative don't necessarily need a text description. So we have the discretion at this point to choose which solution we want to pursue. Let's provide some alt text. Then you could continue going through each error this way until all accessibility issues have been fixed.
This is great for our end user experience. It ensures anybody and everybody can easily access and consume the content on our site, and good accessibility is also good for SEO. With TinyMCE powering our CMS, maintaining accessibility on our site is a breeze. No CMS would be complete without the ability to comment on pages so that the team can get things just right before hitting publish.
As you might have guessed by now, TinyMCE has a plugin for that too. Let's start by enabling it. It's called TinyComments. Next, I'll add a couple of items to the toolbar to make it easy for users to read and write comments.
Finally, we'll set the TinyComments mode. There are two different modes here, callback, which is the default, and embedded. The callback mode stores comments externally, such as in a database and requires callback functions to manage the comment data. The embedded mode stores the comments directly within the content and makes it super easy to set up.
This means that you can store the comments right along with the content in your database. They're encoded in an HTML comment so that they won't display on the finished page, or you can even remove them before sending the HTML to the end site visitor. Next, let's configure the user that is making the comment. With the tiny comments author setting, we can provide some unique identifier for the user.
This is useful for ensuring only the user who wrote a comment can edit or delete it. We can also provide a display name for the user. If it's not provided, the ID will be used instead. Finally, we can also set an avatar to better identify the user who made the comment.
It will be scaled to fit a 36 pixel diameter circle, so it should be a square. I'll just use my GitHub avatar. Also note that the URL for the avatar is saved for the comment. So if you ever want to change the avatar's URL, you should upload a new image to the same URL or redirect the old image URL to the new.
Okay, well, I think that was easy enough. Let's give this a try in the browser now. At first, the add comment button is grayed out, and I'm not able to click on it. But as soon as I select some text on the page, it lights up, I can click on it, then add a comment specific to that portion of the page.
There's my name, there is my avatar. and everything looks great. It looks like I can even reply to myself or other users. Speaking of other users, what about dealing with comments from other people?
Well, you could certainly handle that too, just by setting these to different values, depending on the login user that's visiting the page. Since we don't have auth set up in our application, Let's simulate switching users with a user picker component that I've added to the boilerplate code. I'll add the component here in the page heading, just so it's laid out nicely. And I've written this component so that it supports vModel in order to manage an active user.
Great. Let's define this active user now up inside of script setup. Notice that this component was imported for me by my IDE. Okay, by default, I'm just going to paste in my personal user object.
That is an object with a username, name, and avatar that matches the info we just hard-coded inside of the editor options. Now we can simulate multiple users commenting on this page by simply passing the selected user to the proper author setting. Okay, there is actually one other little thing that we'll need to do here. Since the init prop to the editor is only applied when the editor is first created, we'll need to force the editor to re-render with the new init settings by adding a key attribute to the surrounding div.
This key should be unique and change every time our user changes. username. Okay, let's see if that works. I'll try changing to another user and click on this piece of text where Daniel commented earlier.
If I open up the comments, you can see my comment is there and it highlights the portion of the page that I commented on. What if we add a comment to another section of the page with our new user? I'll select the text, press the add comment button, and then add a new comment. Perfect.
Now both comments appear and we can see exactly who thinks what. Now if I try to delete Daniel's comment without being logged in as Daniel Notice that I'm not allowed to delete this conversation because I didn't create the comment to begin with But if I try to delete my own comment, I can totally do that Also note that as I'm a switching between different users right now, the editor is refreshed That's due to that key that we placed on the surrounding div and was necessary to Reinitialize the editor with a new init object that had the new user in it But in a real system, you wouldn't be switching between users like this And so this wouldn't really be a problem. The solution still works great Plus even in this use case all of our comments and content are still preserved We just have to select the text and open up the comments again. Finally, you can get even more control over who can edit, delete, or resolve comments by providing a callback function to the init option.
For example, we could provide the tiny comments can delete callback function. Inside of this function, we can do any kind of logic that we'd like in order to decide if the current user can delete the conversation or not. same thing for resolve, and there's a callback for edit as well. Before we close out this video, I'd like to mention one more plugin that you might find useful for your CMS.
The accessibility checker plugin is great for ensuring that you ship accessible content to your audience. Here in the tiny MCE docs, there's an interactive example for us to look at. At the very beginning of the toolbar, you can see the accessibility checker. And look how handy this is.
It walks us through all the accessibility issues one at a time. First, it correctly detects that this introductory paragraph should be a heading and gives us a quick way to fix the issue. Next, it points out that we're missing an alt text description on this image. But it also provides the helpful information that some images that are just decorative don't necessarily need a text description.
So we have the discretion at this point to choose which solution we want to pursue. Let's provide some alt text. Then you could continue going through each error this way until all accessibility issues have been fixed. This is great for our end user experience.
It ensures anybody and everybody can easily access and consume the content on our site, and good accessibility is also good for SEO. With TinyMCE powering our CMS, maintaining accessibility on our site is a breeze.