Investigate options for easier management of static content

[markspolakovs]

Currently the only way to edit the content of a static page is to PR this repo. The only way to create a new static page is to write a new controller, which involves modifying Go code, which is not ideal especially for non-technical folk.

The Holy Grail here would be some kind of CMS that 2016-site pulls its content from. Another option would be some kind of CMS that modifies this GitHub repo.

I'm opening this issue to consider options for this.

[MattWindsor91]

Questions here include:

• how often do static pages get changed (eg how much of an issue is this in practice)?
• how often do static pages need to be changed without computing team being involved in some way?
• who should get access to authoring tools? heads of team? station management? just computing team?
• how do these people get access to editing static content? MyRadio, presumably.
• what tools do they get/need -- raw Go templates, or markdown, or TOML, etc? how do things that aren't Go templates access cross-references back into the website content?
• how 'static' do the pages need to be, eg is it ok to have a database or cache query every time someone accesses them?
• what about history? what happens if you want or need to use part or all of a previous version of a static page?

Historic point: if I remember correctly, 2012site, being Django, used to store static pages in the database (!!) with an ostensibly user-friendly CMS backend based on a Django extension. I think this got dropped for 2013site because the cost of trying to replace it with something similar was too high when we could just have teams say 'I want this on this page' and have compteam do it. That and the Django CMS never quite meshed well with MyRadio. That and static content being in the database made me want to scream.

Could maybe have a semi-static system whereby there's a directory somewhere that has statics and that can be compiled hugo-style into templates or web pages that 2016-site can load.

On a side note, this reminds me of the idea of/issues around giving presenters microsites for their shows, and giving teams on-site blogs.