Link event content to extended Page-style content

[cogat]

Placeholder ticket - needs more scoping/thought:

There’s a challenge we have, which is to add trees (or at least a list) of (something like) Pages to an Exhibition. For example, to add a set of educational resources on an exhibit on “Horton Hears A Who?“. That happens in the Page tree, completely separate from any event.

What’s an elegant solution to attaching a “mini-site” of pages to an Event? Or - dare i say it - to an arbitrary piece of non-page content?

Internal slack discussion: https://theicteam.slack.com/archives/C1NNMP5EK/p1494302741870784

[jmurty]

In my research into options for accomplishing this, I have focussed on features of the underlying Fluent Pages project that we can use or repurpose, rather than thinking about what we could build from scratch.

I feel strongly that the less we build around or subvert Fluent Pages, the happier we will be long-term.

That said, here is a slightly perverse approach that could work with minimal interference with Fluent Pages.

Placeholder pages to act as root for Mini-sites

• create a new MiniSiteRoot page type with minimal features:

  • has a required generic foreign key (GFK) field site_context to some object in the system that is the root context for the mini-site, such as an Event
  • has a standard layout field, mainly to serve as the "base" layout for the mini-site
  • does not support any actual content, e.g. fluent contents, hero image etc
  • does not permit direct editing of the override_url field.

• when a MiniSiteRoot page is created, it sets its override_url to the get_absolute_url() value of the related site_context. Thus the page:

  • will be shown at the root of the page hierarchy in the CMS admin
  • will act as a parent for all mini-site sub-pages. Sub-pages can be created using standard page hierarchy management in the CMS
  • is never actually rendered directly, it is purely a placeholder for sub-pages. This should work because the page's full URL will match the URL of the related site_context item for which the URL matching will take precedence (an Event at URL path /x/y/ will be rendered in favour of a page at /x/y/)

• add a CMS admin feature to make it easy to create a mini-site (but probably only ever one?) for the model in the system for which this makes sense

  • could be as simple as adding a "Make Mini Site" button to relevant admins
  • perhaps add a read-only widget showing the related MiniSiteRoot page in the admin

• create separate page layout for the mini-site pages, if necessary. The main job of this custom layout would be to look up the site_context item related to the top-level page in the mini-site hierarchy, and style the page or render content from that item

  • we will probably want a get_mini_site_context() template tag or similar to look up the context item

Other thoughts and potential issues to consider:

• what does it mean to publish/unpublish a MiniSiteRoot page? The standard behaviour where publishing or unpublishing this page makes all sub-pages available or not is probably okay, though it might be unclear why publishing the page does not publish the related context item (unless we want to add this semi-magical behaviour?)
• I think we can and should avoid any kind of complex interactions between the MiniSitePage's context item and sub-pages, such as trying to automagically show only event occurrences related to an Event context item. Re-using event types and other existing filtering mechanisms should be sufficient, and much more straight-forward
• we probably don't want MiniSiteRoot pages to appear in search results or the sitemap, which might require some special handling
• given their quasi-page status, we should probably render MiniSitePages differently in the CMS admin. Perhaps a different colour, or icon, or similar
• we will probably need some signal handlers to keep the MiniSiteRoot's override_url field up-to-date with any changes to the associated site context item (e.g. event's slug is changed)
• is it okay for a MiniSiteRoot page to be deleted when its related context item is deleted? Probably yes.

[cogat]

This approach looks reasonable. Let's call them 'microsites' as they're a more commonly understood term.

Just wanted to check whether these actually need to be FluentPage types? Can they be a new type of fluent content, called EventChildPage, with an FK to EventBase? AFAIK these pages don't need to be in a tree. The main challenge then becomes about the UI for viewing/adding/removing pages from an event.

[jmurty]

My reason for making the placeholders fluent pages was so they will appear in the standard page tree hierarchy view and be manageable like other pages, including the ability to move existing pages into and out of the microsite without any fuss.

For example, this would allow ACMI to relocate their pseudo-microsite pages into a proper microsite structure, once this becomes available in GLAMkit.

I think that unless there is a hugely compelling reason we should avoid reinventing a whole page management UI just for this purpose.

Ideally the top-level page hierarchy management UI in the CMS would not be tied to fluent pages, but currently it is.