[RFC] Template specific fields

[Pinpickle]

Sometimes pages are sufficiently different from each other that using the same fields for both of them will make one, or both of the pages, not entirely editable. Say your home page is full of different sections describing the various areas of the website, some pulling information from other records and some statically sitting there - while your about page has has two columns that each have very different content, followed by a large image. Your client wants to edit everything.

I think this was the concern illustrated in #2476 and some solutions were identified but they're either clunky (having 'resource' records that will require a lot of jumping around to edit a few things) or not possible to edit (choosing a template that has all of the information hard coded in). What we can do, which will clutter the sidebar, is create a separate contenttype for every different page type. I've done this where the only substantially different page was the home page and it worked okay.

But as far as real, intuitive solutions, I see two possible ones (and I think both of them should be implemented):

1. List fields (#2261). This will be the killer because it will allow people to add content "blocks" akin to the matrix field in Craft CMS (as well as all of the other advantages). Hopefully this is coming in Bolt 2.1 and with some time I'd like to help out with that as well.
2. Template specific fields. This issue is about this method.

Essentially, you outline fields in the theme's config.yml the same way you do in contenttypes.yml:

template_fields:
 - template: homepage.twig
   fields:
      section_1_image:
          type: image
      section_1_text:
          type: html
      map_location:
          type: geolocation

When a record uses a particular template (based on the record name, contenttype name or template chooser field), these fields will be displayed on the next refresh of the record. They'd be JSON encoded into a column specifically for template fields on save. When accessing the page, they'd be de-encoded and accessed on the record object like anything else:

{{ record.section_1_text }}

Or if there are any worries about conflicting names, this could easily go under its own namespace

{{ record.template.section_1_text }}

And that's the idea! I can easily see this being considered as out of scope, but it's been floating around in my head for the past few weeks so I thought I'd at least get it written down.

[bobdenotter]

I was thinking about maybe creating a 'blocks' field type, that would just be a wrapper for Sir Trevor.

[Pinpickle]

Where has this been all my life? This is all we need for a list contenttype, though its really minimalistic design will stick out a bit in the interface.

Can we make everything look like this?

However, that's more of my first solution. The per-template contenttypes are for layouts that are more rigid and defined.

I may start on trying to make wrapper for Sir Trevor tomorrow when I get a chance.

[tobias2k]

Incidentally, I've been playing with this idea on a different project; it would fit perfectly with the EAF solution @rossriley and @GawainLynch have been talking about so much. Basically, instead of contenttypes, you'd just have records and fields, where each field is what SirTrevor calls a "block" (arbitrary JSON, annotated with a type that determines how it is edited and rendered), plus a bunch of mechanisms to categorize and cross-link records. This would be something for a Bolt 3.0 though...

[Pinpickle]

That sounds very intriguing! Starting to get vibes of thegrid.io from that.

[serweb-labs]

Wow did not know "Sir Trevor". I had a similar idea and I was working with json as an extra field in contenttype pages for a while, this certainly goes a step further and I'm glad you have mentioned.

[bobdenotter]

It landed! :tada: :sparkles: :tada: :sparkles: :tada: :sparkles: :tada: :sparkles: :tada: :sparkles: