Change help text in stream field to RichText

[frjo]

Fixes #3293

Test Steps

• Test that the "Help text" field in each stream form field in application forms, review forms etc. has a rich text editor.
• Confirm that any old "Help links" have been migrated into the "Help text" field as links.

[frjo]

@wes-otf This PR removes the help link field and migrate any existing links as markdown links and the end of any help text.

The help text field already accepts and renders any markdown you add to it.

What's missing yet is a markdown editor for the help field, if that is needed.

[frankduncan]

For our part, a markdown editor is important to our clients.

[frjo]

Tested a number of ways to get a Markdown editor on the help text field but found no clean way of doing it.

Current version converts the field in to a Wagtail RichTextBlock instead, just like @frankduncan PR.

[frankduncan]

The best thing we've found in a different project was importing the js-only library wysimark and writing javascript to populate and pull the information out. I'm not sure how that would interact with the wagtail admin stuff.

I know wagtail has some javascript events (we used it in our email configuration code) that you can hook into to do things.

[frjo]

Normally I default to markdown but in this case I think rich text is the better option.

All other fields that have formatting are already using the wagtail rich text editor. The consistency is appreciated by staff I think. The editor is quite nice as well.

This PR is now very much a copy of #3293 with the added migrations of the help link field.

[wes-otf]

I had no idea the help text fields would render markdown as is, basic formatting in help text has been a request from staff for a little while so that info will fix some issues in in the interim.

I see no issues with converting this to RichText though. It looks like the help text fields are stored in raw markdown format so we'll also probably need a migration that converts existing fields into HTML

[wes-otf]

this could also probably be tossed right?

[frjo]

Good catch, yes the markdown filter can go and likely the nh3 as well since this is not user generated.

Or we could consider adding nh3 to all outputs, as an extra safety measure.

[frjo]

@wes-otf If OTF is not using Markdown in the help text as of now I suggest we get this deployed soon and avoid more migrations.

[wes-otf]

OTF isn't using markdown but even plaintext will still need to be wrapped in a <p> tag for rich text (if I'm understanding how richtext is stored) so a migration might be necessary. not sure if any adopters have used it either

[wes-otf]

also makes sense to use nh3, maybe we should also do that for paragraph blocks too just for uniformity

[frjo]

The nh3 filter gives an error used alone here, unsure why but it is not really needed anyway so removed it.

The migration is working as it should in my testing. Old as well as new text are rendered correctly with p-tags and all.

[frjo]

@wes-otf Can you give this a test locally before we deploy it to the test server?

Some complex migrations that would mess up the test db if there are bugs.

You can revert the test tb but it is a bit of a hassel.

[wes-otf]

yes! I'll try it out today

[wes-otf]

I think it's ready for test! tested it with existing help text strings (non-markdown) and things migrated totally fine and the rich text displayed as expected

[wes-otf]

@frankduncan just wanted to confirm none of your adopters use markdown in the help text field currently?

[frankduncan]

@wes-otf Correct, none of them use markdown.