Backport ACMI templates to core

[cogat]

Goal: Make ICEkit (and events, collection, and press releases) front end more usable out of the box.

Bring across useful/reusable parts of:

• Django template filename/block structure, including: things in lists, main/related blocks.
• Thumbnails
• HTML/divs around content
• Opengraph tags
• CSS class names
• Programmatic navigation (breadrumb/parent/category links)
• blue preview/edit markers for logged-in staff - top-of-page and in lists

But leave behind:

• In-page navigation (the submenu stuff)
• Design, HTML/divs/css classes around design. ACMI's 3-column thing.
• Main/footer navigation (it's hardcoded)
• Key info blocks in lists and in the top of page.

Suggested approach: Start with ACMI, forget about preserving the ACMI-specific design, and make the ACMI template folder as small as possible by moving stuff into the packages.

Then start a new project and fix up/remove whatever broke on the way.

[markfinger]

• [x] Django template filename/block structure, including: things in lists, main/related blocks.
• [x] Thumbnails
• [x] HTML/divs around content
• [x] Opengraph tags
• [x] CSS class names
• [x] Programmatic navigation (breadrumb/parent/category links)
• [x] blue preview/edit markers for logged-in staff - top-of-page and in lists

[markfinger]

@cogat

Django template filename/block structure, including: things in lists, main/related blocks.

Can you point to any examples of what you'd like back-ported? I'm not too familiar with ACMI's implementation and much of what I've come across seems specific to the project or would be too difficult to extend the necessary flexibility for ACMI's requirements.

Thumbnails

Do you mean the thumbnail aliases in settings?

HTML/divs around content

Do you mean adding container elements around every content plugin's template, or do you have something specific?

CSS class names

I've been adding explicit and verbose classes to all the elements in the templates that I've been back-porting. Do you want me to also do an audit across icekit's templates to add this behaviour everywhere? If there are specific examples, can you provide them?

[cogat]

Can you point to any examples of what you'd like back-ported?

The blocks: hero, main_content (in addition to the existing content), related seem to be generally reusable.

The things in lists are that everything in ACMI knows how to render itself in a list. Most of that back-end work is in ICEkit already (see ListableMixin). But last time I looked, if you render a list in blank ICEkit, it's just a list of titles and links. Lists in ACMI have titles, one-liners, thumbnails, and edit links if you're logged in. Those should be part of ICEkit. Leave the ACMI-specific key_info for now.

Do you mean the thumbnail aliases in settings?

No, just the the thumbnails for things in lists.

Do you mean adding container elements around every content plugin's template, or do you have something specific?

I think that's it.

Do you want me to also do an audit across icekit's templates to add this behaviour everywhere?

Good idea.

[cogat]

On the hero - just render the fields in ICEkit's HeroMixin, it doesn't need to be more complicated than that.

[markfinger]

@cogat I've back-ported the requested bits and pieces into develop.

When ACMI's icekit version is updated, the feature/197-backport-templates-to-core branch will need to be merged in so that it points to the correct templates in icekit. Should I make a ticket on the ACMI repo for some visibility on that?

I'll take a stab at building an icekit project and fixing any issues that may have emerged.

Do you want me to tack on some basic type + layout styles for plugins and pages? I'm hesitant to add bootstrap classes in, as most projects will need to remove them eventually, but there's some worth in a temporary stylesheet which can be used during initial content entry.

[cogat]

@markfinger on a real quick/incomplete review in the agsa project, it didn't look like the front end had any kind of bootstrap installed. I think we're safe to ship icekit with a stable bootstrap installed.

I agree that the html should be as vanilla as possible, and we should accomplish what we need to in css to the extent possible.

If we are almost certainly going to override a template then we can be a bit braver with using bootstrap classes. For example, a template for the footer content could assume 3 columns since we are almost certainly going to implement project-specific footers. But for the content plugins we only want to override when absolutely necessary.

I think that the front end needs:

• bootstrap.css - vanilla bootstrap styles
• icekit.css - being styling for front-end admin features (the preview controls, and in future the review controls)
• site.css - or whatever you want to call it - a throwaway/replaceable/overridable set of basic styles. I'm not even sure if this needs anything beyond what's in bootstrap. Maybe it's a bootstrap theme? Maybe just some styles if necessary for things like header/footer. But if nothing else let's specify the name/location and make it an empty file, for consistency between projects.
• possibly typography.css - a stylesheet shared with the rich text editor for text styles?

[cogat]

@markfinger on further review:

see this logged-in view of ACMI:

[markfinger]

@cogat

• added bootstrap + font-awesome into the base template
• fixed the preview link hrefs (none of them actually linked to the admin page)
• improved the spacing between the list items
• related content now renders as expected
• list items are clickable

[markfinger]

Personally, I think some more spacing would be good. However, the bootstrap defaults are pretty small, so once we start spacing out the list items we'll need to start adjusting the headers + paras as well.