Sensitivity and whether it detects HTML are configurable via theme settings.
Settings
Name
Description
emoji icon
The emoji icon to be displayed next to the title in the unformatted warning modal.
disable at trust level
Disable warning for users with a trust level of N or higher. -1 = enabled for all users.
sensitivity
Sensitivity of the detection algorithm. 0 = plugin disabled; 1 = warn for anything that looks even slightly like code.
min post length to check
Minimum post length to check (number of characters)
max post length to check
Maximum post length to check (number of characters). -1 = no maximum.
include html
Check for HTML tags as well as other types of code. Recommended to disable if users frequently need to render custom HTML in their posts.
Translation
Default
warning_modal.title
Are you posting code?
warning_modal.content
It looks like your post may contain code or logs. To keep your post readable, please remember to format your code using the Preformatted text toolbar button </>, or the backtick ` key on your keyboard, like so: [examples]
warning_modal.do_not_show_again
do not show this message again
warning_modal.fix_post
Edit Post
warning_modal.ignore_and_post_anyway
Post Anyway
Debugging
If you receive a warning for a post which doesn’t include any text, you can print debug information by opening the browser JS console, and typing debugUnformattedCodeDetector()Enter. This will print some information about which lines were considered ‘code’, and what the sensitivity settings are.
“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.
Hosted by us? Theme components are available to use on our Standard, Business, and Enterprise plans.
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?
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.
저는 다른 답변을 작성하다가 경고를 받았는데, 코드를 붙여넣은 적은 없습니다. 잠시 후 topic_id라는 단어를 사용했기 때문이라는 걸 깨달았습니다. 하지만 이 단어가 코드라고 감지된다는 사실은 직관적이지 않습니다(대부분의 사람은 그렇게 생각하지 않을 것입니다). 제 생각에는 단어에 밑줄이 있다고 해서 반드시 코드인 것은 아닙니다.
더 나쁜 점은, warning_modal.content 입력 필드에 클릭하여 포인터를 놓고 방향 키로 커서를 이동하는 것만으로도 입력 필드가 강조 표시된다는 것입니다. 아무런 변경 없이(단, 커서를 한 문자만 이동했을 뿐) 녹색 체크마크를 클릭하여 “편집된” warning_modal.content를 저장하면, 위에서 보여준 것처럼 포맷이 깨집니다.
@codinghorror@lionel-rowe 이 문제를 살펴보고, 공백과 백틱(특히 백틱이 많이 사용되는 “multiplelines” 섹션 내의 누락된 공백이 위의 문제를 일으키는 원인이었습니다)에 대해 기본 warning_modal.content를 조정해 주시면 좋겠습니다.
root@OpenWrt:~# ip link add link eth0 name eth0.9 type vlan id 9
root@OpenWrt:~# brctl addbr br-foo
root@OpenWrt:~# brctl addif br-foo eth0.9
root@OpenWrt:~# ip link set eth0.9 up
root@OpenWrt:~# ip link set br-foo up
“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.
- 제가라면 클릭하고 싶지 않은 버튼입니다. 물론 이것이 의도된 효과일 것입니다. 즉, 사람들이 글의 포맷을 더 잘 다듬기 위해 노력하는 대신 단순히 건너뛰지 못하게 하려는 것입니다.
