Drupal AI

#3578417: AI Automators uninstall leaves ai_automator_status field and related configuration behind

Mon, 13 Apr 2026 09:44:11 +0000

Project: Drupal AI
Type: Normal bug report
Version: 1.3.x-dev
Status: Fixed
Diff: 7976436
Discussion: #3578417 · 7 contributors · 33 comments
Followers: 10

Summary

When the AI Automators module was uninstalled, the ai_automator_status field it had created -- along with its field storage config, field instance config, and references in entity form and view displays -- was left behind on the site. This meant the "AI Automator Status" field kept appearing in Manage Fields for any bundle it had been attached to, and leftover configuration polluted config exports. The fix ensures that all ai_automator_status configuration is fully removed when the module is uninstalled.

Impact

No upgrade or configuration changes required.

Technical details

The root cause was that the ai_automator_status FieldStorageConfig and FieldConfig entities created by AiAutomatorStatusField::modifyStatusField() were not declaring an enforced dependency on the ai_automators module. Drupal's config system uses enforced dependencies to automatically remove config entities when their owning module is uninstalled; without them, the field configs survived uninstall.

The fix operates on three levels:

1. Enforced dependencies on new field creation (AiAutomatorStatusField.php). When modifyStatusField() creates a new FieldStorageConfig it now includes dependencies.enforced.module: [ai_automators]. If the storage already exists, the new ensureModuleDependency(ConfigEntityInterface $configEntity) helper method checks for and adds the enforced dependency. The same enforced dependency is set on the FieldConfig at creation time. A new MODULE_DEPENDENCY constant holds the 'ai_automators' string.

2. Selective hook_uninstall() for field_config (ai_automators.install). Drupal's config system automatically removes field_storage_config entities that carry an enforced dependency during uninstall, but does NOT do the same for field_config entities (a subtlety discovered during implementation). hook_uninstall() therefore retains an explicit deletion loop -- now scoped to only field_config and using the correct field_name query condition instead of the previous incorrect label condition. Entity form and view display references are cleaned up implicitly by Drupal's config dependency cascade when the field config is removed.

3. Post-update hooks to backfill existing installations (ai_automators.post_update.php). Two new post-update hooks using ConfigEntityUpdater handle sites that already have ai_automator_status fields in place: ai_automators_post_update_13001 iterates over all field_storage_config entities and adds the enforced dependency where it is missing; ai_automators_post_update_13002 does the same for field_config entities. Post-update hooks were chosen over regular update hooks on the recommendation of project maintainer fago, because only post-update hooks guarantee the system is in a fully reliable state for entity API operations.

A new kernel test, AiAutomatorsUninstallCleanupTest, covers the full lifecycle: create the media type and automator config, confirm ai_automator_status field storage and field config exist with display components, uninstall the module, and assert that all field config and display references are gone.

Upgrade

Sites running AI Automators that already have an ai_automator_status field need to run database updates so that the backfill post-update hooks add the enforced module dependency to existing field config entities. Without this, the field will still be left behind on the next uninstall.

drush updb

Or visit Administration > Reports > Available updates and run updates from the UI. The two post-update hooks that run are ai_automators_post_update_13001 (field storage configs) and ai_automators_post_update_13002 (field instance configs).

Contribution

Timeline

Opened: March 10, 2026
Committed: April 13, 2026 (1 month and 5 commits later)

Key contributors

cadence96 (SeeD EM)
annmarysruthy (QED42)
fago (drunomics)
a.dmitriiev (1xINTERNET)
ajv009 (FreelyGive)

Collaboration

Two contributions during review meaningfully shaped the final design. First, the issue reporter cadence96 tested an early patch and flagged that while field cleanup worked, the uninstall confirmation page showed nothing -- because without enforced dependencies Drupal had no way to surface what would be removed. That observation drove the enforced-dependency approach. Second, maintainer fago reviewed the implementation and insisted on converting a regular update hook to post-update hooks, explaining that only post-update hooks guarantee the system is in a reliable state for entity operations. During that conversion, a.dmitriiev discovered that Drupal's config system auto-removes field_storage_config via enforced dependencies on uninstall but does NOT do the same for field_config -- which is why hook_uninstall() had to be kept for the latter, while the post-update hooks handle backfilling both types for existing sites.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3582743: Set temp directory in tokenizer

Mon, 13 Apr 2026 09:36:31 +0000

Project: Drupal AI
Type: Major bug report
Version: 1.3.2
Status: Fixed
Diff: dcc1f9e
Discussion: #3582743 · 4 contributors · 17 comments
Followers: 5

Summary

The AI module's tokenizer was writing vocabulary cache files to the hard-coded /tmp directory instead of the server's configured PHP temporary directory. On hosting environments where the temporary directory is set to a non-standard path, those cache files would land in the wrong place or fail silently. The fix ensures the tokenizer now respects the site's configured temp directory, so vocabulary caches go where they are expected on all environments.

Impact

No upgrade or configuration changes required.

Technical details

The Tokenizer utility (src/Utility/Tokenizer.php) wraps Yethee\Tiktoken\EncoderProvider, a library that downloads and caches large vocabulary files needed for tokenization. When no cache path is given to EncoderProvider, it defaults to /tmp regardless of PHP's sys_get_temp_dir() or Drupal's file system settings.

The fix calls EncoderProvider::setVocabCache() in Tokenizer::__construct(), passing the result of FileSystemInterface::getTempDirectory(). Rather than adding FileSystemInterface as a new constructor argument (which would have broken the existing API), a new FileSystemTrait was introduced at src/Traits/File/FileSystemTrait.php. The trait provides a getFileSystem() method that resolves the file_system service via \Drupal::service('file_system'). Tokenizer now uses this trait, and its constructor calls:

$temp_directory = $this->getFileSystem()->getTempDirectory();
$this->encoderProvider->setVocabCache($temp_directory);

A new kernel test class TokenizerTest was added at tests/src/Kernel/Utility/TokenizerTest.php, covering tokenization consistency, different-input behavior, countTokens, empty-string handling, a missing-model error path, the fallback encoder for unrecognized model names, and a specific test (testVocabCacheStoredInTempDirectory) that verifies vocabulary files are written under the PHP temp directory after construction.

Contribution

Timeline

Opened: April 2, 2026
Committed: April 13, 2026 (11 days and 5 commits later)

Key contributors

jan kellermann (werk21)
avinash.jha
marcus_johansson (FreelyGive)

Collaboration

avinash.jha suggested constructor injection of FileSystemInterface as the idiomatic Drupal approach. marcus_johansson chose a trait instead, explicitly noting it was a "non-breaking change", then added the accompanying kernel tests for the tokenizer service. jan kellermann (the original reporter) confirmed the patch worked on their environment.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3573429: Processing automators does not catch all errors

Thu, 09 Apr 2026 16:38:43 +0000

Project: Drupal AI
Type: Normal bug report
Version: 1.3.x-dev
Status: Fixed
Diff: e970c92
Discussion: #3573429 · 8 contributors · 28 comments
Followers: 9

Summary

The OpenAI provider in the AI module could not catch PHP errors (like \TypeError) thrown by the OpenAI PHP client when it received bad API responses. These errors bypassed the existing catch (\Exception) blocks because \Error does not extend \Exception in PHP. The provider layer now catches \Throwable and wraps \Error instances in AiResponseErrorException, so all consumers (automators, chatbot, API explorer, etc.) receive a proper exception they can handle.

Impact

Affects module maintainers.

API change: OpenAiBasedProviderClientBase::handleApiException() parameter type changed from \Exception to \Throwable; PHP \Error instances are now wrapped in AiResponseErrorException

Technical details

OpenAiBasedProviderClientBase is the shared base class for OpenAI-compatible AI providers. Its API methods (chat(), moderation(), textToImage(), textToSpeech(), speechToText(), embeddings()) each wrap SDK calls in try/catch blocks and route errors through a central handleApiException() method. Both the catch blocks and handleApiException() used \Exception as the type, so PHP \Error subclasses (like \TypeError thrown by CreateResponse::from() when the API returns a string instead of an array) were uncaught and caused fatal errors.

The fix has two parts. First, all seven catch blocks in the provider methods changed from catch (\Exception) to catch (\Throwable), and handleApiException() now accepts \Throwable. When the throwable is an \Error instance, it is wrapped in AiResponseErrorException with the original error preserved as the previous exception. Regular exceptions and the existing rate-limit/quota detection pass through unchanged.

Second, the try block scope was narrowed in moderation(), textToSpeech(), speechToText(), and embeddings(). Response object construction (e.g. new ModerationOutput(...), new SpeechToTextOutput(...)) was moved outside the try block so that only the SDK call is covered. A bug in that local code now surfaces as what it is rather than being caught and rethrown as a provider API error.

The initial proposal was to catch \Throwable in the automator processors (DirectSaveProcessing, FieldWidgetProcessing). A reviewer pointed out that fixing it at the provider layer protects all consumers in one place. An intermediate version kept \Throwable at both levels as defense in depth, but the automator-level \Throwable was reverted back to \Exception because the provider now wraps \Error in AiResponseErrorException (which extends \Exception), making the broader catch unnecessary and potentially harmful for debugging local bugs in the automator call chain.

New tests: a unit test for handleApiException() covering \TypeError wrapping, \ValueError wrapping, original error preservation, regular exception rethrow, and rate-limit/quota detection; kernel tests for both DirectSaveProcessing and FieldWidgetProcessing verifying they handle AiResponseErrorException and regular \Exception gracefully (return FALSE).

Upgrade

Subclasses of OpenAiBasedProviderClientBase that override handleApiException() must update the parameter type:

// Before:
protected function handleApiException(\Exception $e): void {

// After:
protected function handleApiException(\Throwable $e): void {

Code that catches exceptions from the provider should already work, since AiResponseErrorException extends \Exception. No changes needed for callers that catch \Exception or AiResponseErrorException.

Contribution

Timeline

Opened: February 13, 2026
Committed: April 9, 2026 (1 month and 6 commits later)

Key contributors

fago (drunomics)
petar_basic (drunomics)
ajv009 (FreelyGive)
harivansh (OpenSense Labs)
abhisekmazumdar (Dropsolid)
jibran (Morpht)

Collaboration

The initial fix by fago caught \Throwable at the automator processor level. petar_basic suggested fixing it at the provider layer instead, so all consumers benefit in one place. ajv009 implemented both levels, but abhisekmazumdar reverted the automator-level \Throwable back to \Exception and narrowed the try blocks to SDK calls only, arguing the broader catch was no longer needed and would make debugging local bugs harder.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3579079: Restrict Topic guardrail silently bypassed due to case-sensitive topic matching

Thu, 09 Apr 2026 16:35:27 +0000

Project: Drupal AI
Type: Normal bug report
Version: 1.3.x-dev
Status: Fixed
Diff: 5089c77
Discussion: #3579079 · 7 contributors · 23 comments
Followers: 8

Summary

The restrict_to_topic AI guardrail could silently pass when it should block, because topic matching between configured topics and LLM-classified topics was case-sensitive. Since LLM responses are non-deterministic in casing (e.g. "Legal Advice" vs "legal advice"), a mismatch would leave both $invalid_topics_found and $valid_topics_found empty, and the guardrail would pass. Both configured topics and LLM-returned topics are now normalized to lowercase before comparison, so the guardrail works regardless of what casing the LLM returns.

Impact

No upgrade or configuration changes required.

Technical details

The RestrictToTopic guardrail plugin classifies user input by sending the prompt text and a list of configured topics to an LLM, which returns a JSON list of topics_present. The plugin then uses in_array() to check each returned topic against the configured $valid_topics and $invalid_topics arrays. Because in_array() is case-sensitive by default, any casing difference between the LLM response and the stored config caused neither array to be populated, silently passing the guardrail.

The fix adds mb_strtolower via array_map to three arrays in RestrictToTopic::processInput(): $valid_topics, $invalid_topics, and $topics_present. The in_array() comparison logic is unchanged. mb_strtolower was chosen over strtolower because topic names are user-configured strings that can contain non-ASCII characters (e.g. Ä, É, ñ), and strtolower only operates on ASCII. Because normalization happens before $all_topics is built, the topic list sent to the LLM in the classification prompt is also lowercase, which nudges the model toward returning lowercase output.

Contribution

Timeline

Opened: March 13, 2026
Committed: April 9, 2026 (27 days and 5 commits later)

Key contributors

abhisekmazumdar (Dropsolid)
annmarysruthy (QED42)
harivansh (OpenSense Labs)
breidert (1xINTERNET)
ajv009 (FreelyGive)

Collaboration

An initial more complex approach by harivansh introduced a matchConfiguredTopics() method that preferred exact-case matches first and fell back to case-insensitive matching. After review feedback from breidert that the code was hard to read, ajv009 simplified it back to a straightforward normalize-then-compare approach. harivansh raised a concern about merging topics that differ only by case (e.g. "Apple" valid and "apple" invalid), but ajv009 and the issue author abhisekmazumdar agreed this scenario is not realistic in practice and the simpler approach was correct. abhisekmazumdar then swapped strtolower for mb_strtolower to handle multibyte characters, as originally proposed in the issue.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3582074: AssertionError: Cannot load the "key" entity with NULL ID

Thu, 09 Apr 2026 16:17:27 +0000

Project: Drupal AI
Type: Normal bug report
Version: 1.3.1
Status: Fixed
Diff: 2d8811e
Discussion: #3582074 · 3 contributors · 17 comments
Followers: 4

Summary

Fixed a fatal error (AssertionError: Cannot load the "key" entity with NULL ID) that occurred when setting up a new Search API server with an AI provider whose API key is not yet configured. The form would crash instead of handling the missing key gracefully. After this fix, a missing API key is logged as an error and the provider continues without authentication where possible.

Impact

No upgrade or configuration changes required.

Technical details

When a provider's api_key config value is not yet set (e.g. during initial Search API server setup), $this->getConfig()->get('api_key') returns NULL. The old loadApiKey() in AiProviderClientBase passed this NULL directly to $this->keyRepository->getKey(NULL), which calls EntityStorageBase::load(NULL). Core's load() method has an assert() on line 266 that rejects NULL IDs, producing the fatal AssertionError.

The fix has two parts:

In AiProviderClientBase::loadApiKey(), the NULL is coalesced to an empty string (?? '') before being passed to getKey(), and the nullsafe operator (?->) is used to chain getKeyValue(). An empty or missing key still throws AiSetupFailureException as before.

In OpenAiBasedProviderClientBase::createClient(), the call to loadApiKey() is now wrapped in a try/catch for AiSetupFailureException. If the key cannot be loaded, the error is logged via $this->loggerFactory and the client factory proceeds without calling withApiKey(). Previously, the code unconditionally called $clientFactory->withApiKey($this->apiKey) even when authentication setup failed.

Contribution

Timeline

Opened: March 29, 2026
Committed: April 9, 2026 (11 days and 5 commits later)

Key contributors

dany.almeida.kairouz
b_sharpe (ImageX)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3574611: Forms are broken when automators or FWA are not configurable

Thu, 09 Apr 2026 16:11:45 +0000

Project: Drupal AI
Type: Normal bug report
Version: 1.3.x-dev
Status: Fixed
Diff: 14c5428
Discussion: #3574611 · 3 contributors · 14 comments
Followers: 4

Summary

When no AI provider was configured for a given operation type (e.g., text-to-image), the automator form displayed an empty form without any notice and could still be saved. Now, RuleBase::extraAdvancedFormFields() checks for available providers and shows an inline warning message with a link to the provider configuration docs instead of rendering an empty form.

Impact

No upgrade or configuration changes required.

Technical details

The ai_automators module lets site builders attach AI-driven automation rules to entity fields. Each rule type has an associated LLM operation type (chat, text-to-image, etc.) and needs a configured provider to function. The configuration form for these rules is built in the RuleBase base class, which all automator plugins extend.

Previously, RuleBase::extraAdvancedFormFields() called $this->formHelper->getAiProvidersOptions($this->llmType) and continued building the form regardless of whether any providers were returned. With no providers, the advanced settings section rendered empty, giving the user no feedback. The form could also be saved in this broken state.

The fix adds an early return when $providers is empty. It looks up the human-readable label for the operation type via $this->aiPluginManager->getOperationType() and renders a messages--warning div telling the user to configure a provider. Because the fix is in the base class, it applies to all automator types, not just the text-to-image case where it was first noticed.

Whether to also block saving the form via validation was raised in comment #7 but deferred to follow-up #3583972 for the 2.x branch.

A new FunctionalJavascript test (AutomatorStringLongProviderWarningTest) covers both paths: one test method verifies the warning appears and the provider select is absent when no provider is installed, and another installs the ai_test module's EchoAI provider and verifies the provider select appears instead.

Contribution

Timeline

Opened: February 19, 2026
Committed: April 9, 2026 (1 month and 3 commits later)

Key contributors

fago (drunomics)
annmarysruthy (QED42)
marcus_johansson (FreelyGive)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3574519: Fix the tag-release to work on linux

Thu, 09 Apr 2026 16:10:39 +0000

Project: Drupal AI
Type: Normal feature request
Version: 1.3.x-dev
Status: Fixed
Diff: fe4de55
Discussion: #3574519 · 5 contributors · 24 comments
Followers: 6

Summary

This is an internal tooling change. The scripts/tag-release.sh script in the Drupal AI module used bash/zsh-specific constructs (pushd/popd, [[ ]], read -p) despite its #!/bin/sh shebang. On Linux, where /bin/sh is typically a minimal POSIX shell like dash, this caused errors such as "pushd: not found". The script was rewritten to use only POSIX-compliant shell constructs so it works on both Linux and macOS. The required Node.js version was also updated from v20 to v24+.

Impact

No upgrade or configuration changes required.

Technical details

The tag-release.sh script automates creating tagged releases of the Drupal AI module. It clones the repo, builds JS UIs in three subdirectories (modules/ai_ckeditor, ui/mdxeditor, ui/json-schema-editor), commits the build artifacts, creates a git tag, removes the artifacts, and pushes.

The original script declared #!/bin/sh but relied on bash/zsh features. On Linux where /bin/sh is typically dash, pushd/popd are unavailable, causing the npm commands to run in the wrong directory and fail with "ENOENT: no such file or directory" errors.

The rewrite makes the script POSIX-compliant. pushd/popd for directory changes during builds are replaced with npm --prefix "$DIR" in the new build_dir() helper function, which avoids directory changes entirely. The reset_version() function uses cd/cd - instead. Bash-specific [[ ]] conditionals become [ ], read -p becomes printf followed by read, and echo with escape sequences becomes printf. Color variables are assigned via $(printf '\033[...') subshells instead of bare escape-sequence strings.

Other improvements bundled in: a check_dependency() function validates node and npm versions up front using POSIX case pattern matching. The minimum Node.js version was raised from v20 to v24, and an npm >= v11 check was added. The macOS-only open command now falls back to xdg-open on Linux. git tag "$TAG" HEAD was changed to git tag -a "$TAG" to create annotated tags that open an editor for the tag message. Error handling was added with || exit 1 throughout the script.

The ui/json-schema-editor/package.json dependency keys were reordered alphabetically. The package-lock.json was regenerated, adding resolved/integrity fields and picking up minor dependency version bumps (rollup 4.57.1 to 4.59.0, etc.).

Contribution

Timeline

Opened: February 19, 2026
Committed: April 9, 2026 (1 month and 5 commits later)

Collaboration

marcus_johansson identified the problem, rewrote the script with full POSIX support, and used it to produce the RC2 release on Ubuntu 22. abhisekmazumdar tested the script end-to-end and successfully created a tag (1.3.1) with it.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3579953: Add bulk operations for media overview page

Thu, 09 Apr 2026 15:10:18 +0000

Project: Drupal AI
Type: Normal task
Version: 1.x-dev
Status: Fixed
Diff: d4798cb
Discussion: #3579953 · 6 contributors · 21 comments
Followers: 7

Summary

The AI image classification recipe now adds Views Bulk Operations (VBO) to the media overview page at /admin/content/media. Editors can select multiple media items and run bulk actions including delete, publish, unpublish, save, and two AI actions: "AI: Image Description" and "AI: Image Tags". This lets editors classify many images at once instead of one at a time.

Impact

Affects site owners.

Requirements: Recipe now requires drupal/ai: ^1.4 (was ^1.2) and new dependency drupal/views_bulk_operations: ^4.4.

Technical details

The core views.view.media view already has a media_bulk_form field using the core bulk_form plugin. Since VBO and core bulk operations fields cannot be used in the same view display together (comment #14), the recipe replaces the existing media_bulk_form field with the views_bulk_operations_bulk_form plugin via the setProperties config action. This modifies the existing view config without overriding the whole thing.

Two new AI automator config entities are added with worker_type: action, which makes them available as VBO actions. They are field-scoped, so two separate automators are needed (comment #4). The image description automator uses the llm_simple_string_long rule with the default_vision AI provider to analyze images and write to field_image_description. The image tags automator uses the llm_taxonomy rule with default_json, taking field_image_description as its base field input to choose or create up to 5 taxonomy terms in the "Image Classification" vocabulary.

The VBO field is configured with six selected_actions: delete, publish, save, unpublish, and the two AI automator actions. An earlier revision used ECA-based actions (eca_preconfigured_action:media_publish_action) for publish/save/unpublish, but review in comment #11 identified that ECA was not a recipe dependency. The actions were switched to core equivalents (entity:publish_action:media, etc.) so they work without ECA installed.

The drupal/ai version requirement was raised from ^1.2 to ^1.4 because the AI automator VBO action feature depends on #3456973.

Contribution

Timeline

Opened: March 18, 2026
Committed: April 9, 2026 (22 days later)

Key contributors

lbesenyei (Brainsum)
a.dmitriiev (1xINTERNET)
ajv009 (FreelyGive)
nodles (1xINTERNET)

Collaboration

Review by ajv009 (comment #11) caught that the original MR used ECA-based action plugins for publish/save/unpublish, but ECA was not a recipe dependency, so those actions silently disappeared from the dropdown. The fix switched to core entity action equivalents. The maintainer noted the merge would proceed but the release would wait for AI Core 1.4.0 to reach at least release candidate.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3577970: Dispatch JS event when DeepChat completes agent calls

Thu, 09 Apr 2026 14:01:49 +0000

Project: Drupal AI
Type: Normal task
Version: 1.2.x-dev
Status: Fixed
Diff: 9c85dc8
Discussion: #3577970 · 2 contributors · 16 comments
Followers: 3

Summary

External scripts can now detect when the DeepChat chatbot finishes running agent calls. In verbose mode, the chatbot updates the same "Contacting Agents..." message rather than creating new messages, so DeepChat's native new-message event never fires on completion. A new agent-call-completed custom event is now dispatched on the deep-chat element when agent execution finishes.

Impact

Affects module maintainers.

New API: New agent-call-completed JavaScript CustomEvent dispatched on the deep-chat element when agent execution finishes.

Technical details

When the AI chatbot runs in verbose mode and loops through agents, it repeatedly updates the initial message in place rather than emitting new messages. Because of this, DeepChat's built-in onMessage / new-message event is never triggered when agent calls complete, leaving no way for external code to detect completion.

The fix adds a CustomEvent("agent-call-completed") dispatch on the deepchatElement in deepchat-init.js. The event fires at the end of the agent loop, right after stepMessages is cleared and shouldContinue is reset to false. The event's detail.message carries the final AI response with role: 'ai' and the rendered html from data.html.

Upgrade

Listen for the new event on the deep-chat element:

document.querySelector('deep-chat').addEventListener('agent-call-completed', (e) => {
  console.log(e.detail.message.html);
});

Contribution

Timeline

Opened: March 9, 2026
Committed: April 9, 2026 (1 month and 6 commits later)

Key contributors

bbruno (1xINTERNET)
marcus_johansson (FreelyGive)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3582856: Add Input Length Limit guardrail plugin against DoW attacks

Thu, 09 Apr 2026 13:47:33 +0000

Project: Drupal AI
Type: Normal feature request
Version: 1.4.x-dev
Status: Fixed
Diff: 9af5bb0
Discussion: #3582856 · 2 contributors · 17 comments
Followers: 4

Summary

New input_length_limit guardrail plugin blocks chat requests that exceed a configurable character or token count before they reach the AI provider API. This provides a safety net against denial-of-wallet attacks (consuming expensive API tokens), context stuffing attacks, and overwhelming the model's context window.

Impact

Affects module maintainers and site owners.

Config change: New ai.guardrail.settings.input_length_limit config schema with max_length, use_tokens, tokenizer_model, check_all_messages, and violation_message keys.
New API: New input_length_limit guardrail plugin blocks chat input exceeding a configurable character or token count.

Technical details

The AI module's guardrail system had no built-in way to limit the length of user input sent to AI providers. The new InputLengthLimit plugin (src/Plugin/AiGuardrail/InputLengthLimit.php) extends AiGuardrailPluginBase and implements processInput() as a pre-generate guardrail.

The plugin only applies to ChatInput. Non-chat input types (e.g. TextToImageInput) receive a PassResult and are skipped. By default, it measures the last user message only. When check_all_messages is enabled, it concatenates all ChatMessage texts (joined with newlines) and measures the total.

Length measurement supports two modes: character-based counting via mb_strlen() (the default), and token-based counting via the ai.tokenizer service with a configurable tokenizer_model (defaults to gpt-4). When the measured length exceeds max_length, the plugin returns a StopResult with a configurable violation message supporting @count, @max, and @unit placeholders. The processOutput() method always returns PassResult since this is an input-only guardrail.

The configuration form uses Drupal #states to show the tokenizer_model field only when use_tokens is checked. A bug in the initial implementation used the wrong form element name selector for this visibility toggle, which was fixed during review.

Config schema was added at ai.guardrail.settings.input_length_limit with five properties: max_length (integer), use_tokens (boolean), tokenizer_model (string), check_all_messages (boolean), and violation_message (string). Unit tests cover character limits, token limits, all-messages mode, last-message-only mode, custom violation messages, multibyte characters, and non-chat input passthrough. Kernel tests verify the full guardrail pipeline using AiGuardrail and AiGuardrailSet config entities with the EchoAI test provider.

Contribution

Timeline

Opened: April 2, 2026
Committed: April 9, 2026 (6 days and 4 commits later)

Key contributors

marcus_johansson (FreelyGive)
ahmad khader (Vardot)

Collaboration

During review, ahmad khader found a bug where the tokenizer_model field visibility state used the wrong form element name (use_tokens instead of guardrail_settings[use_tokens]), fixed it, and moved the issue to RTBC. marcus_johansson split a broader guardrail config schema bug discovered during this work into a separate issue #3583785 for backporting.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3553458: Agents failing to determine solvability forever stuck in "started" state

Thu, 09 Apr 2026 10:02:07 +0000

Project: Drupal AI
Type: Major bug report
Version: 1.2.x-dev
Status: Fixed
Diff: 5ff1ec6
Discussion: #3553458 · 7 contributors · 16 comments
Followers: 8

Summary

When an AI agent failed to determine solvability -- either because it had hit the maximum loop count or because the AI provider chat call threw an exception -- the agent was left permanently in a "started" state with no corresponding "finished" event. This happened because AgentStartedExecutionEvent was dispatched before the conditions that cause early returns were checked. The fix moves the max-loops check before the started event dispatch, and wraps the chat() call in a try/catch that dispatches AgentFinishedExecutionEvent on failure.

Impact

No upgrade or configuration changes required.

Technical details

In AiAgentEntityWrapper::determineSolvability(), the execution tracking relies on a pair of events: AgentStartedExecutionEvent and AgentFinishedExecutionEvent. Before this fix, the method dispatched the started event, then incremented $this->looped, then checked whether the loop count exceeded max_loops. If it did, the method returned JOB_NOT_SOLVABLE immediately without ever dispatching the finished event. Similarly, if $this->aiProvider->chat() threw an exception (e.g. due to an exhausted API quota), the exception propagated up uncaught, again with no finished event dispatched.

Two changes fix this in AiAgentEntityWrapper::determineSolvability():

The $this->looped++ increment and max-loops check are moved to before the AgentStartedExecutionEvent dispatch. If the loop limit is already exceeded, the method returns JOB_NOT_SOLVABLE without creating any tracking state. Because looped is now incremented before the event is constructed, the loop count passed to the event constructor changes from $this->looped to $this->looped - 1 to preserve the original value semantics.
The $this->aiProvider->chat() call is wrapped in a try/catch for \Exception. On failure, the catch block sets $this->finished = TRUE, constructs a dummy ChatOutput with an empty assistant message (the event subscriber does not use the response body), dispatches AgentFinishedExecutionEvent, and returns JOB_NOT_SOLVABLE.

New kernel tests in AiAgentEntityWrapperDetermineSolvabilityTest cover all three scenarios: max loops exceeded (expects 0 started and 0 finished events), chat exception (expects 1 started and 1 finished event), and normal execution (expects 1 started and 1 finished event).

Contribution

Timeline

Opened: October 20, 2025
Committed: April 9, 2026 (5 months and 2 commits later)

Key contributors

mglaman (Acquia)
ajv009 (FreelyGive)
marcus_johansson (FreelyGive)

Collaboration

ajv009, a first-time contributor to the issue, reproduced both failure scenarios described by mglaman, wrote a detailed analysis of the root cause and proposed fix approach, and supplied the patch including kernel tests. marcus_johansson (FreelyGive) made a minor compatibility adjustment to make the tests work with Drupal 10 before merging.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3583705: AiProviderConfiguration form element doesn't work in nested forms with subform states

Wed, 08 Apr 2026 15:55:52 +0000

Project: Drupal AI
Type: Normal bug report
Version: 1.3.x-dev
Status: Fixed
Diff: ef8f787
Discussion: #3583705 · 2 contributors · 13 comments
Followers: 3

Summary

The ai_provider_configuration form element returned a raw string instead of the expected [provider, model, config] array when placed inside a nested form (a container with #tree = TRUE, or a SubformState). This affected any module that embedded the element inside another form's subform. The bug is now fixed and covered by a functional JavaScript test that exercises four nesting configurations.

Impact

No upgrade or configuration changes required.

Technical details

The AiProviderConfiguration form element has a value callback that reconstructs a structured array from the raw POST data. To locate the selected provider and config values it builds $select_parents and $config_parents, which are absolute paths from the form root (e.g. ['root_tree', 'provider', 'provider_model']). The bug was that the callback then called NestedArray::getValue($input, $select_parents), where $input is the element's own local value — a shallow array like ['provider_model' => 'echoai__gpt-test', 'config' => [...]]. When the element sits at the form root the local value and the full user-input tree happen to share the same keys, so the lookup accidentally worked. Inside a nested container or SubformState the paths diverge and the lookup returns NULL, leaving the value as the raw provider_model string.

The fix replaces both lookups with NestedArray::getValue($form_state->getUserInput(), ...). getUserInput() always returns the complete raw POST array regardless of nesting level, so the absolute $select_parents and $config_parents paths resolve correctly in every context.

A new FunctionalJavascript test (AiProviderConfigurationElementNestingTest) exercises all four relevant configurations in one test method: root element without a wrapping container, root container with #tree = TRUE, root container with #tree = FALSE, and an actual SubformState. Each scenario is backed by a dedicated section of AiProviderConfigurationTestForm which renders the captured submitted values into individually addressable <pre> blocks so the test can assert [provider], [model], and [config] independently per scenario.

Contribution

Timeline

Opened: April 8, 2026
Committed: April 8, 2026

Key contributors

a.dmitriiev (1xINTERNET)
marcus_johansson (FreelyGive)

Collaboration

marcus_johansson turned around a fix the same day the issue was opened, providing a video recording of the passing functional JavaScript test as proof across all four nesting scenarios.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3578846: AiGuardrailSet does not declare config dependencies on its referenced guardrails

Wed, 08 Apr 2026 09:09:54 +0000

Project: Drupal AI
Type: Normal bug report
Version: 1.3.x-dev
Status: Fixed
Diff: aa30152
Discussion: #3578846 · 6 contributors · 21 comments
Followers: 7

Summary

AiGuardrailSet config entities now correctly declare config dependencies on the AiGuardrail entities they reference. Before this fix, exported config always showed empty dependencies: {}. This meant Drupal could try to import a guardrail set before its guardrails existed, and it would not warn or prevent deletion of a guardrail that a set still referenced (which would cause a fatal error at runtime). A post-update hook resaves all existing guardrail sets so their stored config gets the correct dependencies.

Impact

Affects site owners.

Config change: ai.ai_guardrail_set.* config now stores dependencies on referenced ai.ai_guardrail.* entities; run database updates to populate dependencies on existing guardrail sets.

Technical details

AiGuardrailSet extends ConfigEntityBase but never overrode calculateDependencies(). The entity stores references to AiGuardrail config entities by ID in pre_generate_guardrails['plugin_id'] and post_generate_guardrails['plugin_id']. Without declared dependencies, Drupal's config system had no knowledge of these relationships.

The fix adds calculateDependencies() to AiGuardrailSet. It collects IDs from both arrays, deduplicates them with array_unique(), loads the actual entities with AiGuardrail::loadMultiple(), and calls addDependency('config', $guardrail->getConfigDependencyName()) for each. Using loadMultiple() and getConfigDependencyName() rather than hardcoding the config name (e.g. 'ai.ai_guardrail.' . $guardrail_id) was a.dmitriiev's deliberate choice to avoid fragile string construction.

ai_post_update_13001 uses ConfigEntityUpdater to resave all existing ai_guardrail_set entities, populating the missing dependencies in already-exported config.

The schema in ai.schema.yml had related bugs found during this work: post_generate_guardrails.plugin_id was typed as a mapping instead of a sequence (not matching pre_generate_guardrails), and stop_threshold (type float) and guardrail_settings (type ignore) were missing entirely from their respective schema entries.

A kernel test AiGuardrailSetDependencyTest covers the new behavior, verifying that both getDependencies() and the raw stored config contain the correct dependency names. The test also demonstrates that referenced AiGuardrail entities must be saved before the AiGuardrailSet that references them.

Upgrade

Run drush updatedb (or equivalent) to trigger ai_post_update_13001, which resaves all ai_guardrail_set config entities so their dependencies are recalculated and written to stored config.

Contribution

Timeline

Opened: March 12, 2026
Committed: April 8, 2026 (26 days and 5 commits later)

Key contributors

abhisekmazumdar (Dropsolid)
annmarysruthy (QED42)
nikro (Dropsolid)
a.dmitriiev (1xINTERNET)
marcus_johansson (FreelyGive)

Collaboration

nikro marked the initial patch RTBC but suggested (as optional) adding an update hook to recalculate dependencies on existing entities. a.dmitriiev then added ai_post_update_13001, changed the dependency calculation to use AiGuardrail::loadMultiple() and getConfigDependencyName() instead of hardcoding the config name, and fixed the kernel test to create guardrail entities before the set (the test was broken because it assumed guardrails could be referenced without being saved first).

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3577813: AI Chatbot block crashes entire site when placed without configured AI Assistant entity

Wed, 08 Apr 2026 09:00:34 +0000

Project: Drupal AI
Type: Major bug report
Version: 1.3.x-dev
Status: Fixed
Diff: 6a814d7
Discussion: #3577813 · 9 contributors · 39 comments
Followers: 12

Summary

Placing the AI Chatbot block (ai_deepchat_block) without selecting an AI Assistant entity caused a fatal AssertionError: Cannot load the "ai_assistant" entity with NULL ID that crashed the entire site, not just the page rendering the block. The block now silently hides itself when no assistant is configured or when the configured assistant has been deleted or disabled. Sites that placed the block before creating any AI Assistant entities, or that deleted a referenced assistant, were affected. The workaround was to delete the block config via Drush.

Impact

No upgrade or configuration changes required.

Technical details

DeepChatFormBlock in the ai_chatbot module did not guard against a NULL or empty ai_assistant configuration value before calling entityTypeManager->getStorage('ai_assistant')->load(). Passing NULL to that method triggers a fatal AssertionError that aborts the entire page render.

The fix adds early-exit guards in both blockAccess() and build():

blockAccess() now returns AccessResult::forbidden() immediately when $this->configuration['ai_assistant'] is empty, before any entity load is attempted.
When a non-empty ID is set but the entity cannot be loaded (stale reference after deletion), it returns AccessResult::forbidden()->addCacheTags(['ai_assistant_list']) so the result is invalidated if a new assistant is later created.
When the entity loads but is disabled, it returns AccessResult::forbidden()->addCacheableDependency($assistant).
The userHasAccess() forbidden and allowed results now include ->addCacheableDependency($assistant)->cachePerUser(), since access depends on both the entity state and the current user.
build() mirrors this with an empty array return for the empty-config and missing/disabled-entity cases.

Previously, the combined !$assistant || !$assistant->status() check returned a bare AccessResult::forbidden() with no cache metadata in all cases, which also meant that calling addCacheableDependency($assistant) on a NULL value was a silent no-op and cache metadata was lost. The split into separate branches, contributed by ajv009 in a follow-up commit, corrects both issues.

A new DeepChatBlockNoAssistantTest functional JavaScript test verifies that the front page returns a 200 and the block is not rendered when placed with no assistant configured. The base test class BaseClassFunctionalJavascriptTests also had its screenshot and video output paths corrected from sites/simpletest/ to sites/default/files/simpletest/.

Contribution

Timeline

Opened: March 8, 2026
Committed: April 8, 2026 (1 month and 6 commits later)

Key contributors

harivansh (OpenSense Labs)
marcus_johansson (FreelyGive)
fago (drunomics)
jatingupta40
ajv009 (FreelyGive)
a.dmitriiev (1xINTERNET)

Collaboration

Multiple contributors iterated toward the final fix. jatingupta40 posted an initial patch; ajv009 then pushed a follow-up that split the single instanceof check into two branches, explaining that calling addCacheableDependency($assistant) on NULL was a silent no-op causing cache metadata to be silently lost, and added cachePerUser() based on a suggestion from jatingupta40. marcus_johansson added the functional JS test and set the issue RTBC. a.dmitriiev rebased the MR to resolve a PHPStan pipeline failure introduced by an unrelated fix already merged into 1.3.x.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3555856: AI Chatbot blocks fail to render: Uninitialized $userMessage property in AiAssistantApiRunner

Wed, 08 Apr 2026 08:43:43 +0000

Project: Drupal AI
Type: Normal bug report
Version: 1.2.2
Status: Fixed
Diff: a90bcfe
Discussion: #3555856 · 7 contributors · 22 comments
Followers: 8

Summary

AI chatbot blocks (ai_chatbot_block and ai_deepchat_block) failed to render on any page due to a fatal PHP error. The getMessageHistory() method in AiAssistantApiRunner tried to call $this->userMessage->getMessage() before any user message existed, which PHP 8.x treats as a fatal error for uninitialized typed properties. This happened on every page load where a chatbot block was placed, making the blocks completely unusable.

Impact

No upgrade or configuration changes required.

Technical details

The class AiAssistantApiRunner declares protected UserMessage|NULL $userMessage; as a typed property with no default value. When session storage is disabled (the !$this->shouldStoreSession() branch of getMessageHistory()), the method returned early with $this->userMessage->getMessage(). Because the property is typed and uninitialized rather than explicitly set to null, PHP 8.x throws Error: Typed property must not be accessed before initialization rather than returning null. A commenter confirmed the call path: getMessageHistory() is triggered during block rendering when the "allow history" setting is session_one_thread.

The fix wraps the access in isset($this->userMessage) && $this->userMessage instanceof UserMessage. If the check fails (no message has been set yet, as is the case on initial render before any user interaction), the method now returns an empty array instead.

Contribution

Timeline

Opened: November 3, 2025
Committed: April 8, 2026 (5 months and 7 commits later)

Key contributors

harivansh (OpenSense Labs)
a.dmitriiev (1xINTERNET)
joshua1234511 (Axelerant)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3582575: Add agent skill and drush generator for Guardrail plugins

Wed, 08 Apr 2026 07:30:09 +0000

Project: Drupal AI
Type: Normal feature request
Version: 1.4.x-dev
Status: Fixed
Diff: 0b36db6
Discussion: #3582575 · 3 contributors · 21 comments
Followers: 5

Summary

The Drupal AI module now ships a Drush code generator and an AI agent skill to help developers create custom guardrail plugins. Before this change, creating a guardrail required knowing the full plugin API: the #[AiGuardrail] attribute, base class hierarchy, four result types, streaming interfaces, and config schema requirements. The new drush generate plugin:ai:guardrail command (alias: ai-guardrail) asks five questions and writes a ready-to-edit plugin stub. The agent skill at .agents/skills/create-guardrail-plugin/SKILL.md gives AI coding assistants (such as Claude or GitHub Copilot) a structured guide to scaffold guardrails from a natural-language description.

Impact

Affects module maintainers.

New API: New drush generate plugin:ai:guardrail command (alias ai-guardrail) scaffolds a deterministic or non-deterministic AiGuardrail plugin stub in any module.

Technical details

Guardrail plugins (#[AiGuardrail]) run before and after AI generation and return one of four result types from Drupal\ai\Guardrail\Result\: PassResult, StopResult, RewriteInputResult, or RewriteOutputResult. Two distinct plugin patterns exist: deterministic (fixed rules, extends AiGuardrailPluginBase, implements ConfigurableInterface + PluginFormInterface) and non-deterministic (calls an AI provider internally, additionally implements NonDeterministicGuardrailInterface, NonStreamableGuardrailInterface, and ContainerFactoryPluginInterface, uses NeedsAiPluginManagerTrait).

Drush generator (src/Drush/Generators/GuardrailGenerator.php) extends DrupalCodeGenerator\Command\BaseGenerator and is registered via the #[Generator] attribute with name plugin:ai:guardrail and alias ai-guardrail. The generate() method interviews for module machine name, label, plugin ID (auto-derived as snake_case from the label), description, and deterministic/non-deterministic choice, then writes src/Plugin/AiGuardrail/{ClassName}.php from one of two Twig templates at templates/Plugin/_ai-guardrail/. The deterministic template produces processInput() with a ChatInput type check, last-message extraction via end($messages), and @todo markers for custom validation logic, plus full ConfigurableInterface boilerplate. The non-deterministic template adds the NeedsAiPluginManagerTrait, a create() method injecting AiProviderFormHelper via ai.form_helper, provider/model configuration in buildConfigurationForm() using AiProviderFormHelper::generateAiProvidersForm(), and submitConfigurationForm() that extracts and type-casts LLM config keys using CastUtility::typeCast().

Agent skill (.agents/skills/create-guardrail-plugin/SKILL.md) is a structured prompt document consumed by AI coding assistants via the /create-guardrail-plugin slash command. It walks through four steps: determine guardrail type, gather requirements, run drush generate plugin:ai:guardrail, add config schema to config/schema/ai.schema.yml under the key ai.guardrail.settings.{plugin_id}, and optionally generate a kernel test using the EchoAI provider. Config schema guidance was added during review (comment #8) after a reviewer found it missing when testing the skill against the InputLengthLimit guardrail from #3582856.

The #[Generator] attribute sets templatePath to __DIR__ . '/../../../templates/Plugin/_ai-guardrail', which is the actual location of the Twig files. The SKILL.md reference section lists templates/guardrail/deterministic.twig (the older path discussed in review), but the authoritative path used by the generator is templates/Plugin/_ai-guardrail/.

Contribution

Timeline

Opened: April 1, 2026
Committed: April 8, 2026 (7 days and 4 commits later)

Key contributors

marcus_johansson (FreelyGive)
ahmad khader (Vardot)

Collaboration

During review, ahmad khader tested the agent skill by running the exact one-shot prompt from comment #5 against the InputLengthLimit guardrail from #3582856. The generated code passed php -l and phpstan --level=1 with zero errors, but the reviewer found that config schema instructions were missing from the skill. This gap was documented in detail in comment #8 and was then incorporated into the SKILL.md before the issue was fixed. The reviewer also raised a naming convention concern about the Twig template directory (templates/guardrail/ vs templates/Plugin/_ai-guardrail/), and the generator was updated to use the latter path.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3579424: The tool category should fixed on Tool Library modal

Tue, 07 Apr 2026 15:43:51 +0000

Project: Drupal AI
Type: Normal feature request
Version: 1.3.x-dev
Status: Fixed
Diff: 5cf71f8
Discussion: #3579424 · 5 contributors · 14 comments
Followers: 6

Summary

In the AI Tools Library modal ("Select Tool" dialog), the left-side category menu scrolled with the content, so it disappeared when a user scrolled down through a long tool list. The menu is now sticky so it stays visible at all times. The content area also gains overflow-y: auto to scroll independently.

Impact

No upgrade or configuration changes required.

Technical details

The fix is a CSS-only change to assets/css/ai_tools_library.css. The .ai-tools-library-menu selector had position: relative, which meant it participated in normal document flow and scrolled away with the rest of the modal. Changing it to position: sticky; top: 0; align-self: flex-start; pins the menu to the top of its scroll container while the content area scrolls. The align-self: flex-start is required for sticky positioning to work inside a flex container, because a flex item that stretches to full height cannot scroll relative to itself. The content panel (the rule around line 149 with padding: 1em; outline: none;) gains overflow-y: auto so it becomes the scrolling region, enabling the sticky behavior to take effect.

Contribution

Timeline

Opened: March 16, 2026
Committed: April 7, 2026 (22 days and 4 commits later)

Key contributors

marcus_johansson (FreelyGive)
shubham.prakash (OpenSense Labs)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3579967: StreamedChatMessageIterator buffer corrupts HTML when consuming streamed responses server-side (relative URLs split mid-attribute)

Tue, 07 Apr 2026 15:38:03 +0000

Project: Drupal AI
Type: Major bug report
Version: 1.3.0
Status: Fixed
Diff: e37b6f7
Discussion: #3579967 · 5 contributors · 21 comments
Followers: 7

Summary

When using the AI module's Chat operation type to process HTML content server-side (for example via ai_integration_eca or any Fiber-based batch consumer), HTML attributes containing relative URLs like src="/sites/default/files/..." were silently corrupted. The shouldFlush() method in StreamedChatMessageIterator held the buffer when it detected an absolute URL being assembled, but not a relative URL starting with /. When the 100-character buffer limit was reached mid-attribute, the buffer flushed and split the URL value across two chunks, breaking the HTML. This fix makes the buffer hold until relative URLs are fully assembled, matching the existing protection for absolute URLs.

Impact

Affects module maintainers.

New API: New getMaxBufferSize() and setMaxBufferSize() public methods on StreamedChatMessageIterator

Technical details

StreamedChatMessageIterator accumulates streamed chunks in a $buffer string and flushes it to callers when a paragraph boundary or the 100-character $maxBufferSize limit is reached. Before flushing, shouldFlush() runs two preg_match calls to detect whether a URL is still being built inside a quoted HTML attribute ("...") or a Markdown link ((...)). The original patterns were /"(?:http|\/\/:)[^"]*$/ and /\((?:http|\/\/:)[^)]*$/, which matched http and the protocol-relative prefix //: but not plain relative URLs starting with /. A relative src like /sites/default/files/image.png split across a buffer boundary would trigger a flush at src="/sites/default", leaving /files/image.png" width="2048" as orphaned text after the closing quote.

The fix adds \/ as a third alternative in both patterns:

// Before
preg_match('/"(?:http|\/\/:)[^"]*$/', $this->buffer) || preg_match('/\((?:http|\/\/:)[^)]*$/', $this->buffer)

// After
preg_match('/"(?:http|\/\/:|\/)[^"]*$/', $this->buffer) || preg_match('/\((?:http|\/\/:|\/)[^)]*$/', $this->buffer)

The test helper EchoProvider was also changed to split its output into 10-character chunks using str_split($string, 10) instead of emitting a single string, so existing and new kernel tests actually exercise the buffer logic. Two new tests were added to ChatInterfaceTest for long relative links in Markdown ([link](/path...)) and HTML (<a href="/path...">), and a new HostnameFilterTest kernel test class exercises the iterator directly with a realistic HTML stream containing a relative src attribute split across chunk boundaries. The new class is annotated @coversDefaultClass \Drupal\ai\Service\HostnameFilter and verifies that relative URLs survive intact while absolute external URLs are filtered out by the hostname filter service.

Two new public methods, getMaxBufferSize(): int and setMaxBufferSize(int $size): void, were added to StreamedChatMessageIterator to expose the buffer size limit.

Contribution

Timeline

Opened: March 18, 2026
First commit: March 26, 2026 (8 days later)
Last commit: April 7, 2026 (11 days and 6 commits later)

Key contributors

increweb21
marcus_johansson (FreelyGive)
abhisekmazumdar (Dropsolid)
a.dmitriiev (1xINTERNET)

Collaboration

marcus_johansson noted after applying the fix and writing kernel tests that he could not actually reproduce the original HTML corruption himself, even with the buffer splitting mid-attribute. He applied the regex fix and added tests based on the reporter's Xdebug evidence regardless.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3559183: Create first improvement of agent form

Tue, 07 Apr 2026 08:51:42 +0000

Project: Drupal AI
Type: Normal feature request
Version: 1.3.x-dev
Status: Fixed
Diff: 652d194
Discussion: #3559183 · 10 contributors · 42 comments
Followers: 11

Summary

The add/edit form for AI Agents is significantly redesigned to reduce visual complexity. Instead of expanding inline details sections for each selected tool, a "Configure" button on each tool card opens a MicroModal overlay containing the tool's settings. The system prompt field now uses the MDX Editor with token typeahead. The structured output schema field uses the ai_json_schema element type instead of a plain textarea. Secondary fields (max loops, orchestration/triage classification, default information tools) are grouped inside a collapsed "Advanced settings" section. The default max_loops value changed from 3 to 10. Property restriction fields are now presented in a table layout per tool rather than individual fieldsets.

Impact

Affects module maintainers and site owners.

Requirements: Minimum drupal/ai version raised from ^1.2.0 to ^1.3.0
API change: AiAgentForm constructor gains a required Token $token parameter; subclasses must inject token service. Modal CSS classes renamed from .modal__* to .ai-modal__*.
New API: New AiAgentForm::afterBuildToolsLibrary() public static after-build callback. New hook_preprocess_ai_tools_library_item() implementation adds a Configure button to tool cards on agent add/edit routes.

Technical details

The form in AiAgentForm.php was restructured in several ways.

Tool configuration modal. hook_preprocess_ai_tools_library_item() in ai_agents.module injects a "Configure" button into each tool card, but only when the current route is entity.ai_agent.edit_form or entity.ai_agent.add_form. The button carries a data-tool attribute (tool ID with colons replaced by underscores). createToolUsageForm() now wraps each tool's settings in MicroModal HTML via #prefix/#suffix on the tool's container element, using the same derived ID. MicroModal.show(id) is called from the openToolsModal Drupal behavior in agents_form.js.

MicroModal bundling. MicroModal v0.4.10 is managed via npm (package.json) and the built micromodal.min.js is committed to the repository under js/. The build script copies it from node_modules. License and source metadata are available via package.json without requiring asset packagist or a CDN. The library is declared in ai_agents.libraries.yml alongside a new css/micromodal.css with CSS classes prefixed ai-modal__ to avoid collisions with themes and other modules.

JavaScript rewrite. agents_form.js was rewritten from jQuery to vanilla JS using Drupal's once() API (comment #34 from jibran, implemented by ajv009 in comment #36). This also resolved ESLint errors. The jQuery UI dialog close event (unavailable without jQuery) is replaced by a MutationObserver on document.body that watches for the removal of .ui-dialog elements, then fires a mousedown on [data-ai-tools-library-form-element-update] to refresh the tool card widget after a tool is selected.

Form structure changes. max_loops, orchestration_agent, triage_agent, default_information_tools, and structured output fields were moved under prompt_detail > advanced (a collapsed details element). Tool settings fields (return_directly, require_usage, description_enabled, description_override, use_artifacts, progress_message) were grouped under a tool_settings sub-key within each tool's container. Property restrictions were restructured from individual fieldsets into a #type => 'table' with three columns (Property, Description override, Restrictions), and the form state paths updated accordingly (e.g., tool_usage[tool_id][property_restrictions][table][property_name][restrictions][action]).

Submit handler. The save() method was updated to read tool_settings.* and property_restrictions.table.* from their new nested paths. A bug found during review (comment #23) where settings like progress_message and use_artifacts were silently dropped was fixed by correcting these paths.

AJAX stability. afterBuildToolsLibrary() is registered as #after_build on the ai_tools_library element. It sets #limit_validation_errors = [] on the update_widget AJAX button and also updates the triggering element copy stored in $form_state, so the form rebuilds correctly after tool selection without requiring all fields to be valid.

Other fixes. orchestration_agent and triage_agent on AiAgent entity changed from non-nullable bool to ?bool = NULL to prevent PHP errors on new entities. A Token service is now injected into AiAgentForm to build token typeahead configuration for the MDX Editor. Gin dark mode support added via CSS custom properties (--gin-bg-layer-rgb, --gin-bg-app-rgb). Z-index values for the modal overlay (1300) and header (1310) were set to sit above Drupal core toolbar and Gin theme layers. A hardcoded element ID selector in agents_form.css was replaced with the generic class .ai-agent-property-restrictions-table.

Upgrade

1. Update drupal/ai to ^1.3.0 in your project's composer.json:

"drupal/ai": "^1.3.0"

2. Subclasses of AiAgentForm must add the Token service to their constructor and pass it to parent::__construct():

public function __construct(
  FunctionCallPluginManager $functionCallPluginManager,
  FunctionGroupPluginManager $functionGroupPluginManager,
  Token $token,
) {
  parent::__construct($functionCallPluginManager, $functionGroupPluginManager, $token);
}

public static function create(ContainerInterface $container): static {
  return new static(
    $container->get('plugin.manager.ai.function_calls'),
    $container->get('plugin.manager.ai.function_groups'),
    $container->get('token'),
  );
}

3. Custom CSS or JavaScript targeting .modal__overlay, .modal__container, .modal__header, .modal__title, .modal__close, or .modal__content must be updated to the prefixed equivalents:

/* Before */
.modal__overlay { … }
.modal__container { … }

/* After */
.ai-modal__overlay { … }
.ai-modal__container { … }

Contribution

Timeline

Opened: November 21, 2025
Committed: April 7, 2026 (4 months later)

Key contributors

marcus_johansson (FreelyGive)
emma horrell (The University of Edinburgh)
ferran_bosch (1xINTERNET)
bbruno (1xINTERNET)
angela saldaña (1xINTERNET)
jibran
abhisekmazumdar (Dropsolid)
ajv009 (FreelyGive)

Collaboration

Review ran two full cycles. abhisekmazumdar found two bugs during the first review pass: the Configure button crashed on the Add Agent form because the AJAX tool picker refreshed only the tool cards widget while the modal HTML lived in a separate DOM section that was not refreshed; and tool settings (progress_message, use_artifacts, description_override) were silently dropped on save because the submit handler still read from the old flat paths after the form nesting was changed. Both were fixed before the second review. jibran then noted that agents_form.js was close to a full rewrite and suggested removing the jQuery dependency. ajv009 rewrote the file to vanilla JS using Drupal's once() API, which also cleared the blocking ESLint errors. abhisekmazumdar followed up with a CSS commit that replaced a hardcoded element ID selector with a generic class and prefixed all .modal__* classes to .ai-modal__*. Gin dark mode issues visible during testing were filed as separate follow-up issues against the AI module (#3582473, #3582474) rather than blocking this issue.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3579632: Add ai:logs Drush command for inspecting AI LLM calls from the CLI

Fri, 03 Apr 2026 03:12:41 +0000

Project: Drupal AI
Type: Normal feature request
Version: 2.0.x-dev
Status: Fixed
Diff: a3ad1c9
Discussion: #3579632 · 5 contributors · 22 comments
Followers: 6

Summary

The ai_logging module now provides a drush ai:logs command (aliases ail, ai-logs) to inspect AI LLM call logs from the terminal. The command queries ai_log entities and displays prompts, responses, provider/model metadata, and tags. It supports filtering by tag (--tag=ai_agents) or provider (--provider=anthropic), limiting result count (--count=20), and viewing single entries with full text (--id=42). This is useful for debugging AI agents, chatbots, or other AI-powered features without opening the Drupal admin UI. The ai_logging module must be enabled and logging must be turned on at /admin/config/ai/logging/settings.

Impact

Affects module maintainers.

New API: New drush ai:logs command (aliases ail, ai-logs) for inspecting AI LLM call logs

Technical details

The AiLogCommands Drush command class uses AutowireTrait for dependency injection and injects EntityTypeManagerInterface to query the ai_log entity storage. The command has two modes: list mode (default) returns multiple log entries sorted by created DESC then id DESC, and single-entry mode (--id=N) returns one full entry. List mode truncates prompt and output_text fields to 80 characters using core's Unicode::truncate(). Filtering is implemented via entity query conditions on tags or provider fields. The command returns RowsOfFields, so Drush provides --format=json|yaml|csv|table, --fields, and --filter options automatically. The ValidateModulesEnabled attribute ensures ai_logging is enabled before execution. Ten kernel tests cover list mode, filtering, single-entry lookup, truncation, empty results, and row structure. The initial implementation was rewritten after maintainer feedback to use Drush's built-in formatters instead of custom output logic, reducing the command from approximately 500 lines to 130 lines and dropping custom token estimation and formatting utilities.

Contribution

Timeline

Opened: March 17, 2026
Committed: April 3, 2026 (16 days later)

Key contributors

ahmad khader (Vardot)
ajv009 (FreelyGive)
scott_euser (Soapbox)

Collaboration

scott_euser (comment #16) reviewed the initial implementation and noted it was overcomplicated with custom formatters, token counters, and truncation logic, and questioned whether to accept it given the project is minimally maintained. ajv009 (comment #18) rewrote the entire command based on that feedback, replacing all custom output formatting with Drush's built-in RowsOfFields formatter, replacing custom utilities with core functions like Unicode::truncate(), and adding kernel test coverage. The rewrite reduced the code from approximately 500 lines to 130 lines and made the command composable with Drush's standard options. The simplified version was accepted.

This content is AI-generated and may contain errors. See Drupal Digests for more.