Experience builder has limited built-in metatag features, disable advanced form fields there as initial stop-gap

Added screenshot.

Added more info on which bits are metatag code in XB.

I wonder would removing the field from the advanced section resolve the problem instead? That's an option on the field widget.

Why not fix this in experience builder?

@catch: I think its also fine to do something along these lines in XB. As said this is a stop-gap.

@damienmckenna: XB adds the metatags field as a base field, and it is set as internal but also configurable :D I don't think there is a way to actually configure this, it does not show up on admin/reports/fields and also XB does not have a way to edit the fields on XB entities (by design I think).

Does metatag need the field to be present to pull from the base fields for metadata? The only thing that XB pulls out of this for its own SEO settings is $form['metatags']['widget'][0]['basic']['title'].

I think "out of the advanced section" in code terms if sidebar FALSE? When I tried that it merely made the metatag fields show up above the SEO settings section. Same problem with robots field then though :)

  #[Hook('entity_base_field_info')]
  public function entityBaseFieldInfo(EntityTypeInterface $entity_type): array {
    $fields = [];
    if ($entity_type->id() === Page::ENTITY_TYPE_ID) {
      if ($this->moduleHandler->moduleExists('metatag')) {
        $fields['metatags'] = BaseFieldDefinition::create('metatag')
          ->setLabel(new TranslatableMarkup('Metatags'))
          ->setDescription(new TranslatableMarkup('The meta tags for the entity.'))
          ->setTranslatable(\TRUE)
          ->setDisplayOptions('form', [
            'type' => 'metatag_firehose',
            'settings' => ['sidebar' => \TRUE, 'use_details' => \TRUE],
          ])
          ->setDisplayConfigurable('form', \TRUE)
          ->setDefaultValue(Json::encode([
            'title' => '[xb_page:title] | [site:name]',
            'description' => '[xb_page:description]',
            'canonical_url' => '[xb_page:url]',
            // @see https://stackoverflow.com/a/19274942
            'image_src' => '[xb_page:image:entity:field_media_image:entity:url]',
          ]))
          ->setInternal(\TRUE)
          ->setProvider('metatag');
      }
    }
    return $fields;
  }

Does XB really need the metatags field on the entity for metatag to work? The easiest would be to not even have the field on :)

This is with sidebar FALSE :)

XB shouldn't be doing weight things like that via hook_entity_base_field_info, it should just add the field via Field API.

I think this should be fixed in experience builder, the whole 'hardcoded metatags field' in hook_base_field_info() seems wrong as @Damien points out.

Additionally it's not obvious whether that field will be removed correctly if metatag is uninstalled so there may be deeper issues going on than just a broken form alter.

Let me repeat the key question: Does metatag need the field to be present to pull from the description and image base fields for metadata?

Matt built this integration, asking him to analyze and propose next steps.

XB crashed before due to the firehose widget. Our team uses this hook:

/**
 * Implements hook_form_FORM_ID_alter().
 */
function OURMODULE_form_xb_page_form_alter(array &$form, FormStateInterface $form_state): void {
  $form['metatags']['widget'][0]['#type'] = 'container';
  $form['metatags']['widget'][0]['basic']['#type'] = 'container';
  $form['metatags']['widget'][0]['basic']['description']['#access'] = FALSE;
  $form['metatags']['widget'][0]['basic']['abstract']['#access'] = FALSE;
  $form['metatags']['widget'][0]['basic']['keywords']['#access'] = FALSE;
  $form['metatags']['widget'][0]['preamble']['#access'] = FALSE;
  $form['metatags']['widget'][0]['tokens']['#access'] = FALSE;
  $form['metatags']['widget'][0]['intro_text']['#access'] = FALSE;
  $form['metatags']['widget'][0]['image_help']['#access'] = FALSE;
}

@mglaman: with that alter the basic elements go away as expected, the closeable metatags section becomes a non-closeable Advanced but the robots checkboxes are still there and therefore lead to the error described. Is that the full extent of the alter you use? All these fields are still present with that alter hook from #13 which I doubt you all expose to users @mglaman :) I'm using metatag 2.1.1.

Adding related issue in 🐛 Autosave publish process does not acknowledge pathauto deactivation Postponed that may cause the checkbox to not work. Even if that would work I think "metatag" working fine is not quite leaving every single field as-is in the sidebar, so lacking further product direction I think leaving all but the XB base field provided (image / description) SEO stuff out for now would be much better. Otherwise (even if the checkboxes then work fine) enabling metatag throws this massive amount of form elements, most of which are quite confusing and super advanced.

That said, until the checkboxes get fixed we do need a workaround that keeps metatag working IMHO.

Does metatag [module] need the [full metatag] field to be present to pull from the description and image base fields for metadata?

No, Metatag can just use tokens in a global configuration to generate meta tags for content entities based upon those few fields, so removing the Metatag field for now would probably be the best bet.

@damienmckenna: are these mappings possible to reproduce in a global config somehow? I think the reason for the field is to use these mappings for xb metadata (unless explicit settings otherwise).

          ->setDefaultValue(Json::encode([
            'title' => '[xb_page:title] | [site:name]',
            'description' => '[xb_page:description]',
            'canonical_url' => '[xb_page:url]',
            // @see https://stackoverflow.com/a/19274942
            'image_src' => '[xb_page:image:entity:field_media_image:entity:url]',
          ]))

The idea with Metatag is to define defaults for each entity type at the global level using tokens to pull in values from the entities. Take a look at Configuration → Search and metadata → Metatag, and customize the configuration for each entity type. You can also override the entity type configuration on a per bundle basis via the "Add default meta tags" page, so that e.g. different content types could have slightly different values based upon the fields available. In theory this should cover most scenarios, especially if you have a few fields on the entity type/bundle for a summary/description and a thumbnail image. IMHO most sites don't need the Metatag field on content types, they should leverage the defaults, fields and tokens.

Also, if you add the Token OR → module you can have either-or logic within each token, useful for setting a failover default if a field isn't filled in.

Had a zoom meeting with Lauri where I showed him the current state. XB has an opinion on what basic SEO fields should be shown and implements all of them as base fields (except the SEO title). So the metatag field is mostly used to wire in the token replacements as shown above in #17. I understand this could be in global config for this entity type. Lauri told me that keeping the field would still be better as it would give the option to create a custom, simpler widget for more complicated SEO settings in the future. I think the field could still be added then, but my aim is to solve metatags not working with XB, not to argue about architecture :)

So attaching a few lines of added code that alters out the metatag section of the form at the existing place where it moves the SEO title field. This works for me, although I don't have the SEO title field somehow in metatag 2.1.1 that I have, so not sure if that would be affected by the #access even though it is moved out of the group. I think for this stop-gap issue that is the remaining question.

gábor hojtsy → changed the visibility of the branch 3531991-experience-builder-has to hidden.

Lauri told me that keeping the field would still be better as it would give the option to create a custom, simpler widget for more complicated SEO settings in the future.

I originally planned to build a new widget for making it possible to customize which meta tags were shown on the edit form, but realized it was pointless when you could just add regular fields and then use tokens to output the tags as necessary.

I don't believe there's any benefit to the Metatag field as it is currently implemented, it feels like it was added as a misunderstanding of how & why it works; my recommendation would be to remove it and just use tokens in the global configurations.

I understand that @damienmckenna. I don't have an opinion either way, so I personally leave considering that to @lauriii and/or other code owners in this area of XB :) My main aim is to make metatag and XB work peacefully together, I don't have architectural opinions about this, trying to help with whatever is needed :)

The remaining fails are around #edit-seo-settings #edit-metatags-0-basic-title of course. I still did not find where this one comes from metatag, but access false-ing the parent does make this inaccessible apparently.

Would be good to get a clear answer from the XB team whether the field should stay and further altering should be put into place (as in #13 but that does not list all the items, see #14) or the field should be removed (which does sound like would be the cleaner solution IMHO).

Re #13, basically this was missing in my MR compared to #13. I don't think this should be committed as-is but this does make metatag work with XB and not emit any scary widgets :)

      $form['metatags']['widget'][0]['advanced']['#access'] = FALSE;

Also adding the current diff file for composer patching purposes.