Add a system of page-less nodes

[saltednut]

Since we will soon have relegated blocks to being an admin-only text-only layout element that's saved into config, we are going to need a content-based alternative that is a fieldable entity!

Big picture, what we want are page-less nodes.

We have several examples of entities that come close in Drupal contrib that we can compare/contrast and decide if we want to start from any of them, or would prefer to create our own.

---

Use Cases

1) Fieldable and typable block content: I often need to create a type of content that will only be viewed as a Block. Example: an Ad block that consists of an image field, a link field, an (optional) text field, and can be placed into a layout. Solutions: Bean or entity construction kit

2) Content without a "page" I often need to create a type of content that will only be seen in a view. Example: a "Slider item" that consists of an image field, a text field, an optional description field and an optional link field. Solutions: entity construction kit or Rabbit Hole module

3) Content as part of other content I often need to create a type of content that will only be seen as part of another piece of content. Example: Example: media-rich content. Sometimes content editors want to insert some media items between text paragraphs: sliders, photo galleries, maps, video, etc. Solution: paragraphs or entity construction kit + inline entity form or field collection or multifield

~~4) Grouping fields together (not a great fit for pageless nodes) I often need to group my fields together, so that when I add another "field" I'm actually adding another "Set of X fields". Example: A "contact person" may consist of a name field, email field, and phone field. Solutions: field collection or multifield~~

---

PR by @serundeputy: https://github.com/backdrop/backdrop/pull/2049 New PR, rerolled and tweaked by @herbdool: https://github.com/backdrop/backdrop/pull/2286

[quicksketch]

Thanks for opening this issue @brantwynn! I don't think there's an issue yet for this, so this will probably become the official request.

I think for starters we might want to replace hookblock*() hooks with a more typical hook_block_info() structure that specifies either callbacks (like hook_image_effect_info() or hook_filter_info()) or move to pointing at classes (like hook_views_info()). An info hook that points at a class effectively is the same thing as a D8 "plugin", since a plugin is basically nothing but a class and a discovery mechanism. If we forgo the automatic discovery and just use info hooks like traditional Drupal, we get the consolidated functionality of plugins without introducing a new concept into the system. Anyway, all that might be a precursor to this request. Since all custom blocks that are created would essentially be exposed through this hook, just like block module's implementation of its own hook today in block_block_info().

[jenlampton]

Wow, it's been a while since we looked at this issue. I, for one, would love blocks to be entities and for them to be fieldable in core. However, I don't think this can a happen in 1.x anymore.

[MrHaroldA]

What if ...

1. We add another optional view mode to nodes: Block
2. We add another checkbox to the publishig options for content types that have the Block view mode active: [ ] Available as block
3. Nodes with the expose checkbox show up as block, in the configured view mode.

Is this "oversimpling" the issue?

[MrHaroldA]

Here's a proof-of-concept that exposes a node as a block, if checked in the publishing options.

https://github.com/backdrop/backdrop/compare/1.x...MrHaroldA:block_nodes?expand=1

It lacks a lot of things; but it's basically a "fieldable block system" of some kind ... ;)

[MrHaroldA]

It would be cool if someone could check the architectural changes of my patch, and tell me if it's viable or not.

I expected this to be difficult to achieve, but my patch is really straight-forward ...

[mikemccaffrey]

@jenlampton: I, for one, would love blocks to be entities and for them to be fieldable in core.

I've been thinking a lot about this, and I have not been able to come up with many cases where it would make sense to add fields to blocks. Pretty much the only one would be a field to hold images that are used in the block.

Do folks have other examples where'd they add fields to blocks? And would these fields just be added to all the blocks on the system, or do we have to implement the concept of block types?

[mikemccaffrey]

A reply from @jenlampton with examples of fieldable blocks that people might create:

ex: type: slide - a home pageslide that needs fields (video, image, text, link) and is only accessed via a view ex: type: ad - an Ad needs fields (image, link) but is placed individually in a layout ex: type: administrator - this item appears only within various lists of administrators. This content will not be associated with a user account, but needs fields (name, address, phone number) as well as categorization.

This will obviously not only require us to convert to the existing custom blocks to entities, but also provide support for different types of blocks.

[MrHaroldA]

What about my "node as block" idea?

[mikemccaffrey]

I see where @jenlampton is coming from with the fieldable block types above, as I've created my share of slide and ad content types that didn't necessarily need to have their own public pages and all the bells and whistles that come with nodes, such as author and comments.

However, I very rarely needed to place these elements directly into the page as individual blocks, and instead usually have a view that displays either a list of these items or a single random item. In fact, it would be kinda overwhelming if a new block was created for every slide or ad that is added over the life of the site.

Therefore, while I'm on board with the idea of creating a new entity for creating fieldable types of content that don't need their own page, do we really want to call them blocks?

[mikemccaffrey]

@MrHaroldA: What about my "node as block" idea?

I like it this idea. Perhaps, just like we are creating a block that allows you to place individual fields into a layout in #1100, we could create another block type that allows you to place a whole node into the region, which has nid and display mode as settings. That might be simpler than defining a unique block for each node that you want to be able to use in a layout.

[klonos]

What about my "node as block" idea?

@MrHaroldA: do you have an issue filed for this already? Because the closest we have to that AFAIK is #1076.

[MrHaroldA]

Not really, but I did make a proof of concept right here: https://github.com/backdrop/backdrop/compare/1.x...MrHaroldA:block_nodes?expand=1

[mikemccaffrey]

Hey folks, I've been thinking about the idea of fieldable blocks, and it seems like the big requirements we have been asking for are:

• they are an entity
• they don't have all the extras that are baked into nodes
• you can create different types
• you can add arbitrary fields
• you can list them using views
• you can add them individually to layouts

However, based on that, it seems like we already have a drupal entity that does all of those things (except for the backdrop-specific layout integration), and that is field collections.

For those who are asking for fieldable blocks (like @jenlampton), are there any features that you are looking for that are not supported by field collections? What if we were to take the existing implementation of field collections, ported it to backdrop, and perhaps changed the name to describe how you'd like to use them?

[MrHaroldA]

Field collections have way more features than we need, is painfully slow on nested collections, and has (or used to have?) big problems with revisions. I also dislike the default edit and delete links on the display within a node, but those can be disabled.

For example: each field collection type has it's own page callbacks, including view, edit and delete.

[jenlampton]

I'm also in agreement about field collection being bloated and (more importantly) really slow. I'd love to see something architecturally cleaner than that, something more like a page-less node.

[serundeputy]

On the last project I worked on we made extensive use of the paragraphs module.

Which is basically a fieldable entity that is not a node. You can attach a paragraph bundle to a node or use it in a view, but it is not a block.

Just throwing that out there. I don't exactly understand all the points of view here (that doesn't make them bad), but paragraphs was a nice solution for me for some of the things discussed here.

2¢geoff.

[mikemccaffrey]

@serundeputy: On the last project I worked on we made extensive use of the paragraphs module.

Good call. That project seems very pertinent to what we are looking for, and we should examine the architecture of that module closely, even if we don't do a direct port or end up building things in the exact same way.

[itsdarrylnorris]

Another possible solution for this problem will be to port Rabbit Hole module. Here is the description of Rabbit Hole.

Rabbit Hole is a module that adds the ability to control what should happen when an entity is being viewed at its own page.

Perhaps you have a content type that never should be displayed on its own page, like an image content type that's displayed in a carousel. Rabbit Hole can prevent this node from being accessible on its own page, through node/xxx.

Instead of trying to port a complex module like ECK, we can try to port Rabbit Hole which prevents from pages from been seen at the node level.

[MrHaroldA]

@darol100 It seems like a waste to me to throw away things php has built in the same process. Disabling detail pages on a content type should prevent them from being built, not thrown away afterwards.

[mikemccaffrey]

We mentioned this issue again in the call last week, and I brought up this question: how are these new page-less entities different than nodes other than the lack of a URL? What would the base table look like? Would it have the same attributes as nodes (author, created, updated, etc.)?

I feel like knowing that would help us understand if these page-less nodes are really a different species of creature.

[klonos]

We mentioned this issue again in the call last week, and I brought up this question: how are these new page-less entities different than nodes other than the lack of a URL?

When you mentioned this, I realized that I had the same question in my head before, but couldn't exactly find the right words to phrase it. As a non-coder, I did not have the db table concerns etc, but honestly, the page-less node thing in my head could be accomplished if we somehow allowed and left the path empty (or with a special value like null or <none>). The technical implementation is of course beyond me at this point.

[jenlampton]

Pushing to 1.7 since there has been no activity on this issue and code-freeze is in just over 3 weeks.

[Al-Rozhkov]

There is one module from D7 which wasn’t mentioned in this issue. It is Fieldable Panels Panes. It has one important feature, it is possible to add a pane directly from Panels UI.

how are these new page-less entities different than nodes other than the lack of a URL?

So, I think it is the main difference for page-less entities from regular nodes in UX sense. Because it is very uncomfortable to create node then insert it in proper layout. Much better UX for me is to create fieldable blocks directly in Layout UI (like custom blocks) with ability to make them reusable.

Field collection or Paragraphs is another way to build composite content. Paragraphs items tied to host entity, at least it is the only way to create them. People use Paragraphs to build complex pages and even long landing pages. With power of fields and field formatters it is easy to give end-user ability to create map or gallery inside single node. Modules like Classy paragraphs exists to style Paragraphs items. But Backdrop already has Layouts and styles for blocks. So as site builder I dream only about fieldable block types in Backdrop.

By the way Paragraphs extremely slow too. And editorial workflow becomes very painful when you need to edit one small thing inside big list of items.

[jenlampton]

This is too big an issue go get done in one day with no PR yet, unless @serundeputy has a trick up his sleeve, I'm bumping to 1.8.

[Al-Rozhkov]

I wish I can help with that, but I don't understand what direction was chosen by the community.

• Introduce new entity type.
• Add setting to node types.
• Other :smile:

[jenlampton]

I don't understand what direction was chosen by the community.

This is the crux of the problem. We haven't decided. I think in general we are leaning towards less abstraction, and potentially all "content" being node-like-things, but @mikemccaffrey brought up some good questions that we need to answer before we can make the call.

I created a spreadsheet of the entities we currently have in core, their associated metadata, and the features those map to. https://docs.google.com/spreadsheets/d/1rY1XM5_mxyCnISaY7kny1aRPGJ3q5AXyv-SGNTtVLD4/edit#gid=0

In some cases, we currently have entities that are missing features we probably need (like translatable and revisionable terms, for example). So we should think about this question at a higher level than just comparing features on nodes and blocks, but the purpose of this spreadsheet is to decide if all the things we currently do for nodes even apply to blocks or not.

[mikemccaffrey]

I think that this discussion has been a bit muddled since we started it by declaring a potential solution and diving into the technical details without fully describing the problem that we are actually trying to solve. And based on people's comments, it seems like there might be several different use cases that people are looking to implement with "pageless nodes".

Perhaps folks could submit some other tickets that better document the user needs that brought them to this ticket? What exactly are you trying to accomplish? How are you currently doing it? Then we can discuss the different ways that can be accomplished, with these pageless nodes perhaps being only of the options.

Make sense?

[jenlampton]

I added 4 use cases for pageless nodes to the first issue in this thread based on the modules people recommended as solutions to this problem. (I don't actually think #4 is a good use-case for pageless nodes, but I added it there anyway for reference).

I haven't used Paragraphs yet, so I figured I should leave a real world example for that one to someone else.

Are there others?

[Dinornis]

I used num.2 example on D6 site. Needed to use content without a "page" to create a type of content only accessible in a view.

[Al-Rozhkov]

The most common use case for my sites is number 3. Example: media-rich content. Sometimes content editors want to insert some media items between text paragraphs: sliders, photo galleries, maps, video, etc.

Picture taken from D7 paragraphs module.

But at the same time I need Fieldable and typable blocks. Actually, I have a site with Paragraphs and Fiedable Panels Panes modules installed together with very similar bundles and fields. Paragraphs for media-rich content inside nodes and FPP for blocks. I feel this task can be done more elegantly without duplication.

So my vote for number 1 and 3 :-)

[mikemccaffrey]

I added 4 use cases for pageless nodes to the first issue in this thread based on the modules people recommended as solutions to this problem.

So, basically, it seems like we have four different problems that have been lumped into a single ticket. Based on all the back and forth, it doesn't seem like we can come up with a single solution to meet the needs of all of the different use cases, so perhaps we should create four different issues to discuss how to independently support each of them in core?

[jenlampton]

So, basically, it seems like we have four different problems that have been lumped into a single ticket.

Yes, that's because they all have something in common and it could be that there is a single solution for all of them.

it doesn't seem like we can come up with a single solution to meet the needs of all of the different use cases

I'm not sure how you reached this conclusion already. I would hate to see four separate implementations of pageless nodes in core when it could be a single solution (a new entity type?) perhaps with 4 different user interfaces (create from layouts UI, create from content content screen, create as fields on nodes, and group together as field groups?).

perhaps we should create four different issues to discuss how to independently support each of them in core?

I don't think this is a good idea... at least not until we know what the solution(s) will be. It will separate out all the conversations and progress will be slower going. Let's create tickets only once we know we need tickets -- once we have actionable items, or have things we know can't be covered here.

[jenlampton]

For example, I would be happy to remove number 4, the field_collection / multifield use case since it is quite a bit different than all the others, and I think it's fine to leave that solution to contrib. That use-case doesn't need an issue for including it in core.

[jenlampton]

I also feel that Paragraphs is a great (contrib) solution for number 3, and I don't think we need an issue for including it in core either.

Item #2 could be solved easily by a rabbit-hole type implementation. But if we went that route for Item #1, we would also need an interface for creating this new type of content from the Layout UI, like we do with blocks.

By looking at only 2 use-cases, the rabbit-hole approach looks more straightforward. However, if we look at all 4, maybe a new entity type appears more attractive? (Paragraphs, Field collection, and Multifield all create a new entity type). Or, maybe we decide that new entity types should be left to contrib, and in core we do only what's simplest?

I'm in favor doing what's simplest. :)

How about adding a setting to all node types that would allow that type of content to be created directly from the Layouts UI (or not). If we added a parallel (rabbit_hole) setting that allowed that type content to be accessed via a specific URL (or not) It could be possible to get both these changes in during the 1.x cycle. :)

[olafgrabienski]

How about adding a setting to all node types that would allow that type of content to be created directly from the Layouts UI (or not). If we added a parallel (rabbit_hole) setting that allowed that type content to be accessed via a specific URL (or not) It could be possible to get both these changes in during the 1.x cycle.

Sounds good to me!

I'd love to use Paragraphs as a contrib module as well. A port started a while ago, haven't tested it so far. Here the project links:

• https://github.com/backdrop-ops/contrib/issues/212
• https://github.com/jacksinn/backdrop-paragraphs

Apart from that, I guess even the rabbit-hole approach would allow a simple implementation of use-case number 3, if used in combination with Reference(s).

[LeeteqXV]

FYI - "Paragraphs module evaluation (simplytest.me export kit)" [#22] https://github.com/backdrop-ops/forum.backdropcms.org/issues/22

[jenlampton]

Hm, we still don't have any code for review here and we're 2 weeks from feature freeze. I think this is too big a feature to get into the next release in the time we have, so removing from 1.8 milestone. We can add a milestone back as soon as we have code to review.

[jlfranklin]

We have a handful of great modules, all of which solve the problem in very different ways. Can we start by porting them to Backdrop and let site builders vote through module popularity?

[jenlampton]

Yes, that's a good way to help us decide :)

[olafgrabienski]

We have a handful of great modules, all of which solve the problem in very different ways. Can we start by porting them to Backdrop and let site builders vote through module popularity?

As far as I know, respective modules were not ported so far, or are not ready. After re-reading the issue I have the impression that the Rabbit Hole approach mentioned lately in https://github.com/backdrop/backdrop-issues/issues/100#issuecomment-299574518 would solve most use cases. @laryn ported the module a while ago but it's not ready to use. Is anyone up to help there? https://github.com/laryn/rabbit_hole (Or should we even still port / adapt Rabbit Hole directly in core?)

[jenlampton]

I'd like to help with the port of Rabbit hole, and I think it would be good to get it working for contrib before we put it into core. We'll likely need to adapt it for core, but having a working contrib version is a useful first step!

[herbdool]

@olafgrabienski @jenlampton @laryn the basics are working and needs testing. Need to figure out why it's not for taxonomy yet.

[olafgrabienski]

@herbdool, great news! Will test as soon as possible, hopefully tomorrow.

[olafgrabienski]

@herbdool Have tested Rabbit hole now, looks great! Found only minor issues, see my comments on the existing page title issue and two new issues: https://github.com/backdrop-contrib/rabbit_hole/issues

[serundeputy]

I took the ideas from rabbit hole and implemented a simplified node only option to Hide nodes. @olafgrabienski this will allow us to make a content type for translatable blocks, so we sort have a fieldable content block; and since it is a node we can use the node translation system to translate these blocks as well.

QC Env: Website: http://2049.backdrop.backdrop.qa.backdropcms.org Username: admin Password: 7TZqGNWd

[olafgrabienski]

@serundeputy Nice! Have already built a respective content type in the environment (and found myself on a not found page directly after creating the node). Will have a closer look in the next days.

[serundeputy]

Thanks @olafgrabienski !

I've pushed up a fix so that new content types can pick up a default of the usual behaviour of an accessible page.

[olafgrabienski]

To give an update: the new simplified option to 'hide' nodes (PR by @serundeputy) has been intensively discussed on the page of the PR itself. The user interface and the functionality of these Pageless settings (how they're called now) have been improved subsequently, so that we now have a good and simple approach for pageless nodes provided by Backdrop core. As far as I can tell, the PR works good but I guess it could need another review.

Supposing a positive review, there might still come up the question why we don't just use the recently ported Rabbit Hole. In my opinion, Rabbit Hole is fine, especially if you need more functionality (handling of not just nodes but also taxonomy terms and user accounts, or the option to overwrite content-type-wide settings individually).

In contrast, the core Pageless settings are only for nodes, which keeps it simple and fits exactly to the title of this issue ("Add a system of page-less nodes"). Another (potential) advantage of the core implementation would be better integration, for instance by adjusting related node options like Menu settings automatically when someone chooses to make a content type pageless. Finally, the Pageless option in core would facilitate to use a popular block translation approach, thus making Backdrop more multilingual out of the box.

That said, I'm not sure if the new Pageless settings should be enabled by default. It's another tab in the content type settings which might not be used very often, just guessing. What do you think, does it make more sense to provide the Pageless settings as a core module which is not enabled by default?

[herbdool]

@olafgrabienski while I agree it probably won't be a popular approach, we can't know for sure since so far this functionality was only offered by a contrib module in D7 (Rabbit Hole).

One reason to keep it as part of the node module is because it avoids the technical issue we encountered with RH where the page not found wasn't working fully.

[herbdool]

I was curious to test how people were thinking of using it for translated blocks. When I enable a second language and then translate a node and then insert the node into a layout directly, it doesn't show the translated node when switching languages.

I've used views myself to accomplish this but can't see how to do it with a single piece of content inserted into a layout.