Allow XB to be used on all node types

The logic to enable XB on article content type was moved to a sub moudle in [# 3498085]. I will try to use the same logic to enable the field on other content types.

That won’t achieve what is described in the issue summary: the purpose of this issue is to evolve it beyond the approach we currently have 😊

Although I am curious what you’re cooking up now! 😄

Hi @wim leers, My plan was to

• Add the option to enable/disable XB in content type settings
• Store it in the third party settings
• Add the XB field programatically, if enabled for a content type

Here is a basic implementation https://git.drupalcode.org/project/experience_builder/-/merge_requests/5...

Need maintainer feedback to see if the current approach is correct or not. Unassigning for now

MR!526 looks like a good start but I am wondering whether these should be configurable fields, because we don't want the user to be able to delete them once they have checked the checkbox. For pages we define a components base field, and I'm wondering if we should do the same for other entity types, except as bundle fields (because they don't necessarily appear on all bundles) via hook_entity_bundle_field_info().

Also I think this should be in a separate xb_node submodule to keep the code entirely separate, and remove the checkbox from sites that never want to use XB on nodes?

I don't see much value from product perspective in splitting the node integration to a separate module. If that's desirable from technical perspective, we could consider it.

#7: veeeeeeeeeery interesting! I really like that! 👍👍👍

#8: I agree with @lauriii on this one: why should we special case Node content entities? I think XB should:

• special case its own Page content entity type
• treat all other content entity types the same — and hence have generic code for them

Am I missing something? 😅

Tentatively retitling/expanding scope per #8 given the idea in #7 seems to make that feasible? 😇

In case there's confusion between #9 and why I opened 📌 Move the addition of the XB field on the Article bundle to a hidden submodule Active , the difference was in XB providing default configuration that turned it on for article nodes, which I wanted moved to a submodule, especially since XB doesn't fully work with nodes yet (in the sense of not being able to use fields within the XB canvas).

With the approach being proposed here (an opt-in checkbox for Node types, or potentially expanded to bundles of other content entity types as well), I think it's fine to keep that within the main module.

However, we shouldn't make Node module a hard dependency of XB. So if it's not efficient to do it as a soft dependency or abstract the solution to content entity types in general, then an xb_node submodule could be a pragmatic choice.

I tried adding the field using hook_entity_bundle_field_info() as suggested in #7.

/**
 * Implements hook_entity_field_storage_info().
 */
function experience_builder_entity_field_storage_info(EntityTypeInterface $entity_type) {
  $fields = [];
  $field_name = 'field_xb';
  $is_xb_supported_entity = in_array($entity_type->id(), ['node']);
  if ($is_xb_supported_entity) {
    $fields[$field_name] = // Field storage definition
  }
  return $fields;
}

/**
 * Implements hook_entity_bundle_field_info().
 *
 * Add the example_field field to appropriate entity bundles.
 */
function experience_builder_entity_bundle_field_info(EntityTypeInterface $entity_type, $bundle, array $base_field_definitions) {
  $fields = [];
  $bundle_entity_type = $entity_type->getBundleEntityType();
  if (empty($bundle_entity_type)) {
    return $fields;
  }
  /** @var \Drupal\Core\Config\Entity\ConfigEntityInterface|null $entity_type_definition */
  $entity_type_definition = \Drupal::entityTypeManager()->getStorage($bundle_entity_type)->load($bundle);

  if ($entity_type_definition?->getThirdPartySettings('experience_builder', 'enabled', FALSE)) {
    $field_name = 'field_xb';
    $field = FieldConfig::loadByName($entity_type->id(), $bundle, $field_name);
    if (empty($field)) {
      $fields[$field_name] = FieldConfig::create([
        'field_storage' => // Field storage definitions
        'bundle' => $bundle,
        'label' => '🪄 XB ✨',
      ]);
    }
  }
  return $fields;
}

The field gets added correctl, but it is still visible in the UI, under 'Manage field/Manage display/Manage form display'. So user could still update/delete the field. Is there any way to hide it from the UI?

#13:

->setDisplayConfigurable('form', FALSE)
->setDisplayConfigurable('view', FALSE)

Thanks @wim leers. I have updated the PR. Few observations after adding the field programatically

• Unable to load the xb UI for the already existing nodes. It's only loading for the pages creating after adding the field.
• If xb field is disabled for a bundle after enabling, the pages that were created after enabling the xb field still display the XB UI.
• Getting the following error on existing pages, after enabling the xb field

AssertionError: assert($items->count() === 1) in assert() (line 27 of modules/contrib/experience_builder/src/Plugin/Field/FieldFormatter/NaiveComponentTreeFormatter.php).

Do we want Experience Builder to work on non-revisionable content entity types? I think the answer is , because that'll prevent saving draft content.

Asking @lauriii to confirm.

That would impact this MR, and might allow us to close ✨ Adding support for XB field in users type since it doesn't have revision_id Active .

I don't think we want to support non-revisionable entities. They would be really confusing in the XB. We might want to consider adding support for templating non-revisionable entity types in future but not something we need to worry about now.

Also, I think that version 1.0 of XB doesn't need to be used on content entity types other than page and node. I think putting a reasonable amount of time into this issue is good, but if we get stuck on a generic solution here, we could punt it to version 2.

Retitling for #18.

We should aim to support all of the core built-in entity types at 1.0 so that it's possible to build a Drupal CMS site without having to learn the existing Field UI tooling for the built-in functionality.

#18 + #19 + #21 make perfect sense — thanks for the fast guidance and confirmation! 😊🙏

In MR 526, an additinal tab for Experience builder was added to the node type edit form, and the value was stored as a third party setting in the node.

But as per #21, we should provide this setting in other entity types as well like taxonomy terms, block etc. But these entities do not have any 'details' element in the settings form. Should we implement separate form alter hooks like node_form_alter, taxonomy_term_alter etc.. to display the XB setting for each entities?
Similerly, experience_builder.schema should be also updated to define the XB thrid party setting for each entities.
Is there any better way to store this setting other than using third party setting in entity types?

Thanks for pushing this forward, @akhil babu! 🤩

Should we implement separate form alter hooks like node_form_alter, taxonomy_term_alter etc.. to display the XB setting for each entities?

We shouldn't be doing it for Node, but NodeType, not for Taxonomy but for Vocabulary.

IOW:

• for revisionable content entity types without bundles: a checkbox at the content entity type level
• for revisionable content entity types bundles: a checkbox at the content entity type's bundle level (e.g. for the "blog post" node type)

Thanks @wim leers, I have updated the code to enable xb for taxonomy terms.
If an entity supports xb, we display the 'Experience builder: {title}' link in the toolbar while viewing the entity. However, I’m not sure how this would work for entities like blocks, where there’s no canonical URL. Maybe we add another tab, like "Experience Builder," next to the existing tabs?

Having the same doubt for user entities as well. We display 'Use Experience builder' option in the account settings (/admin/config/people/accounts) and then render the 'Experience builder: {title}' link in toolbar for all the user canonical urls?

Don't worry yet about that — the link in the toolbar is a temporary measure anyway. This issue is really only about the generalized opt-in configurability, not about generalizing the full functionality :)

This is starting to shape up nicely! 😄 Thanks for pushing this forward! Key missing thing: a kernel test, which should confirm the bug I identified 😇 🤞