html in error messages displayed

[timelsass]

[dingo-d]

Probably a parsing error, good catch. If you can provide a theme that generated that, that would be great 🙂

[timelsass]

here's twentyninteen the example code from https://developer.wordpress.org/reference/functions/add_menu_page/ added for testing: twentynineteen.zip

[timelsass]

It looks like that change would introduce another issue of loading unwanted iframe content:

[timelsass]

added a7b6ae1 to check for iframe before output

[dingo-d]

I guess there was a reason after all for futting .text() instead of .html() after all :D

[dingo-d]

Merged the PR and it works 👍 Thanks!

[DannyCooper]

I'm seeing something similar to this, the authors code isn't great but still...

[timelsass]

Ah, yeah that makes sense - I'll have to take a look at what all the messages are actually outputting to come up with a solution. I didn't give thought to if/when HTML is being output from other sniffs. I'm not sure why that one message includes HTML around the function either since the rest don't seem to do that.

[dingo-d]

Maybe we could strip tags before outputting the message?

[joyously]

So it's just that the messaging to the user is sometimes wanting HTML and most times should show HTML?
At the point of output, the code doesn't know what's in the message. I don't think it should be escaping there. This is a case where late escaping hurts. The individual messages should be escaped where needed, since that's the point the code knows it's needed or not. The user should see the actual code that was in error, so it should not be stripped. And if there needs to be something in bold, that should be available also.

[dingo-d]

Stripped in the theme sniffer 🙂 so that we don't have html in the output. I should have been more precise

[joyously]

That was my point: sometimes it is correct to have HTML in the output. The message should not be stripped since it can contain HTML that is part of the message. If you strip the HTML out, the message doesn't convey the correct thing.

I think the fix that already went in for this was the wrong fix. The fix should have been to remove the <strong> tags from that one message, because the more common case is that messages need to contain exact code from the theme accurately report the problem.

[timelsass]

yes I agree with @joyously - especially given that no other messages really appear to be wrapping things in HTML - that one should definitely follow suit. Sent over PR for WPThemeReview

[dingo-d]

This has been fixed?

[timelsass]

the upstream has been for that message - I was using some HTML for some things in the license check messages though. Since we control the output of the messages we create, I think we can look at messages.message.source to verify it's our message, and then enable using html for the ones we have control over.