Hooks for CSS and JS shouldn't allow full HTML insertion

insert_editor_css insert_editor_js insert_global_admin_css insert_global_admin_js

Is there a better way for these hooks to work? Related: #2333 #2276

They require the user to insert the full HTML. This opens potential for abuse where people could use them to embed things other than styles or scripts. Implementations look something like this:

@hooks.register('insert_editor_css')
def editor_css():
  return format_html('<link rel="stylesheet" href="' \
  + settings.STATIC_URL \
  + 'demo/css/vendor/font-awesome/css/font-awesome.min.css">')

I think it would make more sense to pass in a file (and maybe some options) rather than a full HTML tag.

That way people can’t possibly misuse them, and we have more control over how the content can be rendered.

My first thought is to make it look something like this:

@hooks.register('insert_editor_js')
def editor_js():
  return {
    'files': [static('demo/js/myscript.js')],
    'options': {
        'async': True
    }
  }

StreamField blocks implement something similar. Here is how a ListBlock gets its assets. This is implementing Django Form Assets, which could also be a great way to accomplish this. It allows for options to account for optional HTML attributes like CSS’s screen (not sure about async for JS though).

Ideally, I’d like to see a hook implementing this. Maybe it could look like:

from django.forms import Media
from django.contrib.staticfiles.templatetags.staticfiles import static

@hooks.register('insert_editor_assets')
def editor_assets():
    return Media(
        js=[static('myapp/myscript.js')],
        css=[static('myapp/mystyle.css')]
    )

It appears to be the standard Django way, and it’s already what we’re using for StreamField.

[alexgleason]

I don’t have a problem with letting people insert arbitrary HTML, it’s not that at all. If the hook were named insert_admin_markup_head it would make sense. But the hooks don’t actually do what they’re named to do, and I see a potential for them being misused for that reason. Someone wanting to insert arbitrary HTML could do it within insert_css, which would be wrong.

I mean, at the end of the day, if it works it works. But I don’t want to be like PHP. I think we need to be super careful about hooks because people (like me) are starting to make Wagtail plugins, and god forbid we’re in a “stuck with it this way” situation for 20 years when Wagtail becomes the most widely used Python CMS.

[gasman]

Closing this now, as I don’t think we’re going to come to any conclusions here. Our approach to front-end asset management in Wagtail has and will evolve - but however much the cheap-and-cheerful approach offered by these hooks falls out of favour, I think they’ll still be useful as a lowest-common-denominator, and it would be counter-productive to drop them or replace them with something less flexible.