No way to meaningfully customize EntryCards (list/grid cards)

[MilesRomney]

Summary

Given the flexibility of the collection system, it's highly incongruous to strictly limit the visible summary on list and grid cards to a single line of un-formatted text. At some point, this may warrant a customization system parallel to what's now available for previews, where modules are created for each collection type that define their list and grid cards—that would be a best-case scenario.

In the meantime, the same result can be achieved by simply allowing the configured collection summary (what in the EntryCard.js is assigned to the "title" constant) to include HTML tags. That, paired with currently-permitted CSS overriding, would give developers a lot of freedom in designing list and grid cards.

This can be achieved simply by rendering EntryCard titles using dangerouslySetInnerHTML. Then, cards could easily be configured on a collection-specific basis.

Example

In config.yml, consider a collection with the following summary:

summary: "<img src='{{portraitimage}}' /> <span class='fullName'>{{fullName}}</span><span class='impact'>{{impact}}</span>"

... with this CSS added to static/admin/cms.css:

h2[class*=ListCardTitle] img {
    max-width: 100px;
    float: left;
    margin: 0 20px 20px 0;
}

h2[class*=ListCardTitle] .fullName {
    font-size: 1.2em;
    font-weight: bold;
}

h2[class*=ListCardTitle] .impact {
    display: block;
    font-size: 0.95em;
    margin-top: 10px;
}

This would result in an EntryCard that looks like this:

I've prepared a branch in my fork with this change: MilesRomney@0c6a719

[kylekirkby]

@MilesRomney - can you submit a PR for this change? Would be great to get this implemented!

[MilesRomney]

Hey @kylekirkby, yeah I did, but @erezrokah clarified that they follow a carefully planned feature roadmap, and don't accept PRs without long-standing community discussion. (Fair enough.) So it's a non-starter for now.

The change is only one line of code (twice). Here's the commit on my fork: MilesRomney@0c6a719

I've packaged this up and made it available on a Verdaccio instance if you'd like to use it. Add a .npmrc to your project with the following contents:

registry=http://npm.pkg.maststudio.org/

Then in package.json these are the netlify-cms versions you'll need:

    "netlify": "^2.4.8",
    "netlify-cms-app": "2.10.0-beta.3",
    "netlify-cms-media-library-cloudinary": "^1.3.2",
    "netlify-cms-media-library-uploadcare": "^0.5.2",

(The -beta.3 is the custom version that includes this feature.)

You'll also need to add a bit to your build routine in package.json, to copy an index.html into place that calls your custom stylesheet:

  "scripts": {
    "build": "gatsby build && cp static/admin/index.html public/admin/index.html",

And then, it's pretty sweet. :)

[erezrokah]

Hi @MilesRomney, sorry for not being clear enough. We would love a PR for this (referencing your previous pr for reference), but it should be implemented in a way that is consistent with the other methods of extending the CMS (e.g. registerEntryCard or something similar).

[austincondiff]

@MilesRomney take a look at the UI we are working towards in #2557. Would this fit your needs where the columns displayed would be configurable according to entry fields? Otherwise, it may be worthwhile to think about registering a custom entry card as you mention.

[MilesRomney]

@erezrokah do you have documentation, or an example of what you're looking for? This is what I was following when I submitted the PR:

https://github.com/netlify/netlify-cms/blob/master/CONTRIBUTING.md

Not a lot there, and "other methods of extending the CMS" is pretty broad.

I found this reference to registerEntryCard, but it hasn't been merged, so it's likely not a good example to follow. Looks like several people have taken a crack at this feature, in fact, but none has been merged.

The registerEntryCard implementation is perhaps more elegant, but it's also far more invasive to the codebase and more difficult to use—both of which factors (absent a clear style guide) I assume would make the PR less likely to be approved and not more. And I'm finding plenty of examples in the commit history where minimal changes to existing modules are accepted, very similar to what I've submitted.

So I'm left to guess, and well, "ain't nobody got time for that". ;)

Seems like you all have a specific idea of how you want this feature implemented, so the community should just leave it alone, and let you get to it when you get to it. Your show. Your rules. It's cool.

[MilesRomney]

@MilesRomney take a look at the UI we are working towards in #2557. Would this fit your needs where the columns displayed would be configurable according to entry fields? Otherwise, it may be worthwhile to think about registering a custom entry card as you mention.

@austincondiff that's a very nice improvement. God speed. :)

On the face of it, it doesn't seem to accommodate custom cards per collection type, but the default columned rows are a significant step up, and are something I'd live with.

It's a great product, team—thanks for your work.

[erezrokah]

@MilesRomney I appreciate the feedback and we should do better in terms of making it clear on how to contribute. You are more than welcome to suggest topics here. I was waiting for some more feedback in order to schedule office hours, but I might just decide on a time and share a zoom link.

I couldn't find a PR with the registerEntryCard implementation (just a fork with it).

Previous work on customizing the entry cards was merged in here via the summary field and closed #2019, but that work doesn't satisfy this issue.

I think this boils down to 2 big features:

1. Theming (e.g. changing colors) - can/should be covered in Improve The Overall UX #2557.
2. Customization - being able to swap any default view/component with a custom one (see this comment).

And 1 smaller feature of replacing the entry card component which is the relevant discussion for this issue. This can actually pave the way for the customization feature.

From now on, let try and keep the discussion specific to the issue at hand and have contribution related comments here.

[austincondiff]

@erezrokah @MilesRomney work is being done by @fpunny to implement the design in #2557. If any additions need to be made, please speak up in #3265.

[steveramos]

Thanks... this is going to be a big help for me until #3265 gets merged in somewhere down the line.

I have use cases wherein we're using entries like calendar events and recurring events just look like this in the Collections Entry UI:
Board Meeting
Board Meeting
Board Meeting
Special Event
Board Meeting

It would, at the very least, do a world of good to show wherein the dates provided are not created dates, but rather dates input by users:
Board Meeting – 2020/04/01
Board Meeting – 2020/05/01
Board Meeting – 2020/06/01
Special Event – 2020/06/15
Board Meeting – 2020/07/01

[erezrokah]

It would, at the very least, do a world of good to show wherein the dates provided are not created dates, but rather dates input by users:
Board Meeting – 2020/04/01
Board Meeting – 2020/05/01
Board Meeting – 2020/06/01
Special Event – 2020/06/15
Board Meeting – 2020/07/01

This should be available via the summary field:
https://www.netlifycms.org/docs/configuration-options/#summary

You can reference entry fields, e.g. summary: "{{fields.eventName}} - {{fields.eventDate}}"

[steveramos]

@erezrokah thanks for the tip! I found it in docs just after I posted. I guess I haven't looked into solving this problem in a year and was considering it again while contemplating a new project. Didn't realize it had been addressed since then and I didn't see it at first in docs.

This is really going to help us out! Looking forward to more UX changes as seen in the Invision prototype in #3265

For future reference, anyone know a straightforward way of searching keywords against releases in a repo?

[d4rekanguok]

I think registerEntryCard would be really cool. Any pointer on what the api could look like? Maybe just something simple as this?

CMS.registerEntryCard({
  collection: 'post', 
  component: PostEntryCard
})

[erezrokah]

Hi @d4rekanguok, there is a fork with registerEntryCard:
https://github.com/campus-online/cms/pull/9/files#diff-eb94ebda6978caacfbd4f13e52cd062aR136

registerPreviewTemplate uses registerPreviewTemplate(name, component)

[joernroeder]

I would love to see this coming alive. a similar approach could also work for the summary of list widget items.
I'm often use a relation field combined with some context specific fields. A good example is a masonry style grid of posts, where some items span across multiple lines. It would be awesome to also reference e.g. the title and image of the linked, nested post combined with the sizing for this entry in the summary. It seems that currently I'm stuck with the value of that field.

- label: "Grid"
  name: "grid"
        widget: "list"
        summary: '{{fields.post.title}} {{fields.post.tags}} – {{fields.size}}'
        types:
          - label: "PostType1"
            name: "post-type"
            fields:
              - label: "PostType1"
                name: "post"
                widget: "relation"
                collection: "post-type-collection"
                searchFields: ["title", "tags"]
                displayFields: ["title"]
                valueField: "{{slug}}"

              - label: "Size"
                name: "size"
                widget: "select"
                options:
                  - { label: "Large", value: "large" }
                  - { label: "Default", value: "default" }

[michaelteter]

Is there any solution yet for customizing the collection list cards?