Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set allowedTags based on the field’s toolbar buttons #10

Open
Lingonmirakel opened this issue Oct 7, 2020 · 6 comments
Open

Set allowedTags based on the field’s toolbar buttons #10

Lingonmirakel opened this issue Oct 7, 2020 · 6 comments

Comments

@Lingonmirakel
Copy link

Hi, thanks for the plugin!

I have a heading field (HTML editor) in a model where I only allow bold text. In my template, I use it inside a h1. When an editor copies a heading from the browser to the heading field, the <h1 /> is still there, even though I don’t allow it in the editor, resulting in nested headings in the DOM.

I could fix this in my template(s) by doing some sanitization of my own, but it would make more sense to have everything gathered at one place.

Could this plugin perhaps base the list of allowedTags on available tags in the editor, or have a setting to use this logic?

Thanks and let me know if you want any help.

@vonschau
Copy link
Member

vonschau commented Oct 7, 2020

Hi @Lingonmirakel,

yes, I've already thought about it.

Plugin uses sanitize-html package with the following options:

    {
      allowedTags: ['h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'blockquote', 'p', 'a', 'ul', 'ol', 'li',
        'b', 'i', 'strong', 'em', 'strike', 'br', 'table', 'thead', 'caption', 'tbody', 'tr', 'th',
        'td', 'iframe', 'img'],
      allowedAttributes: {
        a: ['href', 'name', 'target'],
        iframe: ['src'],
        img: ['src', 'alt', 'title', 'width', 'height'],
      },
      allowedIframeHostnames: ['www.youtube.com'],
      parser: {
        decodeEntities: false,
      },
      transformTags: {
        div: 'p',
      },
    }

What would be the best option from your point of view? Let the whole configuration in JSON field in plugin's config? Or split it to tags, attributes, etc.?

Thanks for your opinion!

@vonschau
Copy link
Member

vonschau commented Oct 7, 2020

I'm not sure, if the plugin can get available tags from field, can it? Can you pls find it out?

@Lingonmirakel
Copy link
Author

@vonschau Hey, thanks for getting back to quickly!

I think just having the whole object editable on a per-field basis (with the current config as default) would allow for the greatest configurability. So that might actually be a better solution than my proposal 👍

@Lingonmirakel
Copy link
Author

Lingonmirakel commented Oct 7, 2020

I'm not sure, if the plugin can get available tags from field, can it? Can you pls find it out?

I think it’s field.appearance.parameters. https://www.datocms.com/docs/content-management-api/resources/field

@vonschau
Copy link
Member

vonschau commented Oct 7, 2020

Great!

Anyway, I want still some tags to be allowed - implicit ones (ie. <br>, <p>) or those which can't be put directly using editor function (ie. <iframe>). This has to be configurable.

So I'll make these base tags configurable (global or instance?). Then merge them with tags configured in html editor settings.

I'll let current config as default value to prevent BC.

@Lingonmirakel
Copy link
Author

Anyway, I want still some tags to be allowed - implicit ones (ie. <br>, <p>) or those which can't be put directly using editor function (ie. <iframe>). This has to be configurable.

Sounds reasonable to me 👍

So I'll make these base tags configurable (global or instance?). Then merge them with tags configured in html editor settings.

Instance would, again, allow for greater configurability so that makes more sense to me. Or have a global that can we overwritten for an instance. I have a current scenario where I would like to prevent <br /> for a specific field, while I want to allow it for other fields.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants