klonos's picture

In the blocks meta issue in GitHub we have Add a system of page-less nodes #100 listed as what seems to have initially started as a task/request for fieldable blocks in core, but has eventually evolved into the "rabbit hole" feature for content types (which is awesome by the way 👍). ...I'm trying to wrap my head around use cases for fieldable blocks in D8/D9, and if the respective feature we have implemented in Backdrop core is enough to cover those use cases.

I'm already aware that we have the "Existing content" block type, and also that we are able to place individual fields as blocks (provided that the context specified for the layout is set to node/%) ...what I'm trying to figure out though is things we are missing w/o fieldable blocks in Backdrop. Do others have any use cases to present? Do we have equivalent solutions/workarounds for those in Backdrop?

Accepted answer

What can people do in Drupal 8/9 with fieldable blocks which is not possible in Backdrop?

I'm not missing anything in Backdrop. :-)

It's actually easier to use a content type, hide the path for visitors and include the node(s) in a layout. Easier for users and easier for admins. And if only some parts of a node are needed, a custom layout context will help. Or maybe it's even easier to do it with view modes.

Comments

indigoxela's picture

What can people do in Drupal 8/9 with fieldable blocks which is not possible in Backdrop?

I'm not missing anything in Backdrop. :-)

It's actually easier to use a content type, hide the path for visitors and include the node(s) in a layout. Easier for users and easier for admins. And if only some parts of a node are needed, a custom layout context will help. Or maybe it's even easier to do it with view modes.

mazze's picture

I really agree with indigoxela's way, using nodes. In each and every project I have a content type called "promotion box" which can be loaded as "existing content" into a layout region.

Plus, explaining the difference between blocks and nodes to a non-tech customer was pretty hard back in my D7 days.

However, D9 people might miss the UI for choosing from existing blocks (and nothing but blocks), it's a nice "library" approach. Maybe the UI can be improved in Backdrop, but I do not miss any real feature.

 

klonos's picture

Thanks for the input @indigoxela and @mazze 👍 ...what I've done is to google "drupal fieldable blocks", and then started going through any tutorials and blog posts that came up as results. I tried to find use cases and things people use D8/9 fieldable blocks (custom block types) for ...you are right, that there is not much that is not possible in Backdrop with re to that. ...in fact, things are simpler/easier in Backdrop 😅

Olafski's picture

On many Backdrop sites, I build a content type called "Info box", configured with hidden path  display and to be placed as blocks of existing content in a Layout. It works really well, even for translated content.

The Info box items are placed by me (the site architect) and can be edited by people with the typical "Editor" role permissions, be it on the Manage content page or using contextual links. As far as I know, there is however an important limitation regarding new Info boxes: While the content items can be added by editors, they can't be placed unless you provide editors with the Administer Layouts permission.

Olafski's picture

While the content items can be added by editors, they can't be placed unless you provide editors with the Administer Layouts permission.

Rough idea to improve the situation: Expose block placement to the frontend pages, providing a contextual "Place block" link for people with respective permissions.

Hm, thinking about it, this combination could be a well integrated contrib module (or core improvement):

  • a third content type for blocks of existing content with e.g. body and image field and hidden path display, good name tba
  • frontend block placement for blocks of this content type plus respective permissions