Provide "Cards" by default – a new hidden-path content type.

[olafgrabienski]

Description of the need

With 'existing content' blocks and 'hidden-path' content, Backdrop provides a powerful alternative to custom blocks: fieldable, translatable as any other content, and quite editor-friendly. I've got however a notion that many people aren't aware of its potential. Let's make the approach more visible and integrate it better into Backdrop by adding a new 'hidden-path' content type to Backdrop core.

Proposed solution

Add a third content type to Backdrop, and configure it for the use of existing content blocks. Display an example of such a content block, e.g. on the home page (see #4849 and #4867).

Alternatives that have been considered

1. Create a custom content type on my own sites. Works fine for me but doesn't make the approach more visible.

2. Build a contributed module with such a content type. Should be possible and might make the approach more visible. It couldn't be used in a vanilla Backdrop installation, though.

Draft of feature description for Press Release (1 paragraph at most)

Backdrop now includes a powerful alternative to custom blocks: the flexible and editor-friendly Promobox content type.

---

Advocate: @stpaultim

---

PR: backdrop/backdrop#3700
PR: backdrop/backdrop#3862

[olafgrabienski]

For reference, I've mentioned the plan for this feature request before in issue 4849, and there was some first feedback in a related issue thread:

Using existing content in layouts is (probably) the quickest way to construct landing pages and it's still easy to handle, with a familiar workflow (node forms).

But most of all: less privileged users can edit these content snippets without the need (or permission) to also edit the layout. This is something every site builder should know. And I'm not sure if they do.
#4867 (comment) by @indigoxela

---

I am very interested in the idea of a new content type for "info" nodes that can be used for blocks. Using this new content type for the new home page node makes sense to me. I'd like to hear more discussion on this idea (a new content type).
#4867 (comment) by @stpaultim

[olafgrabienski]

What would be a good name for the new content type? On sites built by me, I use to call it "Info block" or "Info box" (machine name info). It's not too long, and so far, editors understand the meaning of he name / the scope of the content type quite easily. Just "Block" wouldn't work, it would lead to confusion in content edit forms. "Content block" would reflect the characteristics of the content type quite good, but I don't like it very much. Are there other ideas?

[ghost]

The idea is an interesting one, but I'd suggest changing the issue title as the word 'block' there made me think that's what you wanted to call it, and so I started reading the issue already with doubts in my mind.

Maybe "Add a new 'hidden-path' content type" instead...?

[olafgrabienski]

I'd suggest changing the issue title (...) Maybe "Add a new 'hidden-path' content type" instead...?

Thank you, good point! I've changed it to "Add a 'hidden-path' content type for content blocks".
What do you think about it?

[klonos]

A perfect example use case for such a new "rabbit-holed" content type would be a "Slide". But we are getting into hairy territory there, because of the whole slide functionality. I realize that such a feature would provide great OOTB value for Backdrop (less contrib modules for end users to install, less configuration needed etc.). This would be similar to the great job we've done with the drop-down menus provided OOTB... but then you get into quests like which 3rd party library to use (needs to be well-maintained, have modern browser support, be accessible etc.) ...also should this be implemented as a single node with multi-value image fields, or a view display + individual nodes for each slide 🤔

[stpaultim]

A hidden path content type is accurate, but I don't think it's easy for new users to understand. I like "Info block," because that describes how I would most likely use it. But, it may be too specific or narrow. A default content type should be as flexible as possible.

Time to brainstorm:

• Info block
• Information
• Hidden path
• Hidden page
• Hidden content
• Flexible page
• Flexipage
• Flexi content
• Flexible content
• Pathless page
• Embedded
• Embedded content

What if we invent a new name for this type of content to avoid confusion and make it easy for us to define this usage with relatively clean slate?

• Dropblock (drops into other content? :-)

Here are how a few examples might look on the add content page along with some possible help text:

I look forward to new ideas...

[indigoxela]

In our latest backdrop-cms.de team meeting we've already been joking, that finding a proper name for such a content type might be the hardest task. 😆 Here we go...

• Pathless content
• Content snippet
• Content segment
• Page part
• Hidden path pane
• Embeddable

[mazzech]

I like both the idea from @olafgrabienski and the "Embedded" suggestion from @stpaultim. I use this exact approach in every single project, and I highly prefer it over Drupal's fieldable block entity approach (just try to explain the difference to a customer)

[philsward]

Comment redacted for being unrelated to the issue, but related to the overall discussion.

For context see: #4908 because it deals with removing the alias path field from entities.

[olafgrabienski]

@philsward Your suggestions are interesting but I guess they are too general for this thread. Can you open a new issue for your idea, I guess as a follow-up of Add a system of page-less nodes?

[philsward]

@olafgrabienski ah, this is about adding a new content type to the install profile, right? Yeah, totally different. I didn't quite understand the concept at first. I'll remove my previous comment.

[klonos]

...finding a proper name for such a content type might be the hardest task.

But it's fun! 😅 ...OK, I'll get onboard with the name bike-shading:

• Dead-end content
• Cul-de-sac content
• Blind-alley content
• Phantom content
• Ghost content
• Area 51 content
• Area 15 content (separate to the government-controlled one, but equally secret/restricted; controlled by civilians)
• Catch 22 content
• Obscure content (trying hard to refrain from making Harry Potter puns)
• Diagon Alley content (I couldn't help it)
• Fake news 😅 (I certainly couldn't help it)
• Vogsphere content
• Bouncer content
• Gandalf content (best bouncer of them all ...you-shall-not-pass!) 😅 😅

[olafgrabienski]

I like "Info block," because that describes how I would most likely use it. But, it may be too specific or narrow. A default content type should be as flexible as possible.

This was my first thought as well. Thinking about it again, I wouldn't try to cover too many use-cases with the new content type. Let's compare it to Posts which are a simple example of dynamic content usually displayed in lists: Posts work out of the box for a news section, or for a blog (both sorted by post date), perfect. Now, if I want to display something different in a list, e.g. events, I'd add an Event content type, add a date field, and provide a different sort criteria (not by post date but by event date) in Views. Even if this use-case isn't covered by Posts, the Post content type helped me to understand that Backdrop is able to build dynamic lists of content (in contrast to how the more 'static' and menu related Page content type works, at least usually).

I could also tweak the Post content type for Events (instead of adding a new type), but I'd say that's not within the scope of providing Posts in Backdrop out of the box. In the same way, an Info block could be tweaked for holding let's say slideshow pictures, but I'd suggest a more narrow main scope: providing 'hidden path' content for Existing content blocks.

That said, I see that "Info block" may still be too specific. My current favorites are "Content snippet" and "Embeddable". The latter would go fine with the description text when adding Existing content blocks (Embed existing node content as a block onto other pages), on the other hand it may be hard to translate. Are there arguments against "Content snippet"?

[klonos]

(sorry)

[olafgrabienski]

"Content snippet"

Or just "Snippet"? The name will primarily appear on pages like "Add content" and "Manage content", so the "content" part of the name might not be necessary.

[stpaultim]

"Snippet" is very vague to me. I'm not sure what it means in this content, but maybe that is a feature and not a bug, if the description helps define it?

[klonos]

Google defines it as "a small piece or brief extract.". Provides some synonyms/similar words too:

The word seems to have an increasing popularity over the last portion of the last century, and steady usage during the 2000s.

[mazzech]

I use the name "Promo Box" ("Promotionsbox" in German) in all my customer projects, and will rename it accordingly;-)

[olafgrabienski]

"Snippet" is very vague to me (...) but maybe that is a feature and not a bug, if the description helps define it?

Definitely needs a help text. In contrast to other situations, people will probably read it :-) I'll try to provide some mockup screenshots to get an impression. Btw, "Snippet" reminded me the term "Widget". Widgets are / where a very popular feature in WordPress, and it's an example for a vague name that seems to work good.

[olafgrabienski]

Here we are, some mockup screenshots to get an impression of the look and feel of the "Snippet" suggestion:

(1) Content types:

(2) Add content:

(3) Manage content:

(4) Edit Snippet:

(5): View Snippet in context:

[klonos]

I like that @olafgrabienski 👍 ...it showcases a very simple example of how these "snippets" can be used.

[mazzech]

I like that too @olafgrabienski

[stpaultim]

I wasn't sure at first, but I think "Snippet" works for me. I don't have a better idea yet, but I'm still listening...

While, I like the idea for a snippet content type, I would suggest that we ask the following question

"If we are going to add a third default content type to Backdrop CMS Core, is this the one that is most needed?" Because, I don't think we can add (m)any more.

[klonos]

...I don't think we can add (m)any more.

This is where having something like #3763 could be helpful I believe.

[olafgrabienski]

If we are going to add a third default content type to Backdrop CMS Core, is this the one that is most needed?

Well, I haven't heard of another suggestion for a long time (if ever). Did I miss something?

[quicksketch]

I posted to the PR as well, but I think we should go ahead and get this merged. We have the separated issue for the image style at #4903 and we can make another issue if needed to change the default image.

[stpaultim]

@jenlampton has raised a couple of possible changes that have I have rejected for now and explained my reasoning in the PR discussion (mostly because the current code is consistent with other things and if we make changes, we should probably make similar changes for other content types or fields). These are all issues that can easily be discussed and changed later without significant changes in the functionality of this PR.

We need a "Works For Me" label and I assume one more Code Review before we mark this RTBC. Anyone?

Can someone clarify again, where the translation update comes in?

[stpaultim]

I posted to the PR as well, but I think we should go ahead and get this merged. We have the separated issue for the image style at #4903 and we can make another issue if needed to change the default image.

@quicksketch For what it's worth, I'd be happy to see this happen anytime. If small changes need to be made without me, go ahead and make them and get this merged. We can then open up whatever follow-up issues we need, which will be much easier to deal with independently.

[quicksketch]

Can someone clarify again, where the translation update comes in?

Usually after release, @olafgrabienski downloads the release zip file and uploads it to localize.backdropcms.org, where strings are extracted and translators work from there.

[bugfolder]

Seeing as it looked like all issues in the PR got addressed in the last day, I downloaded the code from the PR and ran through a fresh install.

• Installation proceeded fully without problems.
• There are the three cards, looking nice.
• Links to documentation head to the right place. ("Creating Content," the destination of "Learn more about Cards", should get updated after release.)
• The destination of "Learn more about the Home page" is the currently unpublished "The home page". So this page should get published immediately upon release.
• The new View is titled "Promoted cards" and its Block is "3 promoted Cards", in keeping with the existing "Promoted content" View. Check!
• Image styles are unchanged.

Everything looks good. Gonna remove the "Needs testing" label (I see it already had WFM.) I looked through the code, didn't see anything amiss, but I think sharper eyes than me have already looked at the code anyhow.

[quicksketch]

I have merged backdrop/backdrop#3862 into 1.x for 1.22.0! 🎉 🎉 🎉

This was a huge effort with a lot of opinions (it is the homepage after all!) and I'm happy we reached conclusions on almost everything. Thank you everyone for your patience as we worked out an acceptable solution. We have a follow-up regarding the image styles at #5593, and I encourage folks to make new issues as needed for adjustments. The exciting thing is we got this completed for the next release.

The credit list on this one is longer than any I remember. I included everyone who made multiple posts that were beyond the voting and simple preference statements (though those have been useful too!) Big thanks to everyone in this issue.

backdrop/backdrop@c429a72 by @stpaultim, @olafgrabienski, @docwilmot, @herbdool, @bugfolder, @BWpanda, @jenlampton, @quicksketch, @indigoxela, @philsward, @klonos, @laryn, @diannevolek, @wesruv, @yorkshire-pudding, @irinaz, and @albanycomputers. 🎉

[stpaultim]

Wow! Good work everyone.