Unformatted Code Detector theme component



After installation, users posting unformatted code will see a warning message instructing them how to format it correctly.

Sensitivity and whether it detects HTML are configurable via theme settings.


  • “Do not show this message again” only works per device, not per user. This is a known issue and will be fixed once Discourse gains the functionality to attach user info from themes.

I do like this, but the mesage seems a bit too much IN YOUR FACE!!!

1 Like

As the purpose is to interrupt the posting flow and force the user to make a choice, isn’t that the point?


The message text is configurable through localization settings, but do you mean the message itself or the way it’s displayed? I’d certainly be open to suggestions on how to improve the user experience. @Stephen is right though — interrupting the flow is intentional. The challenge is to do so in a way that quickly informs the user without overwhelming them.


This is quite essential to our forum due to the fact that many new users ignore our topic about code formatting and most of our topics are about assistance in code. It makes our life much easier by informing them of informatted code. Thanks @lionel-rowe


v0.5 is now out. I’m gonna start documenting changes properly on this topic. I expect most updates from now will be dealing with edge cases.



Fix false positive on URLs containing snake case (e.g. https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Client-side_web_APIs/Client-side_storage)


Fix two more types of URL-related false positives:

  • Parens in path (e.g. https://en.wikipedia.org/wiki/LAN_(disambiguation))
  • Array query params (e.g. https://www.example.com?foo[0]=bar&foo[1]=baz)


Ignore strings like “O(n)”.


  • Ignore emojis (e.g. :slightly_smiling_face: => :slightly_smiling_face:).
  • Ignore special characters for copyright/TM/registered (e.g. Trademarked(TM) => Trademarked™).
  • Ignore anything formatted like a URL.

This is great, thanks for sharing!


Glad you like it! :smile:

v0.9 Changelog

  • Ignore anything within BBCode tags ([quote]s were triggering a false positive).


Will this recognize logs as “code”? If not consider this a feature request.

How do you identify an extract from a log-file? I guess it would suffice to look for a date/time at the beginning of two consecutive lines.

Another question: will ir work when people are using quote-formating (>) instead of code fences?

It will recognize logs as code if they happen to “look like” code (i.e. contain any of the patterns that would flag a post as containing code). You can test it out on your content at the demo link.

There are lots of ways to format a datetime, and not all log formats start each line with a datetime in any case. I guess detecting full ISO8601 representations (1970-01-01T00:00:00+00:00 etc.) would work, as these are very unlikely to appear outside of code or logs.

Anything in code blocks (fenced or indented) is ignored. Quoted blocks don’t receive any special treatment. Quoted blocks aren’t a correct way to format code, and may lead to unexpected results.

Example: the string <xml />

Block quoted (gets parsed away into oblivion):

Code fences (displays as intended):

<xml />

That’s exactly why I think it shouldn’t be ignored. People keep using quotes to “format” their code…


We at the Home Assistant forums think that this is the best thing invented since sliced bread. Or maybe Home Assistant. Thank you so so much @lionel-rowe!!!

Two minor request:

  • I don’t want to allow users to skip formatting or disable the dialog in the future. I want them to feel pain until they change their ways. I’m sadistic like that. Can you make the “Don’t show this message again” and “Post anyway” buttons optional? For now I’ve hid them with some CSS but would be better to just not include the HTML at all.

  • Unsure if you are doing language detection or not, but if you are, can you add the estimated language name after the first code fence so that users will properly syntax highlight too?

Thanks so much!!


I wouldn’t recommend hiding them, especially if you leave the setting to include HTML detection on. Power users may still want to have their (sanitized) HTML parsed as such, not formatted as code. Two examples where this can be useful are kbd and abbr tags.

If you exclude HTML tags from detection (which may be viable depending on the scope of your forum), hiding the “don’t show this again” would probably be OK. I still wouldn’t recommend hiding the “post anyway”, though, because there are bound to still be some edge cases of false positives (I hit one the other day where I’d omitted a space before an opening parenthesis — poor typesetting, but not unformatted code). Then you’ll have a situation where users can’t post their question at all, and, unless they report the issue to you directly, you won’t even know about it.

Language detection is beyond the scope of this component, I’m afraid. Where possible, it looks for syntactical features shared by many languages, such as lines ending in semicolons, certain configurations of curly braces, and so on.

I am thinking about ways to enhance the UX, though. One big improvement would be to make it much more interactive. For example, instead of a simple modal, the user would be presented with a wizard that first asks them which language their post concerns (select from a dropdown), then a screen which asks them to select which ranges of their post are code (defaulting to lines that contain strings flagged by the plugin), then generating the appropriate markdown. This would still include a “skip and post anyway” option, though, for the reasons I mentioned.

I don’t have a timeline for this change, but it’d be good to know if it’s something people would be interested in.


Already hit the edge cases issue within 30 minutes or so of hiding the elements, so they have been re-added.

I would be super interested in the modal being more interactive!

This is causing errors for the last month. As far as I can tell it’s as simple as updates needing to be made to certain components. Can you please address this as I’d really not like to spend my time forking and then maintaining my own version.

I realized that sounded bad and wanted to keep it for the record though, hence the edit. I just really need this theme component for my community as it’s constantly filled with people new to the language and forums in general. This component really helps, a lot. Please keep it maintained is what I should have asked instead of the robotic way I looked at the problem.

One possibility you have here is sponsoring some maintenance work. I am sure a $200 USD bounty in the #marketplace category would go a long way.


RIP this plugin. We had probably over 4 million users that needed this plugin on the Home Assistant forums. Will investigate putting a bounty on this.

EDIT: Actually, wait! This is fixed thanks to a minor change to settings.yml. Submitted PR here.


So the fix looked like it would work but i’m still getting CSP issues. Not sure if the extend_content_security_policy property in settings.yml has been deprecated or isn’t working and I don’t know enough Discourse code to know exactly how to patch this. Sorry to get everyones hopes up. Maybe someone will come along and figure out what’s wrong.

Here’s a working fix for the CSP problem:

Your PR was automatically updated since you previously created it with my non-working fix. :wink: