SanitizeHtml on HtmlField not honored on package import.

[sonicmouse]

I have a Recipe that has this definition:

{
  "FieldName": "HtmlField",
  "Name": "articleEntryBody",
  "Settings": {
    "ContentPartFieldSettings": {
      "DisplayName": "Body",
      "Editor": "Wysiwyg",
      "Position": "10"
    },
    "HtmlFieldSettings": {
      "SanitizeHtml": false
    },
    "ContentIndexSettings": {}
  }
}

Below that, I have article content that looks like this:

I import the package, and when i navigate to the resource, it changed it to this:

Notice the <div class="media-carousel"> was changed to <p class="media-carousel">.

Apparently setting SanitizeHtml to false isn't enough. Is there any way I can just shut off all HTML sanitization? I don't want to use it for this project and deadlines are creeping fast.

[MikeAlhayek]

I had similar issue even when adding HTML content to a content item using the UI the same happens.

[Skrypt]

This is probably just an issue when importing recipes. The HtmlSanitizer is probably not executed.

[sonicmouse]

Is there any way i can shut off sanitization globally so it never runs, @Skrypt ?

[Skrypt]

I don't recommend it. But you would need to take a look at https://github.com/mganss/HtmlSanitizer options. Or, you could unregister the service with the DI from a custom module I guess.

[MikeAlhayek]

I don't know if this truly a recipe import issue or just editor problem. I think you're problem is related to #12049 which is fixed by PR #12049

[sonicmouse]

When i pull the data out via GraphQL, it's in this converted state. That's right after package import, without viewing it in the editor, if that helps.

[MikeAlhayek]

@sonicmouse are you able to share with us the recipe you are using to create the content-type and import the content item that is causing this problem? This will make reproducing the problem easier.

[sonicmouse]

I tore down everything and rebuilt it to test what I said, and it's not converting it on import. It seems to be the bug that is referenced above. When I go to article page, it's acting the exact same where the div is being converted to p and the edit box is not scaled correctly.

But I swear I never edited the article contents. I imported, then pulled the data out via GraphQL. So I have no idea how it ever got in that state to begin with. But I sure can't recreate it now. This data was imported on a much earlier version of Orchard Core CMS though (v1.1.0 I believe), so maybe there was something that was fixed since then.

You can mark this as duplicate if you'd like.

[MikeAlhayek]

@sonicmouse glad to know its just a bug :) apparently this isn't a bug. its part of the default that the editor creator provide. A proposed fixed can be found in PR#12050. If this one get merge, you won't need to make a change. but for now, I suggest you use Tryumbowyg and add this to the settings

 semantic: {
        'b': 'strong',
        'i': 'em',
        's': 'del',
        'strike': 'del'
    }

I suggest you close this issue since the other issue has the actual problem and the proposed fixed.

[sonicmouse]

Thank you, @CrestApps. Is there a timeframe on the PR being merged? Sorry to be annoying, just trying to get info to management.

[MikeAlhayek]

I don't know if it'll get approved. Since it's not a bug, you can change the default behavior as stated above for now. WYSIWYG uses Tryumbowyg.

[sonicmouse]

@CrestApps fix worked for me, so I am closing this out due to the fact that this issue has already been reported.