🇮🇹Italy @robertoperuzzo

robertoperuzzo → created an issue.

I propose the following testing strategy for the mcp_studio module

Based on the module structure, we need to test:

Core Components

• Forms: SettingsForm, ToolForm, ToolDeleteForm
• Plugin: Studio MCP plugin
• Routes: Admin configuration routes
• Configuration: Schema and default settings

Dependencies

• Parent module: mcp
• Core requirements: Drupal ^10 || ^11
• Required permissions: administer mcp configuration

Testing Strategy

1. Unit Tests

Unit tests focus on testing individual classes and methods in isolation, mocking dependencies where necessary.

File: tests/src/Unit/Form/SettingsFormTest.php

• Test form ID generation (getFormId())
• Test editable config names (getEditableConfigNames())
• Test form array structure building
• Test individual validation methods (if any custom validation exists)
• Mock ConfigFormBase dependencies

File: tests/src/Unit/Plugin/Mcp/StudioTest.php

• Test plugin annotation parsing
• Test plugin configuration handling
• Test tool creation and management
• Test Twig template rendering
• Mock ConfigFactory, Twig, and other dependencies

2. Kernel Tests

Kernel tests run with a minimal Drupal installation, testing integration between components without a full web browser.

File: tests/src/Kernel/StudioPluginKernelTest.php

• Test plugin discovery and instantiation
• Test plugin configuration storage and retrieval
• Test plugin dependency injection
• Test plugin interaction with MCP system
• Verify schema validation

File: tests/src/Kernel/ConfigSchemaKernelTest.php

• Test configuration schema validation
• Test default configuration installation
• Test configuration form integration
• Validate configuration structure integrity

File: tests/src/Kernel/ServiceIntegrationKernelTest.php

• Test service container integration
• Test dependency injection for forms and plugins
• Test service configuration and initialization

3. Functional Tests

Functional tests use a real browser environment to test complete user workflows and UI interactions.

File: tests/src/Functional/StudioAdminTest.php

• Test access control for admin pages
• Test navigation to studio settings
• Test permissions enforcement
• Test menu link visibility and functionality

Coverage:

• Access /admin/config/mcp/studio with proper permissions
• Verify unauthorized access is blocked
• Test breadcrumb navigation
• Test task link functionality

File: tests/src/Functional/StudioSettingsFormTest.php

• Test complete form rendering
• Test form submission and validation
• Test configuration saving
• Test form error handling

Test Cases:

• Valid configuration submission
• Invalid input handling
• Configuration persistence
• Form state management
• CSRF token validation

File: tests/src/Functional/StudioToolManagementTest.php

• Test tool creation workflow
• Test tool editing functionality
• Test tool deletion with confirmation
• Test tool listing and navigation

User Journeys:

1. Create new tool → Fill form → Save → Verify creation
2. Edit existing tool → Modify values → Save → Verify changes
3. Delete tool → Confirm deletion → Verify removal
4. List tools → Navigate between tools → Verify display

File: tests/src/Functional/McpStudioIntegrationTest.php

• Test studio plugin registration with MCP system
• Test studio tools appearing in MCP tool lists
• Test studio configuration affecting MCP behavior
• Test permissions inheritance from parent module

robertoperuzzo → created an issue.

Hi @gagosha I've fixed them.

The problem is about the layout_builder__layout fields.

The Drupal\jsonapi_schema\Normalizer\DataDefinitionNormalizer::normalize() does that control

    if (array_key_exists('type', $property) && !in_array($property['type'], static::JSON_TYPES)) {
      // Unable to find the correct type.
      \Drupal::logger('jsonapi_schema')->error('{type} is not a valid type for a JSON document.', ['type' => $property['type']]);
      $property = (object) [];
    }

In our case the $property['type'] = 'layout_section', so the returned value is (object) [], but it should return just an empty array to be compatible with the returned allowed types array|\ArrayObject|bool|float|int|null|string

robertoperuzzo → created an issue.

robertoperuzzo → created an issue.

robertoperuzzo → created an issue.

robertoperuzzo → created an issue. See original summary → .

I improved the translation process, allowing the developers to choose via YAML configuration to list which kind of fields to be excluded.

The filtering is ALREADY implemented at the field level! The issue description mentions "fields not marked as translatable may still be included," but the code shows proper field-level filtering.

robertoperuzzo → created an issue.

robertoperuzzo → created an issue.

robertoperuzzo → created an issue.

robertoperuzzo → created an issue.

robertoperuzzo → created an issue.

Thank you, j-barnes, for your precious feedback.
If I understand correctly, you have already implemented the fixes listed in your comment. So, please add them to the MR or share the patch to be applied.

Correct the "Changelog" URL.

robertoperuzzo → created an issue.

Regarding Randy’s comment, the ddev-drupal-suite DDEV add-on is now compliant with

https://ddev.com/s/addon-update-checker.sh

and includes the ddev-get topic, so it can be retrieved with ddev add-on list --all. At this point, I’d like to pass the ball to Randy and the DDEV community to consider the possibility of adding it to the DDEV GitHub namespace.

Thank you nexusnovaz for your support and your changes to CONTRIBUTING.md are ok.

I update the branch with the upstream changes. Now the CI pipeline has only one warning, so can be committed.

I implemented an AI Agent that performs
RAG (Retrieval-Augmented Generation) on top of
Typesense’s semantic search.

When a user enters a query (as a prompt), the main agent doesn’t just run it directly.
Instead, it first calls a sub-agent whose job is to determine
which Typesense collection is most relevant to the query.

Once the sub-agent identifies the best collection, the main agent uses that collection to perform a
semantic search in Typesense (following
Typesense’s semantic search workflow).
The retrieved context is then fed back into the AI to generate an enriched, context-aware answer—completing the RAG cycle.

• Dynamic routing: It automatically selects the right collection based on intent.
• Scalability: No hardcoded mapping; adding new collections doesn’t require code changes.
• Accuracy: Queries hit the most relevant data, improving retrieval quality and answers.

• User enters a prompt.
• Main agent calls the sub-agent to pick the most relevant Typesense collection.
• Main agent runs Typesense semantic_search against that collection.
• Retrieved passages are injected into the LLM as context (RAG) to produce the final answer.

robertoperuzzo → created an issue.

valthebald → credited robertoperuzzo → .

robertoperuzzo → created an issue.

Hi @kristen-pol, here’s a brief recap of the current state of the work:

• The ddev-drupal-suite DDEV addon is now compliant with https://ddev.com/s/addon-update-checker.sh. The only missing step is adding the ddev-get topic in the GitHub repo to make it discoverable via the ddev add-on list --all command (I don’t have permission to do that). I successfully tested all the commands listed in CONTRIBUTING.md, so I agree that the issue is RTBC and, from my side, ready to be merged.
• I created the ddev-drupal-ai repo with a draft implementation of the CLI interactions to spin up a Drupal AI environment based on the required AI functionality.
• I opened this issue in the Drupal-AI/ddev-drupal-ai repo to discuss how to merge/handle the CLI wizard setup configuration with the AI recipes ecosystem. (We might also open an issue on drupal.org to broaden the discussion to the whole community, if you think that would be better)

valthebald → credited robertoperuzzo → .

robertoperuzzo → created an issue.

Hi @thatfinegentleman, there isn't any snippet in the issue's description.

Anyway, when you are logged in as admin, are you sure you do not have the following _iub* cookies already saved?

Hi @thatfinegentleman, there isn't any snippet in the issue's description.

Anyway, when you are logged in as admin, are you sure you do not have the following _iub* cookies already saved?

I quickly tested your snippet with the new module version 5.0.0-alpha1 → and the banner is working as shown in the attached screenshot.

So, if your Drupal version is 10.3+, I suggest you use the latest module version. Otherwise, I need more time to debug your snippet. Thank you for your feedback.

robertoperuzzo → created an issue.

valthebald → credited robertoperuzzo → .

After the today's meeting, I share the two main points of DDEV add-on discussion.

1. Move ddev-drupal-suite to the DDEV Namespace

Objective

Transfer ownership of the
ddev-drupal-suite add-on
from the current repository to the official DDEV namespace for greater visibility, credibility, and community adoption.

Actions

1. Initial Contact with Randy
   • Prepare a short Slack message or GitHub issue to Randy (maintainer of DDEV).
   • Clearly state the goal: to move the repository under the official ddev namespace.
   • Highlight the benefits: centralized maintenance, broader adoption, consistency with other official add-ons.
2. Evaluation of Add-on Name
   • Assess whether to keep the current name ddev-drupal-suite or rename it (e.g., ddev-drupal-tools or another clearer alternative).
   • Consider factors such as:
     • Scope of functionality
     • Consistency with other DDEV add-ons
     • Clarity for new users
3. Repository Transfer Process
   • Ensure the current repo is up-to-date, with a clean commit history and a clear README.md.
   • Add or review a CONTRIBUTING.md to make it community-friendly.
   • Request Randy (or DDEV maintainers) to initiate the transfer.
   • Update all documentation links, CI/CD configurations, and references to point to the new namespace.
4. Community Announcement
   • Once transferred, announce the move in DDEV channels (Slack, GitHub Discussions, Mastodon, etc.).
   • Include a migration note if repo URLs change.

2. DDEV Drupal AI Add-on

Objective

Create a ddev-drupal-ai add-on that orchestrates AI-related tools and workflows,
starting from the current proposal in the ddev-drupal-suite repository.

Scope

• Provide a glue add-on that centralizes commands for AI workflows.
• Allow users to:
  1. Request additional add-ons (e.g., unstructured, pgvector).
  2. Install AI "recipes" through an interactive workflow (provider → functionality → setup).
  3. Include a new official add-on for pgvector (currently missing).

Architecture Overview

• Glue Add-on (ddev-drupal-ai)
  • Acts as a meta-tool.
  • Provides DDEV CLI commands for interactive setup.
  • Manages dependencies and recipes.
• Add-on Dependencies
  • unstructured add-on (existing).
  • pgvector add-on (to be created).
• Workflow
  

  ddev drupal-ai setup
   └─ Step 1: Choose AI provider (e.g., OpenAI, Local LLM)
   └─ Step 2: Choose functionality (search, embeddings, Q&A, etc.)
   └─ Step 3: Install required add-ons (pgvector, unstructured, etc.)
   └─ Step 4: Configure environment variables and Docker services
      

Probably, it isn't a good idea to automatically generate the read-only key under the hood, but rather inform the site builder that the search block needs it. So, guide him to create the key and put it in an environment variable.

robertoperuzzo → created an issue.

robertoperuzzo → created an issue.

I mark it as Fixed because the related issue ✨ Add a custom block to render the search UI Active has been merged.

@norbert-goco, if you have any feedback to share, please feel free to leave a comment here or open a new issue. Thank you for your valuable support!

I mark it as Fixed because the related issue ✨ Add a custom block to render the search UI Active has been merged.

robertoperuzzo → created an issue.

I made some tests using the Umami demo website, but I couldn't replicate the problem. I suspect it may be related to the custom project I’m currently working on.

I’ve put this issue on hold for now to gather more details.

Hi @thatfinegentleman, as I wrote here 🐛 Installed version 4.0.3, cookie banner doesn't show up anymore Active , it's likely that you are missing some settings in the iubenda.com dashboard site configuration.

Could you pass me the "Privacy Controls and Cookie Solution" snippet code you find there (obviously without your "siteID" and "cookiePolicyId" values), so I can test your configuration. Thanks

valthebald → credited robertoperuzzo → .

When contributing to fix an issue, we usually need to clone the corresponding forked issue branch on GitLab
(for example: this one). Because of this, I think the ddev drupal-get-module command might benefit from an additional parameter—not just the "version," but also one to specify the issue forked branch. That way, contributors (not only maintainers) could more easily work on open issues.

Maybe I’m stretching the purpose of the ddev command a bit, but I find it really helpful to have two remotes set up like this:

ai-3532795  git@git.drupal.org:issue/ai-3532795.git (fetch)
ai-3532795  git@git.drupal.org:issue/ai-3532795.git (push)
origin      git@git.drupal.org:project/ai.git (fetch)
origin      git@git.drupal.org:project/ai.git (push)

• origin: so I can rebase my branch on 1.2.x and pull in the latest community changes.
• ai-3532795: so I can push my own changes to the issue fork.

What do you think?

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

Regarding the amazee.io provider I link here the Slack thread.

It looks like we can simplify the recipe’s `composer.json` by removing some redundant module requirements:

• `drupal/key` The [`key` module](https://git.drupalcode.org/project/key) is already a dependency of the `ai` module (see [`ai.info.yml`](https://git.drupalcode.org/project/ai/-/blob/1.2.x/ai.info.yml#L9) and [`composer.json`](https://git.drupalcode.org/project/ai/-/blob/1.2.x/composer.json#L6)).
  When you run the command ddev drupal-get-module ai 1.2.x the `key` module is installed automatically.
  Therefore, we can safely remove `drupal/key` from the recipe’s `composer.json`.
• `drupal/menu_link_content` The `menu_link_content` module is used internally by the `token` module (for example, see [token.module#L705](https://git.drupalcode.org/project/token/-/blob/8.x-1.x/token.module#L705)). Since `token` is already a `require-dev` dependency of the `ai` module, there’s no need to declare `menu_link_content` in the recipe.
• `drupal/project_browser` The `project_browser` module is listed as a `require-dev` dependency for the `eca` module, which in turn is a `require-dev` dependency for the `ai` module. This means `project_browser` is already pulled in indirectly, so we can remove it from the recipe’s `composer.json`.

robertoperuzzo → created an issue.

robertoperuzzo → created an issue.

Thank you, norbert-goco, for your patch. I take inspiration from your code to add this feature to the main working issue ✨ Add a custom block to render the search UI Active .

You can find the implementation always in this MR.