So I noticed some existing cheklists on my instance which were showing the older asterisk syntax. I decided to run the above rake task, but they don’t get updated.
IIRC most of the other checklists I have got silently migrated to the new syntax while I upgraded Discourse in past several weeks. But looks like there are some strange ones that the rake task is leaving behind. Anyone has any clues why that might be?
Happy to provide more info if it helps debug things.
Update: it looks one of such posts had the syntax [\*] (the one automatically generated on checking the checkbox from the UI). So perhaps that’s the case missed by the rake task?
The pages I am seeing all have the checkboxes at the beginning of the line. The question is whether the task changes both [*] and [\*] or just the former syntax?
Don’t checklists always start with a bullet marker (* or -) first [1, 2], so that the regex should match: - [\*]
which means this gets skipped because it is not in the first three characters anymore.
I later found other cases where I have nested checkboxes as well. So assuming they are the beginning of the line will also skip a lot of valid use cases.
PS: I realized the OP here does not use GFM checklist syntax (but only as of Aug 4 with the change to wiki by @sam), but I have been using that since forever. CommonMark spec that Discourse seems to refer to for markdown documentation doesn’t seem to support checklists yet. Is Discourse inventing its own variant of the checklist syntax? I would prefer sticking to the widely popular GFM syntax instead of diversifying it further.
Sorry, this seems confusing because things have changed fairly recently. I am referring to the screenshot shown at the plugin page that does not show the bulleted checklist syntax (and that the rake migrate task doesn’t seem to support):
It’s hard to see but the left side has bulleted checkboxes, but the current right side gets rid of the bullets, suggesting a different default checkbox syntax for new users.
Added later:
In other words, all of these are now supported using the checklist plugin:
[] first
-[] second
- [] third
rendered as
first
- second
third
while GFM tasklist spec only allows for the third variant (as a tasklist is a list):
A task list item is a list item where the first block in it is a paragraph which begins with a task list item marker and at least one whitespace character before any other content.
A task list item marker consists of an optional number of spaces, a left bracket ( [ ), either a whitespace character or the letter x in either lowercase or uppercase, and then a right bracket ( ] ).
If one wants to conform to the GFM tasklist extension spec, then the first two should not be allowed and not promoted in the plugin documentation.
Supporting the GFM case doesn’t mean not supporting the other cases. If you were to extrapolate that logic out it would necessitate lots of negative changes to the way Discourse handles all kinds of markdown formatting.
There are lots of apps which generate markdown checkboxes, it’s quite convenient to be able to paste lists into Discourse posts. What value is there in breaking compatibility?
One of the big issues with markdown is lack of a common standard (CommonMark is fixing that) and hence a variety of incompatible implementations. When there already exists a hugely popular check list extension in the form of GFM, why is there a need to invent another one? I was under the impression that Discourse devs were invested in CommonMark and standardization of markdown.
My issue is not with supporting alternate syntax, I believe in Postel’s law (even though I believe the above issue should have been taken into consideration when the latest syntax changes were done, ie, from [*] to [x]), it is with promoting an incompatible (with GFM) syntax in the plugin doc and not supporting easy migration of the GFM-like task list syntax to the newer format, which broke a lot of my pages on my Discourse instance, see my OP.
We did just make the change to make the syntax simpler. You can use [] anywhere in a post to make a checkbox. I don’t foresee us changing it again anytime soon. You’re more than welcome to create a fork of the plugin to implement what you desire, though.
