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

[olafgrabienski]

@herbdool Did another quick sandbox review. Permission works now, nice! (After changing the permission, the setting applies however not immediately but only after clearing the "Page and else" cache.)

Regarding the terminology, I like 'path' instead of 'page' to avoid confusion with the Page content type. There is of course room for improvement, but I'd suggest to handle it in follow-up issues.

[alexfinnarn]

<?php

/**
 * @file
 * Definition of views_handler_filter_node_hidden_path.
 */

/**
 * Filter by content type's hidden path setting.
 *
 * @ingroup views_filter_handlers
 */
class views_handler_filter_node_hidden_path extends views_handler_filter {
  function admin_summary() { }
  function operator_form(&$form, &$form_state) { }
  function can_expose() { return FALSE; }

  function query() {
    $table = $this->ensure_my_table();
    $node_types = config_get_names_with_prefix('node.type.');

    $enabled_types = array_filter($node_types, function($val) {
      return config_get($val, 'settings.hidden_path');
    });

    $enabled_types_names = array_map(function($val) {
      return str_replace('node.type.', '', $val);
    }, $enabled_types);

    $this->query->add_where_expression($this->options['group'], "$table.type IN (:types)", array(':types' => $enabled_types_names));
  }
}

By adding that views filter handler, an entry into node_views_data() and the autoload of the handler file, I was able to filter based on the hidden path setting.

The code could be cleaned up a little, and I took the example from views_handler_filter_node_status.inc.

[quicksketch]

I posted a short review to https://github.com/backdrop/backdrop/pull/2286#pullrequestreview-151562341. Code-wise, this looks good.

I'm not sure I like hidden path any more than pageless but it is more technically accurate. I'd prefer that for internal storage even if we decide to change the user-facing label and description for the option later.

Can we lop the word "display" off the permission name and change it from "view hidden path display" to "view hidden paths" (similar to "view revisions")? The word "display" gets conflated with display modes in my mind.

[herbdool]

@quicksketch I've updated the permission wording.

@alexfinnarn thank you! I've gotten pretty close based on the class you provided. But I might be doing something wrong in node_views_data. I can get the filters and field to show up but the options don't show in the filter.

Here's my working copy in node_views_data():

// hidden path
  $data['node']['hidden_path'] = array(
    'title' => t('Hidden path'),
    'help' => t('Whether or not the content has a hidden path.'),
    'filter' => array(
      'handler' => 'views_handler_filter_node_hidden_path',
    ),
    'sort' => array(
      'handler' => 'views_handler_sort',
    ),
  );

Not sure if I can get this figured in time for code freeze. Hopefully but any help you can lend is much appreciated.

[herbdool]

@alexfinnarn I updated my previous comment. It works for me but the options don't show up in the filter (no yes/no option). Not clear yet on how to get it to appear.

[herbdool]

I'm wondering if at this point we can merge the PR as is and open a new issue for the view filter, since it doesn't block the main PR.

[docwilmot]

@herbdool

    'filter' => array(
      'handler' => 'views_handler_filter_node_hidden_path',
      'label' => t('Hidden'),
      'type' => 'yes-no',               <<<<<-------------------- Add
    ),

and

class views_handler_filter_node_hidden_path extends views_handler_filter_boolean_operator <<<<<---

Then in the query in the filter handler,

if ($this->value) {   <<<<<<<--------- the user chose "Yes"

// Modify the query as appropriate

The code in that query gives me a headache with all the closures and $vals.

[herbdool]

Thanks @docwilmot I'll give it a try.

[herbdool]

Okay, ready for an other testing. I've now got a functioning views filter for including/excluding content with hidden paths with help from @alexfinnarn and @docwilmot.

cc @olafgrabienski

[olafgrabienski]

@herbdool Here my quick sandbox test results:

(1) From the help text at the content type:

Users who have the "view hidden path" permission will still be able ...

Did you change the capitalized "View" to "view" on purpose? In my opinion, the capitalized version is more convenient.

(2) I wanted to add and configure the Views filter in the "Administer content" view and saw that it was already there and enabled ("Paths are hidden: Yes"), and it works! (I guess someone else had enabled the filter before. Can you double-check that it's not enabled by default?)

[herbdool]

@olafgrabienski 1) nope it wasn't on purpose. I can change it. 2) Actually I added it. I wanted to double-check on a different website.

[quicksketch]

One new issue with the views handler: https://github.com/backdrop/backdrop/pull/2286#pullrequestreview-151606175

My request from before was awkwardly made, so it didn't get conveyed quite:

Can we lop the word "display" off the permission name and change it from "view hidden path display" to "view hidden paths" (similar to "view revisions")?

@herbdool the new permission name is now view hidden path (singular). Can you make that plural; view hidden paths? Other places like on the node type where the setting is just called hidden_path look good to me.

[herbdool]

@olafgrabienski one last review? The main difference is the slight change in permission wording and a fix to the tests.

[olafgrabienski]

@herbdool - done! Have tested the sandbox site regarding

• wording √
• hidden path setting vs. permission to view hidden path √
• Views filter √
• DBlog (no errors) √

So, RTBC in my opinion!

(I've also added the 1.11.0 milestone.)

[quicksketch]

Thanks @herbdool and @olafgrabienski! This looks great! I've merged https://github.com/backdrop/backdrop/pull/2286 into 1.x for 1.11.0. Issue credit in the commit, as there are a lot of people to mention (https://github.com/backdrop/backdrop/commit/e48317db985e31ecd6d90738394b6a1ac43d6388).