Main page footer can be overridden

[manics]

This allows the footer on the main (index) page to be replaced with custom HTML.

Related to https://github.com/jupyterhub/mybinder.org-deploy/issues/2156

Current default:

With c.BinderHub.main_footer_message = '<div class="row text-center" style="transform:rotate(10deg);padding-top:3em;"><h3>This is a custom footer message.</h3></div>':

I decided to override the main page footer instead of prefixing/suffixing it to give us more flexibility in layout.

[choldgraf]

Nice start! I think this would be enough to make good progress here. The other thing we might want is a button in the top right or something, but we could always absolutely position an element in the footer 🤷

The other page I had in mind was the loading screen, since that is a very common one for people to see 🙂

[manics]

I've updated it so instead of replacing the footer it's now a new section above the footer.... it should appear on the index and loading pages

Adding a button at the top should already by doable: https://github.com/jupyterhub/mybinder.org-deploy/blob/945d2accd7e400a0230ecd6be9e549d9281a762d/mybinder/values.yaml#L128-L129

[betatim]

I like it. My only nitpick is that "summary message" as config option name had me thinking "a summary as well, i thought we are doing the footer in this PR" -> why call it summary message? Somehow I was primed to expect it to be called a footer. What was your thinking around calling it summary instead?

[minrk]

We have established a pattern for ourselves of using extra_. Maybe extra_footer and put it inside the footer block (but not inside the footer container?)?

[manics]

Originally this was just to customise the footer on the main page (hence the now misleading PR title), but after feedback I attempted to give the property some sort of semantic meaning, since it appears in the main and loading pages, but not the others.

I could rename it to something like extra_footer, but since it's only for some pages I'm worried about creating an impenetrable mess of HTML configuration options where the only option is to grep the templates. Maybe that's the best option though?

[minrk]

None of these placeholder strings-as-config are necessary if using a custom template is practical, because all we need is:

{% block footer %}
custom stuff
{{ super() }}
{% endblock %}

and the only impediment to that is getting the template to the container via helm. Maybe that's what we should do?

I'm okay with this as-is as a short-term fix, though, since we are under some time pressure.

[minrk]

1472 supports arbitrary custom templates

[manics]

I like #1472