🇮🇳India @Akhil Babu

Please review

akhil babu → created an issue.

This is an early version of the workflow plan. It may change as development progresses.

akhil babu → created an issue.

Not sure if this is the correct way:

To show the warning, first add

    if (isset($this->agentsManager->getDefinition($default_agent)['custom_type']) && $this->agentsManager->getDefinition($default_agent)['custom_type'] === 'config') {
      if (empty($this->providerManager->getSimpleProviderModelOptions('chat', FALSE, TRUE, [AiModelCapability::ChatTools]))) {
        $this->messenger->addError($this->t('This agent will not work with the selected model as function calling is not supported.'));
      }
    }

to Drupal\ai_agents_explorer\Form\AiAgentExplorerForm::buildForm

But for this to work,

      if (in_array(AiModelCapability::ChatTools, $capabilities)) {
        continue;
      }

should be added to Drupal\ai_provider_openai\Plugin\AiProvider\OpenAiProvider::getModels in the
1.0.2 version code

marcus_johansson → credited akhil babu → .

Merged. Thanks

akhil babu → made their first commit to this issue’s fork.

akhil babu → created an issue.

akhil babu → created an issue.

The module will not work with the 0.2.0-alpha6 version of experience builder. Could you try with the latest dev release of experience builder?
https://www.drupal.org/project/experience_builder/releases/0.x-dev →

Fixed

Now the dev release of experience builder would get downloaded when the module is downloaded using composer

akhil babu → created an issue. See original summary → .

Merged

Working now

akhil babu → created an issue. See original summary → .

akhil babu → created an issue.

akhil babu → created an issue.

Raised a PR

griffynh → credited akhil babu → .

akhil babu → created an issue. See original summary → .

kristen pol → credited akhil babu → .

kristen pol → credited akhil babu → .

kristen pol → credited akhil babu → .

kristen pol → credited akhil babu → .

kristen pol → credited akhil babu → .

kristen pol → credited akhil babu → .

griffynh → credited akhil babu → .

This warning was appearing in logs while running the tests. So I have updated the AutoSaveManager::save() method to check if $data["entity_form_fields"] exists or not.

/var/www/html/web/modules/contrib/experience_builder/src/AutoSave/AutoSaveManager.php:34
Undefined array key "entity_form_fields"

Please review

akhil babu → made their first commit to this issue’s fork.

Resolved the conflicts and rebased. Thanks

akhil babu → made their first commit to this issue’s fork.

Just saw similar test failures in another merged MR: https://git.drupalcode.org/project/experience_builder/-/jobs/4335852. So I am moving this issue to needs review

Few test are failing even after rebasing. But those are fine in local..🤨

akhil babu → made their first commit to this issue’s fork.

Added the tests as well. Thanks

Thanks for the review @wimleers. I have updated the code to camelCase. Changes are made to the drupalsettings.xb values. Please review

akhil babu → changed the visibility of the branch 0.x to hidden.

I have added a config action 'setBlockSettings' for updating the block settings

config:
  actions:
    block.block.claro_primary_local_tasks:
      setBlockSettings:
        secondary: false

Please review. I will add the tests if the current implementation looks good.

I will try to add the config action

Drupal\Component\Render\FormattableMarkup::placeholderFormat always escapes the special characters in the string if the placeholder passed is '@'. This happens every time, and then the render API properly renders the special characters. But not sure why it's not happening in this case (Maybe because the rendering happens in the decoupled UI, but the label in the component listing /admin/structure/component is also double escaped). Should we use html_entity_decode here?

This issue does not affect for SDC components.

This part of the code is causing the issue

experience_builder_block_alter() {
//
      $component = Component::create([
       //
        'label' => (string) new TranslatableMarkup('@label block', ['@label' => $definition['admin_label']]),
       //
      ]);
}

(string) new TranslatableMarkup('@label block', ['@label' => $definition['admin_label']]) returns the incorrect label for blocks

Created a new MR. This time I am using snake_case for all parameters as it was more simpler to implement 😬

akhil babu → changed the visibility of the branch 3501847-send-entity-keys to hidden.

Conflicts

Ready for review

Thanks @wimleers and @omkar, I have updated the PR to include both the js_componen and xb_asset_library entities. The same id error does not occur for pattern entities as Drupal\experience_builder\Entity\Pattern::generateId() updates the id if an entity with same id exists.

Updated ApiConfigControllers::post() and added the tests. Please review

akhil babu → made their first commit to this issue’s fork.

Hmm.. in my local only the 'og:type' validation part of the test if failing. But here it's failing while opening the front page 🧐

Moving to 'Needs review' so the maintainers can provide their insights on #4.

I have added the tests but it's failing because the 'Content' meta tags are getting applied to the node set as the front page. Eg: For the front page, the og:type is configured as 'website' and for other pages it's cofigured as 'article'. After creating a node and setting it as the site's front page, the og:type is still appearing as 'article' when opening the front page. This happens only while running the tests. If I try this directly from the ui (Create a new node and set it as the front page) , front page tags are coming properly

Also, the front page meta tag config was using 'field_image' to get the image meta tags like image_src, og:image, etc. But the default homepage is a basic page, and the basic page content type has 'field_featured_image' instead of 'field_image'. I’m not sure if it was a mistake or was intentionally set (since 'field_image' field exists in the article content type), but I’ve updated it in this PR as well.

I will try to add the tests

kristen pol → credited akhil babu → .

Tried adding the xb field using FieldConfig::create and FieldStorageConfig::loadByName just now. Field gets added correctly, but could not set setDisplayConfigurable('form', FALSE) and setDisplayConfigurable('view', FALSE)

Updated to use camel casing

Please review

Updated the controller to send the entity type keys

akhil babu → made their first commit to this issue’s fork.

Thanks for the review @wimleers. I updated the field creation code and added a check to see if any of the bundles of a given entity type uses XB or not (ie, experience_builder.enabled is true in the third party setting). The field and it's storage will be create only if xb is enabled for any of the bundles
However, I am now getting Base table or view not found: 1146 Table 'db.node__field_xb' doesn't exist error after enabling xb for any of the content types.

I compared this code with the previous version, where I hardcoded supported entity types and noticed that tables like tables like taxonomy_term__field_xb, node__field_xb were created during the installation of the XB module (A major bug!) wheras now its not happenig. But, unfortunately, the tables are not getting created after enabling xb for a bundle as well.

akhil babu → created an issue.

Updated the documentation. Moving to needs review

Uploading https://git.drupalcode.org/project/drupal/-/merge_requests/9429 as a patch to use in one of our projects, Thanks

akhil babu → made their first commit to this issue’s fork.

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?

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?

I think this test is for the ApiComponentsController
https://git.drupalcode.org/project/experience_builder/-/blob/0.x/tests/s...

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).

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?

Need maintainer feedback to see if the current approach is correct or not. Unassigning for 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...

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.

PHPUnit tests were already available for these routes and I have updated them to validate the CSRF token

experience_builder.api.content.update
experience_builder.api.config.patch
experience_builder.api.config.delete
experience_builder.api.config.post

Couldn't find any PHPUnit tests for the other routes. The cypress tests should be updated for them, I belive
experience_builder.api.preview
experience_builder.api.log_error
experience_builder.api.publish_all

akhil babu → changed the visibility of the branch 3490087-controllers-performing-data to active.

akhil babu → changed the visibility of the branch 3490087-controllers-performing-data to hidden.

As suggested by @larowan, I have added a new method toArray() to the prop source classes

I tried adding a new view bulder for terms like this
Term.php

    'view_builder' => TaxonomyTermViewBuilder::class,

TaxonomyTermViewBuilder.php

  /**
   * {@inheritdoc}
   */
  public function view(EntityInterface $entity, $view_mode = 'full', $langcode = NULL) {
    // Get all the nodes that use this term.
    $tid = $entity->id();
    $query = $this->database->select('taxonomy_index', 't')->fields('t', ['nid'])->condition('tid', $tid);
    $nodes = $query->execute()->fetchCol();

    // Render all the nodes in teaser view mode.
    $build = [];
    $view_builder = $this->entityTypeManager->getViewBuilder('node');
    foreach ($nodes as $node) {
      $node_entity = $this->entityTypeManager->getStorage('node')->load($node);
      $build[] = $view_builder->view($node_entity, 'teaser');
    }

    return[
      '#theme' => 'item_list',
      '#items' => $build,
    ];
  }

The nodes are listed correctly when "Views" is not installed. However, the listing gets duplicated after installing 'views'. This could be fixed by simply checking whether the module is installed or not. but I am not entirely sure if this is the best solution.

Let me give this a try