Just like you can use a RichTextField/RichTextBlock in Wagtail (powered by hallo) without the need to configure it, wagtaildraftail should ship with proper defaults (all the default entities, blocks and styles in the editor and the corresponding exporter config).
For the editor, this might be a bit more complex. If a widget doesn't not receive any options upon initialisation, we could add some defaults, but for the widget to be instantiated in the first place, it needs to be present in the WAGTAILADMIN_RICH_TEXT_EDITORS settings (which is used by wagtail.wagtailadmin.rich_text.get_rich_text_editor_widget which both our field and block use to load the widget). I'm not too keen to hijack the settings to inject ours, so maybe we could have a intermediary utility function which first try to load "the Wagtail way", but failing that (catch KeyErrors) would return our default widget.
Just like you can use a
RichTextField/RichTextBlockin Wagtail (powered byhallo) without the need to configure it,wagtaildraftailshould ship with proper defaults (all the default entities, blocks and styles in the editor and the corresponding exporter config).For the exporter, everything can happen in wagtaildraftail.utils.get_exporter_config.
For the editor, this might be a bit more complex. If a widget doesn't not receive any options upon initialisation, we could add some defaults, but for the widget to be instantiated in the first place, it needs to be present in the
WAGTAILADMIN_RICH_TEXT_EDITORSsettings (which is used bywagtail.wagtailadmin.rich_text.get_rich_text_editor_widgetwhich both our field and block use to load the widget). I'm not too keen to hijack the settings to inject ours, so maybe we could have a intermediary utility function which first try to load "the Wagtail way", but failing that (catch KeyErrors) would return our default widget.