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 https://github.com/backdrop/backdrop-issues/issues/4849 and https://github.com/backdrop/backdrop-issues/issues/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: ~https://github.com/backdrop/backdrop/pull/3700~ PR: https://github.com/backdrop/backdrop/pull/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. https://github.com/backdrop/backdrop-issues/issues/4867#issuecomment-758764761 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). https://github.com/backdrop/backdrop-issues/issues/4867#issuecomment-759089160 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. :laughing: 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: https://github.com/backdrop/backdrop-issues/issues/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?

[klonos]

I haven't heard of another suggestion for a long time...

I've always heard others (at least @jenlampton IIRC) mention "Slide" nodes and a slideshow block as a use case: people should be able to view the slideshow, but not access the individual slide nodes.

[jenlampton]

I just built a FAQ page yesterday this way too, it's also a common pattern.

On Thu, Jan 28, 2021, 6:36 AM Greg Netsas notifications@github.com wrote:

I haven't heard of another suggestion for a long time...

I've always heard others (at least @jenlampton https://github.com/jenlampton IIRC) mention "Slide" nodes and a slideshow block as a use case: people should be able to view the slideshow, but not access the individual slide nodes.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/backdrop/backdrop-issues/issues/4903#issuecomment-769108815, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADBER4C6TACOQKMBJOP46TS4FY73ANCNFSM4WQ4DY5Q .

[olafgrabienski]

Coming back to this question by @stpaultim:

"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.

I agree, we probably don't want to add many more content types to Backdrop out of the box. My answer from yesterday (not heard of such suggestions for a long time) was a bit short, but I still think it's right. At least in terms of formal feature requests, I don't recall any proposal for a new content type. And that's no surprise, for a new content type there have to be really good reasons.

In contrast to other potential 'hidden-path' content types (Slide, FAQ), the "Snippet" approach is more general. It would help to expose not only the 'hidden-path' feature but also the great tool of translatable and editor-friendly "Existing content" blocks in Layouts. So, the "Snippet" type would really fill a gap, in my opinion. It would even help to implement https://github.com/backdrop/backdrop-issues/issues/4849 and/or https://github.com/backdrop/backdrop-issues/issues/4867 in a nice way.

I'm curious what others think. Maybe also worth a discussion during the weekly meeting?

[jenlampton]

My only concern with adding a Snippit is the name. It's likely that nobody will know what it is, so nobody will use it. This word is yet another abstract noun like node, entity, bundle, etc, and has no meaning on its own, which makes it hard to understand. If we can provide something that has a concrete use, like a slide, people will immediately understand what it should be used for. (I'm not advocating for slides, but they do make a good example)

[stpaultim]

We did talk about this issue in the design meeting yesterday. See 12:00 min into meeting (we talked about it for about 12 minutes). https://www.youtube.com/watch?v=FsEVAkVdXQ8

My summary of the discussion:

@jenlampton - says that she is on the fence. She can see how it would be a good learning tool, but hopes that it doesn't get in the way of the many users that don't need. Acknowledging that it's easier to remove a content type than to create one.

While providing this content type out of the box would make it easier to understand, there might be better ways to help users understand that. For example, we should make the existing help text for path-less nodes much better.

It was suggested that maybe calling these "fieldable blocks" would be descriptive, it would help people understand and compare this to the equivalent Drupal 8 feature.

[olafgrabienski]

Thanks for the link to the meeting video, @stpaultim, really an interesting discussion! (Btw, you can link directly to a video part putting the time in the URL, e.g. https://www.youtube.com/watch?v=FsEVAkVdXQ8&t=12m01s.)

To call the content type "Fieldable blocks" while it remains a content entity could help to explain (part of) the concept. On the other hand, it can be very confusing. I guess, it would raise way more problems that it would solve.

Anyway, what's still missing for a new 'hidden-path' content type seems to be a good name. I share the concerns of @jenlampton against "Snippet" (another abstract noun like node, no meaning on its own). However, in context it works surprisingly good. Actually, the idea came from @indigoxela's suggestion "Content snippet"; this term isn't abstract at all, only a bit long, in my opinion, but I don't know if that's really a problem.

My current state of mind: Let's see if a hidden-path content type would be useful for https://github.com/backdrop/backdrop-issues/issues/4849. If that's the case, it makes sense to provide the content type and to choose the name considering primarily that use-case.

[philsward]

I have a feeling that pretty much any name is going to end up being pretty arbitrary.

Looking at the term "slug", Wordpress uses it for the path of a page. It doesn't mean anything to really anyone who hasn't been around wordpress or other platforms that use that term (I had never heard it called that until WP). Point is, it's a taught term. You learn what it means by using the platforms that use that term.

I think at the end of the day, the best we can do is give it a good description and teach people what Backdrop wants it to mean.

I'm neutral on "Snippet" but of the suggestions, it appears to be the most ambiguous yet most descriptive word that could be used to describe a node without a path.

Are there existing D7 modules that might conflict with this namespace?

[olafgrabienski]

Are there existing D7 modules that might conflict with this namespace?

It turns out, there is https://www.drupal.org/project/snippet (name: "Snippets"), last release Dec 2016. Only "71 sites report using this module". Could however be a problem if we wanted to provide a "Snippet" content type as contributed module, but I don't see a problem if we put it in core.

Edit: More projects / mentions of the term:

• https://www.drupal.org/project/content_snippets
• https://www.drupal.org/project/snippet_manager
• https://www.drupal.org/documentation/customization/snippets

[jenlampton]

https://www.drupal.org/project/content_snippets sounds like exactly our use-case.

The term snippets has a different meaning for Drupal (as per https://www.drupal.org/documentation/customization/snippets) but those stopped being popular around the time of Drupal 6. Before that the forum was full of snippits for use with PHP-filter or to throw into template.php. I'm not sure this should stop us from using the word, but it will be confusing for people who've been around Drupal for a long, long time.

[klonos]

https://www.drupal.org/project/content_snippets sounds like exactly our use-case.

Same with https://www.drupal.org/project/snippet

The snippet module allows you to provide user (usually a site-admin) editable "text-areas" in panel pages without given users general panels admin access. Each snippet area is exportable, so it can be bundled in a feature along with panels. The text contained within the snippet (which the user can edit) is not exported.

^^ Sounds to me like the node blocks use case.

https://www.drupal.org/project/content_snippets

Content Snippets is a simple module that provides an administrative and content editor interface for editing small bits of text that can then be used by developers when they would be otherwise tempted to hard-code content into custom code, themes, etc. Then these bits of text can be controlled by Content Editors without developer intervention.

So both of these projects seem similar or at least trying to address similar issues; one is for D7, the other for D8.

I'm not sure this should stop us from using the word, but it will be confusing for people who've been around Drupal for a long, long time.

Same feeling here: not hard-opposed to it, but I'd prefer it if we found a name that was self-explanatory.

[jlfranklin]

Snippet, to me, sounds like it should be part of Paragraphs.

[olafgrabienski]

I'd prefer it if we found a name that was self-explanatory

No problem: "Hidden-path content for blocks and other use-cases" 🙂

But seriously, here are name suggestions mentioned so far. Posting for reference (in alphabetical order):

• Content block
• Content segment
• Content snippet
• Dropblock
• Embeddable
• Embedded
• Embedded content
• Fieldable block
• Flexible content
• Flexible page
• Flexi content
• Flexipage
• Hidden content
• Hidden page
• Hidden path
• Hidden path pane
• Info block
• Info box
• Information
• Page part
• Pathless content
• Pathless page
• Promo box
• Snippet

[jenlampton]

Ooh, I like Promo Box!

On Tue, Feb 2, 2021, 12:33 AM Olaf Grabienski notifications@github.com wrote:

I'd prefer it if we found a name that was self-explanatory

No problem: "Hidden-path content for blocks and other use-cases" 🙂

But seriously, here are name suggestions mentioned so far. Posting for reference (in alphabetical order):

• Content block
• Content snippet
• Content segment
• Dropblock
• Embeddable
• Embedded
• Embedded content
• Fieldable block
• Flexible content
• Flexible page
• Flexi content
• Flexipage
• Hidden content
• Hidden page
• Hidden path
• Hidden path pane
• Info block
• Info box
• Information
• Page part
• Pathless content
• Pathless page
• Promo box
• Snippet

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/backdrop/backdrop-issues/issues/4903#issuecomment-771463526, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADBER777EQG3QFRRGSSKRDS462F7ANCNFSM4WQ4DY5Q .

[klonos]

Ooh, I like Promo Box!

That would be a good use case (IOW the name of any content type we may add). It's not generic enough to be the name of these "hidden-path" thingies.

[jenlampton]

IOW the name of any content type we may add

What does IOW stand for?

It's not generic enough to be the name of these "hidden-path" thingies.

The reason I really liked this name is because a "promo box" wouldn't ever have a path, so we don't even need to state that it is special. The word "Box" would make it clear, even from the content listing, that it should be placed as a block. We could also add fields (image!) to make it immediately apparent that it's fieldable. And, a "promo box" is generic enough to solve nearly every non-specific use-case. I could see myself using this on almost every site! (Unlike a faq, which would only appear on a few, or a slide, which would require additional modules).

Solves all 3 concerns!

[klonos]

Sorry 😅 ...that's: In Other Words 😅

[stpaultim]

Well, I went ahead and created PR with a new Promo Box content type. We can continue to discuss the name if we like, but at least we have one clean version to look at.

I included replacing the promoted content view on the front page with node in this PR (Issue = https://github.com/backdrop/backdrop-issues/issues/4849). Because they are two small PR's that look good together. We can break them apart again if we need to.

Is this something we might get into 1.20?

Atten: @olafgrabienski

Looking for input on what fields to add to Promo Box. It's just title and body field right now.

[olafgrabienski]

Thanks for the PR, @stpaultim! I'll have a look at it soon.

[olafgrabienski]

Had a look at the PR's sandbox in the meantime. I think, the PR works great but could need some finishing. I'll start with some details (and hope to add more comprehensive thoughts in another comment):

Name: The name of the content type in the PR is "Promo Box". Looks good, but I was wondering if a single word is more handy: "Promobox". I guess, it isn't possible in English ... but if it is, I'd suggest to use the single word.

Machine name: In any case I'd like the machine name promo_box to be changed to promobox. The underscore is quite annoying, in my opinion, and it could lead some people to use ambiguous field machine names like field_promo_box_image.

Content type decription:

Add a piece of content to be used for blocks and views. A Promo Block Box does not have a public path (hide hidden path display).

Should we also add an example use-case? Not sure if it gets too long:

Example use-case: Place Promo Box content as "Existing content" block in a Layout.

Title of provided content item: "Home page" as title could make people think, this item is the Home page. What about "Home page content" instead?

Content item heading:

• H3 "Welcome to your new site.": A H3 heading is problematic here, we should have a H2 on the Home page. So, let's remove the heading from the body text and add the text as Block title (see below).
• Btw, the term "Welcome" is already part of the Hero block. Alternatives to a 2nd "Welcome" are (well) welcome!

Content item text:

• You can edit this message by looking for the "Home page content" item listed under the Content menu.

(Maybe also display an edit link?)

You can add or remove blocks on this page layout at admin/structure/layouts.

Display the path in italics or this way: admin/structure/layouts? Or even display it as link?

Block title: Let's choose Custom instead of None, and put there the heading text of the Content item (see above).

Block Admin label:

Home Page Content content

(cf. "Promoted content" block)

Fields: Add an Image field? See https://github.com/backdrop/backdrop-issues/issues/4903#issuecomment-771932367, "to make it immediately apparent that it's fieldable". I agree! On the other hand, images can easily be added via CKEditor. However, if we add an image field, we need good looking defaults (example image, image style, positioning). We could try how it works!

Permissions: Should the Editor role get the "View hidden paths" permission? Without it, the new content type isn't editable for Editors. (Another useful permission for Editors with the new content type: "Use contextual links".)

Phew, that's it for the moment! Thoughts?

[olafgrabienski]

Regarding the example Promo Box item, should we just align the text with the other example content items?

• Your first post! This is your first post! You may edit or delete it.
• About This is a page with static content. You may edit or delete it.
• Hello, world (tbd) This is a Promo Box content item. You may edit it, remove it from the Home page layout, or delete it.

[stpaultim]

@olafgrabienski - I took most of your suggestions verbatim, except the the title of the sample Promobox, which you didn't really provide one.

I also did the following:

1) I restored the "Promoted Content" block underneath our new Promobox, since folks are asking for this here: https://github.com/backdrop/backdrop-issues/issues/4849 2) I added a second sample post, so that we can actually see that the front page view is a view.

I understand that we don't have agreement yet on either "Promo Box" or "Promobox", but I don't see any harm in trying them out for size.

My main concern about having the Promobox and view of Promoted Content on front page is that the page is starting to look cluttered. I think that with some css changes, we could make this front page look better, but I am not sure if we can improving the CSS for the front page without breaking existing sites (https://github.com/backdrop/backdrop-issues/issues/4167).

[klonos]

The name of the content type in the PR is "Promo Box". Looks good, but I was wondering if a single word is more handy: "Promobox". I guess, it isn't possible in English

It's not a matter of being possible or not in English, rather than a cultural preference I believe. AFAIK, nouns in German are concatenated, to form a single "compound" word, whereas in most other languages the same thing happens either by using a dash between the two words, or just leaving a space. That's why you are finding "Promo Box" odd @olafgrabienski 🙂 ...the label is translatable (via st()), so that shouldn't be an issue, and the German translation can be "Promobox", but I get it re the machine name and all. I'm not fussed either way TBH.

I like where this is going. It will be great to have a pageless node as an example OOTB. Thanks for working on this @stpaultim 🙏🏼

[klonos]

I restored the "Promoted Content" block underneath our new Promobox, since folks are asking for this ...

I agree with that 👍🏼 ...but we now have 2 ways of listing/adding content on the home page. I really doubt that is obvious to people, unless they are Drupal/Backdrop users that understand how things work internally. I would like us to improve this, so that it makes it obvious that pageless nodes are distinctly different to the list of nodes provided by the "Promoted Content" view/block, and so that it is immediately visually obvious that these "special" pageless nodes are used for such specific use cases.

I think that we'd achieve that better if instead of the "Promo box" we had something like the following:

• a "Slide" content type (with fields such as title/image/text/link), which is rendered as a slideshow on the home page
• a "FAQ" content type, which is rendered as an accordion on the home page (what @jen suggested earlier in this thread)

Each slide or FAQ content item, should have a text that explains things in "steps". In the case of slides for example, the could have the following series of text:

• 1st slide: This slide is a "pageless" or "hidden-path" content item. (click next to find out more)
• 2nd slide: You use such pageless content items when you want to block site visitors from directly accessing the individual content items, but still want to show the content as part of a "collection" (click next)
• 3rd slide: In the case of this slideshow, each slide is a pageless content item. Content editors can access existing slides to edit them, but site visitor can only see the slideshow - not each individual slide on its own page.

(rough wording - I hope you get the idea)

Although I think that a slideshow/slides example would provide more value OOTB, I also understand that it would require adding a specific JS slideshow solution in core, which I'm sure that many people would object to (and for perfectly valid reasons too). A FAQs example on the other hand would be easier to implement with fieldsets, that we already have in core (although again, I'd rather we used an accordion).

[docwilmot]

I can imagine that this is going to cause quite a bit of extra work with testing and maintenance. Lots of tests now do things with content types; this is going to increase by 50% if we add a new one.

Are we sure the ROI on this is acceptable?

Excuse the late stage negativity.

[klonos]

@docwilmot what sorts of tests would you expect to be required to be added with this feature? Can you provide a rough list? I'm asking because off of the top of my head, I'd expect that most things we're using in this feature are pre-existing in Backdrop. I'd expect that we already have tests in place for them.