Idea summary

What is the problem to solve?

As a content editor, I want to be able to create pieces of content which can be embedded on different pages.
Example: I create a node type called 'Hero', I add content to this hero, which goes through its own review process to be published. These nodes then are placed on another page via panels, panelizer, or the new layout hotness.

Currently, there is no way to do this without using the entity_blocks module or creating your own custom block plugin.

Who is this for?

Content authors, site managers, (advanced) site builders, frontend developers, site owners.

Result: what will be the outcome?

By placing this in core, it'll give content editors built in functionality to embed reusable blocks or 3rd party content.

How can we know the desired result is achieved?

By seeing people using the layouts system in core and embedded these content blocks on landing pages.

Original Details

Behold, this contrib module: https://www.drupal.org/project/entity_block

This is a module that provides a single block plugin which, via a deriver, allows one to display any viewable entity type in a block. You choose the entity to display using an autocompleting text field, and can select the view mode to use on a per-block basis. I think this functionality should be merged into the core Block module.

I discussed briefly with @tim.plunkett on IRC, and although there is no technical reason not to do this, he pointed out that you can cover most of this use case with the Block Content module. I think this approach presents two major advantages over Block Content, though:

1. You don't have to create a new block type, and indeed a new entity reference field, for every entity type you'd like to display in blocks. You can just instantiate the appropriate derivative, and off you go. It requires less configuration infrastructure (which might mean better performance).

2. You can choose which view mode to use for each block. Using Block Content, you'd be choosing the view mode for all blocks of that type, and that's the only view mode that could be used. This approach would allow you to define two separate blocks which show the same entity in two different view modes, respectively. That'd be quite difficult with Block Content and involve a lot of extra infrastructure and configuration.

I think it is quite a common use case to want to just display entities in blocks which can then be positioned freely around the page. I'd like to know if other people think this would be valuable for core to provide, and if there is enough buy-in, I am happy to produce a patch.

Comments

phenaproxima created an issue. See original summary.

phenaproxima’s picture

Issue summary: View changes
rlnorthcutt’s picture

+1 on this. I've created custom block types for embedding content (especially in IPE) and had to do this work over and over... I've also struggled with the work to choose the display mode - before finding entity_block. Now that everything is an entity, it makes sense to have an easy way to embed them where we need.

This also opens up a whole avenue of easy solutions, especially for non-devs. They can create the entity they need (content, media, taxonomy, etc.), and then put it in place. On top of that, it actively encourages use of view modes, which is something that I think more people need to consider. I'm curious to see how many people might find this a "must have" module, like I do.

samuel.mortenson’s picture

My team has written code for this basic use case multiple times in Drupal 7 and 8, and are now using entity_block. It's a fairly simple module that's super useful for site builders.

jibran’s picture

Why only keep it for entity view displays? What about entity form displays? https://www.drupal.org/project/formblock

phenaproxima’s picture

I suppose there's no reason not to include form displays as well; I just figure that displaying content is the more common use case. I have an easier time imagining a relatively non-techy (author) Drupal user wanting to display finished content in some arbitrary region, rather than a form -- contact forms being the lone exception.

yoroy’s picture

Issue summary: View changes
Status: Active » Needs work

Adding the "idea template" to the issue summary to help clarify the what, who, why and how. Looks like people recognize the problem but I can't really tell yet what that problem is exactly :)

Your short answers to the 4 questions will help us compare and weigh ideas for their relative impact. Thank you!

inteja’s picture

Rather than edit the summary, I thought I'd add my "why" for this here first:

In my experience, block administration should be restricted to site builder and developer roles only, because block positioning and order can negatively impact layout and styling (especially in header area). But restricting access to blocks is problematic because some blocks contain "content" or what content authors regard as content that they should be able to easily edit without site builder or developer help. So this feature (as embodied by entity_block) allows selected block content to be easily edited without changing block regions or order, and allows editing via the familiar content editing UI i.e. users don't need to learn the block admin UI as well.

Overall it's a much more streamlined user experience and eliminates any problems caused by overzealous or ill-informed block editing.

japerry’s picture

Issue summary: View changes
shelane’s picture

It looks like this has lost steam, but for issues in the summary and #9, I currently use the entity_block module and would love to see this in core. Over 9000 users of that module currently and at least one more module just like it with several hundred users, the use case is there.