This blog has all the details what we have done here. Before we start out, let me provide you with all the master links which might be super useful for you:

Module Site - Config Chef - AI Recipe Generator

Master Issue Tracker R1

Youtube Channel

My Propoal

If you need any help with Proposal or any more questions, feel free to reach out to me on LinkedIn.

With that done, let's get started.

My Deliverables

composer require 'drupal/ai_recipe_generator:^1.0@beta'

Project Abstract

What is Drupal?

Drupal is a free, open-source Content Management System (CMS) and digital experience platform built on PHP and Symfony. While platforms like WordPress focus heavily on out-of-the-box ease of use, Drupal is engineered as an enterprise-grade framework for building complex, data-heavy, and high-traffic website

About this project

The project was built with just one thing in mind - to help non-technical people with their Drupal development. So it sits at the heart of Drupal development. We use Drupal Recipes in order to enable this faster. Drupal Recipes are like website blueprints that will help you to build websites. But the main drawback here was that they are really technical to write!

Inorder to help them, we have built this solution which uses AI as the core backbone and empowers users to rapid build and prototype this! Aimed at helping thousands of people.

The features that I have made: 1). AI Recipe Chat: Pick a model, generate recipes via natural prompts, and use the Explain wand for instant breakdowns.

2). Smart Editor: Tweak code manually, validate YAML/schema rules, or let AI refine your changes with Apply Edits.

3). Preview, Export & Save: Inspect outputs live, download as .zip, or deploy directly to web/recipes/custom.

4). LLM Arena: Broadcast one prompt across multiple models to compare results side-by-side.

5). Site Context Aware: Pulls live Drupal architecture into prompts to eliminate duplicate fields and configs.

6). Master Prompting: Enforce system-level persona instructions globally across all AI requests.

7). Benchmarking Metrics: Track token latency, success rates, and model accuracy via visual dashboards.

Major Accomplishments

AI Chat Interface

The AI Chat Interface instantly translates plain English prompts into valid, YAML-compliant Drupal recipes while leveraging live site context to prevent duplicate fields. It features an intelligent editor with schema validation and AI-driven error correction, alongside an educational "Explain" wand that breaks down the generated configurations. Additionally, it enforces global system personas for consistent quality and streamlines deployment through live previews, direct server saves, and .zip exports.

AI Arena

The AI Arena facilitates simultaneous testing by broadcasting a single master prompt to multiple selected LLMs at once. This allows developers to evaluate outputs side-by-side and quickly determine which model generates the most accurate and compliant code.

LLM Benchmarker

The LLM Benchmarker features a visual analytics dashboard to track overall system and model performance. It effectively monitors key metrics, including total successful runs, average token latency, generation costs, and model accuracy.

Technical Challenge Overcame

Chat Interface Layout

Problem: Used a twig template, which caused rendering issues (data loading and UI) as it was difficult to manage.

Solution: Simplified the twig template, did the heavy lifting in the controller.

Impact: A smoother loading and transition, which was then scalable when had a lot of data in the database.

Markdown Paradox

If you are really curious I have a detailed blog with proper testing

Problem: The YAML directly returned by AI caused formatting issues when directly used.

Solution: Used a Drupal Module for YAML editing and built a custom parser.

Impact: The formatting and display of YAML became seamless.

Queries Multiple AI Models

Problem: Queries multiple AI Modules was resulting in higher processing time and code breakage.

Solution: Implemented the Drupal Batch API to query multiple models at once.

Impact: Users could now query multiple models parallelly to get which model performs best for their usecase.

Timeline Chart

I was my planned timeline of what I wanted to it. But in reality I completed things was sooner than the proposed timeline which gave me & my mentor space to work on further integration and adoption with newer versions of Drupal : )

Code Quality & Testing

This is the most important aspect while coding. Drupal has in depth version of testing and maintaining the code quality. I made sure that after each commit the pipeline was green so the code quality was upto standard.

1). Build Stage: Composer Dependency Resolution: Installs and verifies project packages across baseline, maximum PHP versions, next minor Drupal releases, and previous major versions.

2). Validate Stage:

• Syntax & Asset Linting: Checks composer.json syntax (composer-lint), scans for typos (cspell), lints JavaScript (eslint), and validates stylesheets (stylelint).
• Code Standards & Static Analysis: Enforces Drupal PHP coding standards (phpcs) and detects bugs, type mismatches, and deprecations across environments (phpstan).

3). Test Stage:

• Automated Test Execution: Runs PHPUnit suites across baseline and compatibility matrices (maximum PHP version, next minor, and previous major Drupal releases) to ensure all tests pass.

Future Development

The scope of this project is complete. A further focus could be on working on the security patch. The work is in progress.

Acknowledgements

I would like to thank my mentor Rajas Samse along with the entire Drupal community as the whole for providing me with such a great opportunity to work and develop a useful application.

Kudos to them!

Useful Links / Sources

Please feel free to check my website or my other blog about Drupal Hope they provide you with some insight. In case of any questions feel free to reach out to me.

Thanks a lot!

This is the last week of our Google Summer of Code journey. Has an amazing journey with Drupal - one that I will never forget.

So for this last week, Drupal was giving me a gift, D-12 Compatibility. The Drupal Bot gave me a PR: Drupal Bot PR.

Quickly reviewed this PR and that was all for week 12. Compatibility with D-12.

Will post a wrap up blog!

Until then, keep exploring, keep building!

After the excitement of pushing our first Beta release last week, we took a slight breather this week to focus on some essential housekeeping. When you are building a complex module quickly, little inconsistencies can start to creep in. This week, we focused entirely on solving one specific, but very important—issue: cleaning up our administrative routes and refining the UI.

The Problem: Scattered Routes and Hardcoded Links

During the initial development phases, our administrative paths became a bit fragmented. For example, some pages were sitting at /admin/config/ai-recipe, while others were at /admin/config/development/ai-recipes.

This inconsistency led to a few annoying problems:

1). Orphaned Settings: Our settings page wasn't properly nested in the main Drupal configuration menu, making it hard to find. 2). Brittle Code: The sidebar links in our chat dashboard (RecipeChatForm.php) were using hardcoded <a href="#"> tags. If a path ever changed, those links would break immediately. 3). Cluttered UI: The settings form had a bit too much heavy text, making it feel clunky rather than actionable. 4). YAML Quirks: In our routing file, we were using the literal string 'NULL' instead of standard YAML nulls, which isn't best practice.

The Solution: Tying It All Together

To make the module feel native and polished, we completely overhauled how these paths and links are structured. Here is exactly what we did:

1. Unifying the Routing Namespace

We standardized all of the module's routes in ai_recipe_generator.routing.yml so they sit under one predictable namespace: /admin/config/development/ai-recipe-generator/.... Now, everything is logically grouped together.

2. Wiring Up the Menu Links

We created an ai_recipe_generator.links.menu.yml file. This tells Drupal exactly where to put our pages in the admin menu. Now, you can easily find the Settings, Dashboard, Prompt Arena, and Recipe Chat neatly nested right under Configuration > Development.

# Main Settings Page 
ai_recipe_generator.chat_dashboard:
  title: 'Config Chef - AI Recipe Generator'
  description: 'Configure settings and models for the AI Recipe Generator.'
  parent: system.admin_config_development
  route_name: ai_recipe_generator.chat_dashboard
  weight: 100

# Sub-menu items
ai_recipe_generator.dashboard:
  title: 'Dashboard'
  parent: ai_recipe_generator.chat_dashboard
  route_name: ai_recipe_generator.dashboard
  weight: 10

ai_recipe_generator.arena:
  title: 'Prompt Arena'
  parent: ai_recipe_generator.chat_dashboard
  route_name: ai_recipe_generator.arena
  weight: 20

ai_recipe_generator.settings:
  title: 'Settings'
  parent: ai_recipe_generator.chat_dashboard
  route_name: ai_recipe_generator.settings
  weight: 30

3. Dynamic Link Generation

We went into RecipeChatForm.php and stripped out all the hardcoded string paths. We replaced them with Drupal’s dynamic Url::fromRoute() class. This means Drupal will now automatically generate the correct URL based on the route name, making the code much more resilient. If we ever change a URL path in the future, the sidebar links will update automatically!

4. Refining the UI and YAML Syntax

We replaced the string 'NULL' with the standard YAML null character (~) for our optional {thread_id} parameter in the routing file. We also cleaned up the settings page by moving bulky documentation out of the way and utilizing the #description property on individual form fields. This keeps the UI focused and gives users targeted help exactly where they need it.

What's Left?

To wrap this issue up, the final remaining tasks were pretty simple:

1). Doing a quick sweep of the codebase (including Twig templates) to ensure no old legacy paths were hiding in the cracks. 2). Running drush cr (Cache Rebuild) to register the new routing and menu link trees. 3). Clicking through the sidebar to verify all the new dynamic routes point exactly where they should.

It might seem like a small task compared to building AI features, but these architectural cleanups are what separate a good module from a great one.

Catch you up next week!

This week was special, this was close to my heart. Finally did my FIRST RELEASE!!!

Ever since I have seen people releasing their beta, I knew I wanted to do the same. So after finishing the testing and the changes, this was BETA 1 Launch week. Super interesting. Lets dig in!

Alternate: you could follow along this official documentation and skip this Creating a Project Release

Moving from active development (dev) to a Beta release means our primary feature set is code-complete and ready for broader community testing.

If you have ever wondered how a release actually comes together in the Drupal ecosystem, here is a simple breakdown of the steps involved.

What Goes Into Creating a Drupal Release?

Creating a release on Drupal.org is straightforward, but it requires careful preparation so users get stable code and clear documentation.

1. Final Quality Checks & Green Pipeline

Before touching any release buttons, we made sure the codebase was completely clean:

1). All unit, kernel, and functional JavaScript tests passed without issues. 2). Coding standards (phpcs) and static analysis (phpstan) passed with zero errors. 3). Module dependencies and Drupal core compatibility (e.g., core_version_requirement: ^10.3 || ^11) were verified in the .info.yml file.

2. Preparing the Changelog and Release Notes

A good release note tells users exactly what has changed and what to test. We rounded up all the major features and fixes implemented so far.

This is generally when you have multiple major developments. You could technically do this for a beta release as well but since our scope is just limited to me, I have skipped this.

The major steps are:

• The interactive Recipe Chat dashboard.
• AI orchestration and context extraction services.
• YAML parsing and schema validation utilities.
• The complete test suite and CI pipeline integration.

3. Tagging the Release in Git

Drupal releases are tied directly to Git tags following Semantic Versioning. Super useful sources: Types of Releases & Release Naming Convention.

What is a tag?

A tag is like a permanent bookmark or snapshot for a specific moment in a project's history. While branches are meant to keep moving forward as new code is added, a tag stays locked exactly on the commit where it was created. Developers primarily use tags to mark official release versions, like v1.0 or v2.5, so anyone can always go back and download that exact, specific version of the software without worrying about future code changes altering or breaking it.

Once the main branch was verified, creating the tag took just two commands:

# Create an annotated git tag
git tag -a 1.0.0-beta1 -m "Release 1.0.0-beta1: AI Recipe Generator"

# Push the tag up to the Drupal.org repository
git push origin 1.0.0-beta1

4. Creating the Release Node on Drupal.org

Once Drupal.org detects the new tag in the repository, the final step happens on the web interface:

1). Navigate to the project page and click Add new release. 2). Select the 1.0.0-beta1 tag from the dropdown. 3). Paste in the release notes (highlighting key features, how to install, and known caveats). 4). Hit Save to publish.

Drupal.org automatically builds the release package and generates the Composer-compatible metadata so developers can easily install it.

How to Try the Beta

Anyone can now pull down and test the beta version using Composer (You must have seen the glimpse picture at the start):

composer require 'drupal/ai_recipe_generator:^1.0@beta'

Thanks you! Catch ya later : )

Up until now, a lot of our focus has been on building features, tweaking UI, and getting the AI integration just right. But this week, we took a step back to focus on something arguably even more important: stability.

We tackled two massive milestones this week: writing a comprehensive test suite for the AI Recipe Generator and finally fixing up our CI/CD pipeline so everything runs automatically. Let’s dive into what we got done!

1. Building the Test Suite

You can't have a reliable module without tests. From the previous blogs, I have covered quite a few about testing and what all we have been doing. This is the overview of our compelte testing, you can view the entire testing in the testing folder : )

We’ve set up a full testing directory that covers everything from quick syntax checks to headless browser UI testing.

• Unit Tests (tests/src/Unit/): These are our fastest tests. They run without bootstrapping Drupal and use mocked dependencies. They validate things like YamlServicesTest (checking raw YAML syntax), ContextExtractorTest (gathering site data for the AI), and RecipeGenerationServiceTest.
• Kernel Tests (tests/src/Kernel/): This is where we test integration with a partial Drupal bootstrap and an active database. Tests like RecipeStorageServiceTest ensure our database CRUD operations work perfectly, while ArenaServiceTest validates our evaluation logic.
• Functional Tests (tests/src/Functional/): Full PHP-driven browser tests with a complete Drupal installation to test backend form submission logic.
• Functional Javascript Tests (tests/src/FunctionalJavascript/): The real deal. These use Chrome/Selenium to test actual UI interactions, like AJAX requests and dynamic dropdowns in the RecipeChatFormTest.

Running the Tests with DDEV

To make life easy for any developer jumping into this project, everything is configured to run smoothly inside DDEV.

Before running the browser tests, you just need to make sure your .ddev/config.yaml has the required environment variables under web_environment so PHPUnit can reach the site and the Selenium Chrome driver:

web_environment:
  - SIMPLETEST_BASE_URL=http://localhost
  - SIMPLETEST_DB=mysql://db:db@db:3306/db

Once that is set (and you've run ddev restart), you can run the whole suite or break it down by type:

# Run all tests
ddev exec phpunit --configuration=web/core web/modules/custom/ai_recipe_generator/tests

# Run just the lightning-fast Unit tests
ddev exec phpunit --configuration=web/core web/modules/custom/ai_recipe_generator/tests/src/Unit

# Run full browser Javascript tests
ddev exec phpunit --configuration=web/core web/modules/custom/ai_recipe_generator/tests/src/FunctionalJavascript

Tip: If you want to see test names as they run, just append --testdox to your command!

Testing Conventions We Follow

To keep the codebase clean moving forward, we’ve established a few ground rules for new tests:

1. Intent-first naming: Method names should clearly state what they are testing.
2. Process isolation: Adding #[RunTestsInSeparateProcesses] to Kernel and Functional tests (crucial for Drupal 11.3+ and 12).
3. Bypass HTML5 validation: When testing AJAX in FunctionalJS, we inject novalidate attributes to ensure the request actually reaches the server.
4. Arrange/Act/Assert: Non-trivial tests use these comment blocks to keep the logic easy to read.

2. Fixing the Pipeline

If you have been working on some PR or somehow on Drupal code, you know seeing the pipeline green is the most important aspect of it. Quite a few times it drains your soul - why did I get stuck here?

After getting all the test cases written and passing locally, the next big hurdle was the CI/CD pipeline. Previously, the pipeline was throwing some frustrating errors and failing to properly spin up the environments needed to run our heavy FunctionalJS tests.

I spent the second half of the week debugging the configuration, ensuring the database services and Chrome headless drivers were properly communicating inside the runner. The pipeline is now fixed and fully green! Every time we push a commit, it automatically runs our linting checks (phpcs, phpstan) and executes the entire PHPUnit suite.

I will cover testing how to make pipeline green in another blog.

See ya next week!

This week was more about fixing the issues that persisted. Some of them were UI and adding test cases. We dived deeper into testing.

Without further adieu, let me give you a glimpse first.

Testing our application

Testing is one of the backbone of any application. I also started out the testing journey. Drupal testcases are super useful, you can break them down into different files with specific purpose. Let me again take you through this different tests

This time we created a bunch of Kernel tests.

What are Kernel Tests?

Kernel tests (using the KernelTestBase class) are PHPUnit-based integration tests. They boot a minimal, lightweight version of the Drupal environment (the "kernel") rather than a fully installed site.

What are they used for

They are used to test how your code interacts with core Drupal subsystems: like the database, Entity API, services, and configuration: without the massive performance penalty of loading the full HTML presentation layer or simulating a web browser.

The goal for writing any test case is to cover all the possible combinations, your application may encounter.

Diving Deeper into Kernel Test cases

Explicit Setup Requirements Unlike Functional tests, which install a full copy of Drupal behind the scenes, Kernel tests start completely bare. If your test needs a module,you must explicitly declare it in the $modules array. Furthermore, just enabling a module doesn't install its database tables or default configuration; you must manually trigger these in your setUp() method using calls like $this->installEntitySchema('node') or $this->installConfig(['my_module']).

Configuring this is slightly more complex than Unit Test cases, as it will take more time.

Access to the Database and Container Kernel tests connect to a real, isolated test database and fully compile the Drupal service container. This is their primary advantage over Unit tests:you can write real data to tables and retrieve real services (like the database connection or entity type manager) instead of writing dozens of complex, fragile mocks.

The Missing Browser (and Recent Upgrades) Historically, Kernel tests were strictly for backend APIs. There is no logged-in user, no active theme, and no browser. However, recent additions to Drupal core (via HttpKernelUiHelperTrait) now allow Kernel tests to make HTTP requests using $this->drupalGet(). Instead of spinning up a browser, these tests pass requests directly to Drupal's HTTP kernel. This allows you to test page routing and text responses much faster than before, though you still cannot submit forms or run Javascript.

When NOT to Use Them You should avoid Kernel tests if:

i. A pure Unit test will work (i.e., you can easily mock all dependencies). ii. You need to test form submissions or complex UI interactions. iii. The functionality behaves differently depending on the active front-end theme.

Demystifying Drupal Recipes

Alongside testing, a major part of the work this week involved wrangling Drupal Recipes. If you haven't worked with them yet, they are fundamentally different from traditional modules.

1. The "One-Way Street" Concept Unlike modules, recipes are applied, not installed. Once you run a recipe, it dumps its configuration directly into your active site and steps away.

• No Uninstall: Drupal doesn't track what a recipe did, so there's no native "undo" button.
• Idempotency: You can safely run the same recipe multiple times. It simply skips configuration that already exists.
• Direct Modification: Because recipes alter active config instantly, any YAML errors (like targeting non-existent config) will break the application.

2. The DDEV Pathing Fix When applying recipes locally inside a DDEV environment, drush silently shifts its working directory to the web root. If your recipe is sitting in the project root, relative paths will fail or trigger confusing schema errors.

• The Fix: Always execute using the absolute container path:

ddev drush recipe /var/www/html/recipes/your_recipe_name

3. Recovery Strategies (When things go wrong) Because recipes lack an uninstall feature, you have to handle recovery externally if a recipe applies unwanted changes:

• Database Snapshots (Best): To revert to a clean state.
• Config Rollback: overwrite the database with your clean YAML files (though you still have to manually uninstall any modules the recipe added).
• Manual Reversal: Read the recipe.yml and manually undo the changes in the Drupal UI.

ddev restore-snapshot [name] // database snaphots

ddev drush cim - y // config rollback

4. How to Actually Test Them To avoid breaking your site while developing, use these workflows:

• The Blank Canvas: Apply the recipe to a completely fresh Drupal install (like the Minimal profile) to ensure it isn't secretly relying on your specific local database configuration.
• Snapshot & Diff: Take a snapshot, export your config (drush cex), run the recipe, export again, and use git diff to see the exact YAML changes.
• Automated PHPUnit: Use Drupal Core's RecipeTestTrait to write functional tests that spin up headless instances, apply the recipe, and programmatically verify the results.

Polishing the UI

Beyond testing, a huge chunk of this week was dedicated to refining the AI Recipe Generator's chat dashboard.

Bringing Markdown to Life (The Big Win) When the AI explains a recipe, it returns the response formatted in Markdown. Initially, Drupal's standard string sanitation (htmlspecialchars) meant the browser was just spitting out literal characters like ### Requirements and **Node:** instead of actual formatting.

To fix this, I integrated the league/commonmark library into the module's backend. I refactored the message rendering loop in RecipeChatForm.php so that before a message hits the template, it passes through the CommonMark engine. Now, the AI's raw text renders beautifully into structured HTML: clean headings, bold typography, and proper lists—while remaining secure against XSS vulnerabilities.

The "Save Button" Dilemma I also had to make a tough architectural call regarding file saving. Originally, we had a "Save to Folder" button that dumped the generated YAML directly into the web/recipes directory. This created two massive problems:

i. Permissions: Standard web servers (www-data) don't have write access outside the web root, which would force admins to manually chown/chmod directories just to use the module. ii. The Air Gap: Because recipes are a "one-way street" with no uninstall feature, automatically saving potentially hallucinated AI configurations directly to the server is incredibly dangerous.

The Solution: I scrapped the server-save button entirely. Instead, we now rely on direct memory downloads using Symfony's ResponseHeaderBag. The generated YAML is served directly to the user's browser, forcing them to manually review it and intentionally apply it via the terminal.

Squashing CSS and Layout Bugs To finish out the week, I went on a UI bug-squashing spree:

• Dynamic Validation Badges: The stats panel (Latency, YAML validity, Schema validity) used to be hardcoded green. I wired up the PHP backend to dynamically assign .valid-badge, .invalid-badge, or .neutral-badge CSS classes based on the actual live validation state.
• Button Makeovers: The "Export" buttons were rendering as ugly default gray browser inputs. I wrapped them in hidden submit layers, allowing us to style them as sleek, blue pill-shaped buttons with FontAwesome icons that match the design system.
• Flexbox Wrangling: The dashboard was plagued by double vertical scrollbars and horizontal overflow. By fixing 100vw constraints, using calc() for margins, and applying flex-grow: 1 to the Ace Editor, the layout now fits the viewport perfectly and the YAML editor finally stretches to fill the vertical space.
• CSS Variable Scope: Fixed an issue where user chat bubbles were rendering completely white. The global .chat-dashboard-master wrapper was missing from the main form array, preventing our custom CSS color variables from cascading down the DOM to the child elements.

Thanks for reading & catch you up next time

This week we have made quite a bit of progress. Small victories but essential victories. I have worked on the LLM Arena Page, refining it better. Let's dive into it :)

Official Tracker: Week 7 Tracker

Glimpses on our work

How I fixed the UI Interface?

In Week 5 while fixing our blog we were stuck, had to rework a lot but now if we see this, we have successfully changed the UI.

My goal was simple: transform the interface from a standard form-based page into something that the user can instantly use doesn't have to think - How do I use this?

The NEW User Experience

Started to change UI, some changes

Modern Chat Bubbles: Messages are now visually separated into intuitive left/right aligned chat bubbles. User prompts appear in a distinct dark blue, while system responses show up in a clean light gray.

Seamless History Navigation: Your chat history now lives in a dedicated, scrollable sidebar. Clicking on a previous thread instantly loads that conversation into the main window without refreshing the page. I also added a "Load More" link to fetch older threads 10 at a time, keeping the initial page load blazing fast.

Instant Context Resets: The "+ New chat" button has been fixed and upgraded. Clicking it immediately clears the canvas via AJAX so you can start brainstorming a new recipe right away.

Actionable System Buttons: Underneath system responses, you will now see sleek, minimalist icon buttons for actions like "Explain" and "Retry."

Graceful Error Handling: Previously, forgetting to select an LLM Provider and Model before hitting submit could cause a jarring page error. Now, you’ll get a smooth, animated red inline toast notification directly above the chat box reminding you to select your model.

Polished UI Elements: I stripped out default generic buttons and basic emojis in the sidebar footer, replacing them with standard, cleanly spaced Font Awesome icons.

Under the Hood: Technical Implementation

Migrating a traditional web form into a dynamic, single-page application (SPA) style interface required several structural changes to the architecture, particularly within Drupal's Form API and AJAX framework.

1. Refactoring the Sidebar for Precise AJAX Targeting

The biggest hurdle was the chat history sidebar. Previously, it was hardcoded into a static Twig template (ai-recipe-dashboard.html.twig), meaning any interaction required a full page reload.

To fix this, I migrated the sidebar structure out of the Twig template and directly into the Form API inside RecipeChatForm.php. By doing this, I gained the ability to use precise AJAX targeting. I implemented dedicated callbacks:

• ::ajaxRefreshSidebar: Triggered by the "Load More" button to rebuild only the sidebar.
• ::ajaxRefreshMain: Triggered by clicking a historical thread or "+ New chat" to refresh the main chat area independently.

2. Optimizing Database Queries with Pagination

To prevent loading massive chat histories all at once, I updated the underlying data service. The signature for fetching threads was updated to include pagination parameters: RecipeStorageService::getRecentThreads(int $limit = 10, int $offset = 0): array

This ensures the database is only queried for 10 records at a time, dramatically improving memory usage and load times.

3. Fixing Form Actions and Library Dependencies

I squashed a few stubborn bugs related to form submission and rendering:

• The 500 AJAX Error: The "+ New chat" button was missing a dedicated submit handler. I introduced submitNewChat to clear the thread_id and reset state variables (latest_yaml, last_prompt) safely.
• Invisible Action Buttons: The "Explain" and "Retry" buttons were originally configured with #type => 'html_tag', which breaks Drupal AJAX. I converted them to standard #type => 'submit' elements, wrapping them in #prefix and #suffix to render the Font Awesome icons with a transparent, clickable CSS overlay. I also ensured fontawesome is properly attached via RecipeChatController.php.

4. Inline Validation over Fatal Errors

I replaced a harsh PluginNotFoundException with a much friendlier user experience. If a user submits a prompt without selecting an LLM provider or model, I now intercept this in the form state validation. Instead of a fatal error or a standard Drupal block message, it triggers a custom #type => 'html_tag' element that bypasses aggressive text filters to render a styled ⚠️ toast notification right where the user is looking.

5. CSS Overrides

Finally, I added highly specific CSS rules (using !important where necessary) to strip out default Drupal form and button margins. If you are making custom CSS in Drupal, chances are you have already done this : )

Changes we did in LLM Arena

The Unified User Experience

Restored Action Buttons: If you noticed missing icons on buttons like "Remove" or "Fire Prompt," they are now fully restored! I integrated Font Awesome 6 icons directly into the buttons, complete with smooth hover animations and the clean Drupal Claro color palette. Earlier the icons were not there : )

A Unified Preview Interface: Previewing a generated recipe in the LLM Arena now uses the exact same UI as the Main Chat Dashboard, ensuring a familiar experience everywhere in the app.

Under the Hood: Technical Implementation

Bringing the Arena up to speed required solving some quirks in Drupal's Form API and centralizing our data architecture.

1. Outsmarting HTML <input> Tags for CSS Icons

In Drupal, form action buttons are rendered as <input type="submit"> tags. Because <input> is an HTML void element, it ignores CSS ::before or ::after pseudo-elements, which broke my injected Font Awesome icons.

To fix this without breaking Drupal’s Form API or AJAX:

I wrapped the submit inputs in a structural #type => 'container' (<div>).

I moved the Font Awesome styling to this new wrapper.

I styled the inner <input> element to be visually transparent (opacity: 0) while stretching it to cover the styled wrapper, making it fully clickable.

2. Centralizing Database Logic

Previously, the Arena and Main Chat used entirely different mechanisms to save data. The Arena was bypassing our centralized RecipeStorageService and executing direct database inserts, leading to fragmented data and sync issues.

I refactored the data layer to fix this:

Service Injection: I updated ArenaService to require RecipeStorageService via dependency injection.

Streamlined Saving: I completely rewrote the saveToDashboard() method to route through $this->storageService->logGeneration() instead of performing raw DB queries.

Clean Separation: I implemented a unique thread ID prefix (arena_...) and a distinct action type (arena_benchmark). This allows the Arena and Main Chat to share the exact same database tables without mixing up standard chat threads with Arena benchmarks.

By centralizing the storage logic, the codebase is much more maintainable, and our dashboard data is perfectly synchronized.

tests/src/
├── Unit/                  # Fast, isolated tests with no Drupal bootstrap
├── Kernel/                # Integration tests with partial Drupal bootstrap
├── Functional/            # Full browser tests with complete Drupal installation
├── FunctionalJavascript/  # JavaScript interaction tests
└── Traits/                # Shared test helpers

Testing my way through it

Lastly, I’ve been giving the AI Recipe Generator a lot of cosmetic love, polishing the UI, sharpening the presentation, and making sure the front-end looks delicious. But any chef will tell you that a beautiful plate doesn't matter if the kitchen is chaotic.

Had taken quite a bit of refrence from AI Context (my goto place for refrence)

This week, there are no new buttons or shiny features. Instead, I’ve been under the hood, deep-cleaning the backend engine to ensure it never chokes on an order.

The Backend Recipe: Pure Isolation

AI engines are brilliant, but they can be messy prep cooks. When they spit out malformed YAML strings or stumble over missing database states, the app breaks. To fix this, I built a rigid validation line using PHPUnit:

The YamlServices Test: Powered by PHPUnit Data Providers, this acts like a strict health inspector. Every single generated YAML string is checked for syntax compliance before it ever touches runtime.

The ContextExtractor Test: A true test of a chef is how they perform in an empty kitchen. I completely mocked out Drupal core services (like ConfigFactory and EntityTypeManager). The system can now map site context in total isolation, free from live database dependencies.

The Secret Ingredient: Modern PHP 8 Attributes

Out with the stale, in with the fresh. I stripped out the old-school docblock annotations and upgraded the suite to modern PHP 8 Attributes (like #[CoversClass] and #[DataProvider]). It’s cleaner, faster, and fully prepped for Drupal 11+.

Next on the Menu

The foundation is rock solid, but the prep work isn't done. Up next:

Baking Kernel tests for the BenchmarkDashboardService to map database logic.

Functional testing for the Recipe Generation forms.

Isolating remaining stateful tests with #[RunTestsInSeparateProcesses].

Thanks for reading & catch you up next time :)

We have finally crossed the half way mark of our journey, that we are going to go to. Last week we were in a bit of soup, had to rework a bit of twig files and format. This week we have covered a lot, most of the functions, databases etc.

Official Tracker: Week 6

Glimpse of what we have built so far in our journey!

We have tried to cover all aspects rather than just one part of it.

let's dive deep into Week 6!

Getting things on track

Our first issue was that the chat UI you can see was not visible, the functions were not working. So first I took one thing at a time, defined the structure, just the core one without any proper focus on UI just the feature should work & data should be stored.

The UI Foundation: Keep It Simple

I started by establishing the base structure. I set up a single Twig file mapped to a custom Controller. For now, I kept the CSS really, really bare. The goal this week was purely structural and functional—making sure the data flows correctly before making it look pretty.

The core of the interface is the Preview Pane on the right side of the screen. This pane gives the user three main capabilities:

1. Preview the YAML: See exactly what the AI generated.
2. Explain the Solution: Get a plain-text breakdown of what the recipe actually does.
3. Retry / Refine the Prompt: Iterate on the generation if it missed the mark.

To make the YAML editing experience native and smooth, I pulled in a new dependency: the yaml_editor module, which provides a great out-of-the-box editing experience.

Validation & Contextual Edits

Generating code is only half the battle; ensuring it won't break a Drupal site is the other.

I added Validator buttons that run the generated code through the YAML parser service. This ensures the YAML structure is valid and strictly checks the schema for the required recipe components: name, description, type, install, and config.

I also implemented an Apply Edits button. This feature is particularly cool because it takes into account both the user's natural language feedback and any inline comments they leave directly inside the YAML editor. It packages that context and sends it back to the AI so the LLM understands exactly where and why it needs to refine the recipe.

Exporting & Saving Recipes

Once a user has a valid, working recipe, they need to actually use it. I built out the functionality to either save the recipe directly to the server's file system or package it into a ZIP file for download.

Here is the implementation for the core file management logic:

  /**
   * Saves the generated YAML to a physical folder on the server.
   */
  public function submitSaveRecipe(array &$form, FormStateInterface $form_state) {
    $yaml = $form_state->get('latest_yaml');

    if (empty($yaml)) {
      $this->messenger()->addWarning($this->t('There is no recipe to save yet.'));
      return;
    }

    $folder_name = 'recipe_' . date('Ymd_His');
    $directory = $this->rootPath . '/recipes/custom/' . $folder_name;

    try {
      $this->fileSystem->prepareDirectory($directory, FileSystemInterface::CREATE_DIRECTORY | FileSystemInterface::MODIFY_PERMISSIONS);

      $file_path = $directory . '/recipe.yml';
      $this->fileSystem->saveData($yaml, $file_path, FileExists::Replace);

      $this->messenger()->addStatus($this->t('Recipe saved successfully to: @path', ['@path' => $file_path]));
    }
    catch (\Exception $e) {
      $this->messenger()->addError($this->t('Failed to save recipe: @message', ['@message' => $e->getMessage()]));
    }

    $form_state->setRebuild(TRUE);
  }

  /**
   * Generates a ZIP file on the fly and forces a browser download.
   */
  public function submitExportZip(array &$form, FormStateInterface $form_state) {
    $yaml = $form_state->get('latest_yaml');

    if (empty($yaml)) {
      $this->messenger()->addWarning($this->t('There is no recipe to export.'));
      return;
    }

    // 1. Safely determine the temporary directory.
    $drupal_temp = $this->fileSystem->realpath('temporary://');

    // If Drupal's temporary directory is not writable, fallback to system temp.
    $temp_dir = ($drupal_temp && is_writable($drupal_temp)) ? $drupal_temp : sys_get_temp_dir();

    // Create a unique absolute file path for the ZIP.
    $zip_filename = $temp_dir . '/recipe_export_' . uniqid('', TRUE) . '.zip';

    $zip = new \ZipArchive();

    if ($zip->open($zip_filename, \ZipArchive::CREATE | \ZipArchive::OVERWRITE) !== TRUE) {
      $this->messenger()->addError($this->t('Could not initialize the ZIP file.'));
      return;
    }

    $zip->addFromString('recipe.yml', $yaml);

    // 2. Check if close() actually succeeds (writes to disk).
    if (!$zip->close()) {
      $this->messenger()->addError($this->t('Failed to write the ZIP file to the server. Check permissions for: @dir', ['@dir' => $temp_dir]));
      return;
    }

    // 3. Force the browser download
    $response = new BinaryFileResponse($zip_filename);
    $response->setContentDisposition(
      ResponseHeaderBag::DISPOSITION_ATTACHMENT,
      'ai_recipe_export.zip'
    );

    // Automatically delete the temporary file after download completes.
    $response->deleteFileAfterSend(TRUE);

    // Bypass standard form rendering to output the file.
    $form_state->setResponse($response);
  }

The Brains of the Operation: RecipeGenerationService

To orchestrate all of this, the RecipeGenerationService acts as the central nervous system. It connects the Drupal AI provider, extracts the site context, and formats the ChatInputs depending on whether the user is generating a new recipe, asking for an explanation, or refining existing code.

One of the most important architectural decisions here was keeping the codebase DRY (Don't Repeat Yourself). If you look closely at the class below, you will notice that generateRecipe, explainRecipe, and refineRecipe all construct their specific prompt structures, but they all ultimately route their data through a single, unified function: queryLlm().

By centralizing the actual handoff to the AI provider into one core method, the system is much easier to maintain, debug, and scale if we need to add new AI operations down the line.

<?php

namespace Drupal\ai_recipe_generator\Service;

use Drupal\ai\AiProviderPluginManager;
use Drupal\ai\OperationType\Chat\ChatInput;
use Drupal\ai\OperationType\Chat\ChatMessage;
use Drupal\Core\Config\ConfigFactoryInterface;
use Drupal\ai_recipe_generator\Utility\YamlProcessor;

/**
 * Service to generate Drupal Recipes using AI.
 */
class RecipeGenerationService {

  protected AiProviderPluginManager $aiProviderManager;
  protected ContextExtractor $contextExtractor;
  protected ConfigFactoryInterface $configFactory;

  public function __construct(AiProviderPluginManager $ai_provider_manager, ContextExtractor $context_extractor, ConfigFactoryInterface $config_factory) {
    $this->aiProviderManager = $ai_provider_manager;
    $this->contextExtractor = $context_extractor;
    $this->configFactory = $config_factory;
  }

  public function getProviderOptions(): array {
    $options = [];
    $definitions = $this->aiProviderManager->getDefinitions();

    foreach ($definitions as $provider_id => $definition) {
      try {
        $provider = $this->aiProviderManager->createInstance($provider_id);
        if ($provider->isUsable('chat')) {
          $options[$provider_id] = (string) $definition['label'];
        }
      }
      catch (\Exception $e) {
        // Skip unconfigured providers.
      }
    }
    return $options;
  }

  public function getModelOptionsForProvider(string $provider_id): array {
    if (empty($provider_id)) {
      return [];
    }

    try {
      $provider = $this->aiProviderManager->createInstance($provider_id);
      if ($provider->isUsable('chat')) {
        return $provider->getConfiguredModels('chat');
      }
    }
    catch (\Exception $e) {
      // Skip if provider fails to instantiate.
    }
    return [];
  }

  private function buildChatInputRecipeYamlGeneration(string $user_prompt): ChatInput {
    $site_context = $this->contextExtractor->getSiteContextMap();
    $config = $this->configFactory->get('ai_recipe_generator.settings');
    $system_instructions = $config->get('system_prompt');
    $context_message = "Active Site Context: " . $site_context;

    return new ChatInput([
      new ChatMessage('system', $system_instructions . ' ' . $context_message),
      new ChatMessage('user', $user_prompt),
    ]);
  }

  private function buildChatInputRecipeExplanationGeneration(string $yaml_content): ChatInput {
    $prompt = "Please explain the following Drupal Recipe YAML in simple, plain text. Do not output any code, just explain what it does. You may also reference parts of the code that need explanation in the response:\n\n" . $yaml_content;

    return new ChatInput([
      new ChatMessage('user', $prompt),
    ]);
  }

  private function buildChatInputRecipeRefineGeneration(string $yaml_content, string $user_feedback): ChatInput {
    $prompt = "The following is a Drupal Recipe YAML:\n\n" . $yaml_content . "\n\nPlease refine the YAML based on the user's feedback: " . $user_feedback . ". Ensure it remains valid and adheres to the schema. Also ensure that the user comments in the yaml and taken care of.";

    $site_context = $this->contextExtractor->getSiteContextMap();
    $config = $this->configFactory->get('ai_recipe_generator.settings');
    $system_instructions = $config->get('system_prompt');
    $context_message = "Active Site Context: " . $site_context;

    return new ChatInput([
      new ChatMessage('user', $prompt),
      new ChatMessage('system', $system_instructions . ' ' . $context_message),
    ]);
  }

  public function generateRecipe(string $user_prompt, string $provider_id, string $model_id): string {
    $input = $this->buildChatInputRecipeYamlGeneration($user_prompt);
    return YamlProcessor::normalize($this->queryLlm($provider_id, $model_id, $input));
  }

  public function explainRecipe(string $yaml_content, string $provider_id, string $model_id): string {
    $input = $this->buildChatInputRecipeExplanationGeneration($yaml_content);
    return $this->queryLlm($provider_id, $model_id, $input);
  }

  public function refineRecipe(string $yaml_content, string $user_feedback, string $provider_id, string $model_id): string {
    $input = $this->buildChatInputRecipeRefineGeneration($yaml_content, $user_feedback);
    return YamlProcessor::normalize($this->queryLlm($provider_id, $model_id, $input));
  }

  /**
   * THE CORE ENGINE: 
   * A single, unified function that handles all AI interactions.
   */
  private function queryLlm(string $provider_id, string $model_id, ChatInput $input): string {
    $provider = $this->aiProviderManager->createInstance($provider_id);
    $response = $provider->chat($input, $model_id);
    return $response->getNormalized()->getText();
  }
}

This setup ensures that whether a user is generating a recipe from scratch or iterating on a complex YAML file with custom comments, the active site context is always injected seamlessly and executed uniformly.

The Context Conundrum: Why JSON:API Wasn't the Answer

When you use AI to generate recipe.yml files, the generator is essentially flying blind unless you give it an architectural blueprint of the current Drupal site.

If the LLM doesn't know what already exists, it will try to generate recipes that recreate existing configuration entities (like a field_image or a blog content type). When you try to apply that recipe, it results in fatal errors and massive configuration collisions. The AI needed to know the state of the site, so I had to figure out the most efficient way to feed it that data.

My initial thought was to simply make an HTTP request using \Drupal::httpClient() to hit the local /jsonapi endpoint. JSON:API is great for exposing site data, right?

Yes, but for this specific use case, it was the wrong tool for the job.

The Pivot: Internal Services Over HTTP

Executing an external web request to a site’s own JSON:API endpoint while running code on that exact same environment adds unnecessary performance overhead. Furthermore, JSON:API is designed to return content (the actual data), whereas the AI only needed the architecture (the blueprints). Sending actual node data to the LLM would instantly bloat the payload and consume the entire context window.

Instead, I dropped the HTTP approach and utilized Drupal's internal services—specifically EntityTypeManager and ConfigFactory—to generate a highly optimized, lightweight structural map.

Here is how I structured the final data extraction to ensure recipe safety:

1. Performance & Payload Size: By fetching only machine names, bundles, and entity types, the resulting JSON payload is incredibly lightweight and easily fits within standard AI context windows.
2. Comprehensive Field Discovery: It is easy to just query field.field.node.*, but that ignores fields attached to taxonomy terms, media, or users. Instead, I queried field.storage.*. This captures all fields across the entire site, ensuring the AI can properly reuse existing field storage (a core Drupal best practice).
3. Content vs. Config Entities: Drupal Recipes frequently interact with configuration entities (like roles, menus, and block placements). I updated the queries to explicitly map out both content and config entities so the AI has a 360-degree view of the system.

The Implementation: getSiteContextMap()

To handle this, I introduced a new backend method called getSiteContextMap(). It uses those internal services to build out three main arrays: a clean list of node bundles, a unique array of all field storage machine names, and a multidimensional map of all system entities categorized by their group.

Here is a look at how that blueprint generation comes together in the code:

  /**
   * Generates a lightweight architectural blueprint of the Drupal site.
   *
   * @return string
   * A JSON-encoded string mapping the site's architecture.
   */
  public function getSiteContextMap(): string {
    $context = [
      'existing_content_types' => [],
      'existing_fields' => [],
      'all_entity_types' => [
        'content' => [],
        'config' => [],
      ],
    ];

    // 1. Fetch existing content types (node bundles).
    $node_types = $this->entityTypeManager->getStorage('node_type')->loadMultiple();
    $context['existing_content_types'] = array_keys($node_types);

    // 2. Fetch existing fields across all entity types via field storage.
    $field_storages = $this->entityTypeManager->getStorage('field_storage_config')->loadMultiple();
    foreach ($field_storages as $field) {
      $context['existing_fields'][] = $field->getName();
    }
    // Ensure the array is unique and re-indexed.
    $context['existing_fields'] = array_values(array_unique($context['existing_fields']));

    // 3. Map all entity types (Content and Config) and their respective bundles.
    $entity_types = $this->entityTypeManager->getDefinitions();
    foreach ($entity_types as $entity_type_id => $entity_type) {
      $group = $entity_type->getGroup();
      
      if (in_array($group, ['content', 'config'])) {
        $bundles = \Drupal::service('entity_type.bundle.info')->getBundleInfo($entity_type_id);
        $context['all_entity_types'][$group][$entity_type_id] = array_keys($bundles);
      }
    }

    return json_encode($context);
  }

By passing the output of this method into the system prompt (which connects perfectly to the RecipeGenerationService built earlier), the AI now has a perfect, zero-overhead map of the site it is generating code for. No more fatal errors, no more configuration collisions.

Last but not the least - documentation

We finally did some detailed documentation utilizing the fucntion comments and all the things that we were writing. This will be helpful for a handover and for understand and explaining what function we need. Check it out here: https://www.drupal.org/project/ai_recipe_generator/issues/3607975

So what I did was to generate a python script in the module folder, which scans the repo, then another one when generates a markdown file and a pdf file for export which can be suitable for our module.

You can checkout the detailed PDF here: https://git.drupalcode.org/project/ai_recipe_generator/-/blob/1.0.x/docs/Codebase_Architecture.pdf?ref_type=heads

Thanks a lot & catch you up next week!!!

Sometimes in software development, the best way forward is to burn it down and start over. Week 5 of my Google Summer of Code journey with Drupal was exactly that.

Official Tracker: Week 5 Tracker

The original version of the project simply wasn't working as intended. The foundation was shaky, and patching it was taking more time than fixing the root cause. So, I made the tough call to hit the reset button. I went back to the drawing board to recreate the entire thing—starting from the ground up with fresh HTML and form templates.

This time, the architecture is much more robust, allowing me to finally push through the proper updates. Here is a look at what was on the agenda for the rebuild:

UI & Layout Refinements

Getting the interface to feel native and clean was a huge priority this round.

• Sidebar Enhancements: Completely revamped the CSS for the sidebar to make it cleaner and more responsive.
• Page Alignment: Fixed the overarching structural alignment of the page so the layout doesn't break under different states.

Core Feature Updates

With the new templates in place, I started wiring up the core functionality that the AI module actually needs to be useful.

• The "Explain" Prompt: Added the new "Explain" prompt type to the system.
• Markdown Rendering: Ensured that the explain history parses proper markdown and renders it cleanly for the user.
• Zip Export & Import: Added the functionality to seamlessly export and import configurations via ZIP files.
• YAML Editor Swap: Decided to drop the old YAML preview and swap it out entirely with the much more robust yaml_editor module.

State & History Fixes

• Editable Sidebar: Fixed the "Edit Prompt" sidebar issue, ensuring the state is actually editable and saves correctly.
• History Management: Overhauled the history functionality to ensure it tracks and retrieves past prompts reliably.

Developer Note: A complete rewrite mid-project is always daunting, but the momentum it creates is undeniable. While Week 5 was all about laying this new groundwork and tackling these 8 core issues, the actual completion and polishing of many of these features spilled over into Week 6.

Stay tuned for the Week 6 update, where all of these rebuilt components finally cross the finish line!

This week was pretty cool for building the UI & getting started with that. Had defined the colour scheme, the master colours of the Drupal Page & then started building the Figma for the same. This process was more towards thought and what the user would feel good using, what will enable him / her to use better.

A cool page for good UI practices is: Synsation.

Official Week 4 Tracker: Week 4

Time to take a dive into depths of this week:

Take a look at Figma: UI Core

Design Principles

In a video I watched by Synsation, she explained that using familiar user interfaces is incredibly helpful for users. Think about it: almost every e-commerce website puts the shopping cart in the top-right corner. This intentional placement ensures that when a user lands on a new site, they don't feel completely overwhelmed trying to figure out where things are.

This UX design concept is known as Jakob's Law.

Read More: You can explore the full concept at Laws of UX: Jakob's Law.

Then I had to make the master colour scheme, as the theme has to be uniform and match the Drupal Theme. So took colours from the default Drupal Theme:

Dissecting an AI-Powered Chat Interface in Drupal

Tracing a request through a complex Drupal module can feel like unraveling a mystery. Recently, I mapped out the complete request/response flow of a custom AI Recipe Generator module. Instead of a monolithic block of code, the module is a great example of a decoupled, service-oriented architecture within Drupal.

The Anatomy of the Three-Pane Layout

The chat page is not a single file, but a composition of specialized parts orchestrated by a central controller.

When a request hits ai_recipe_generator.routing.yml, it is routed to the RecipeChatController. The controller's primary job is to assemble the page shell: it checks for a thread ID (generating one if necessary), builds the interactive form, prepares a starter preview panel, and loads recent threads.

The visual layout is handled by theme hooks defined in the .module file, splitting the UI into three distinct areas:

• Left Sidebar (recipe-chat-sidebar.html.twig): Displays dynamic thread navigation and links to sibling pages (Dashboard, Arena, Settings).
• Middle Chat Area (recipe-chat-form.html.twig): The interactive core containing the prompt input, provider/model controls, and message history.
• Right Preview Panel (ai-yaml-preview.html.twig): A shared YAML preview component featuring validation badges, dependency checks, a copy button, and an edit-apply workflow.

The Lifecycle of a User Request

The core interaction logic lives inside RecipeChatForm.php. Here is exactly what happens when a user clicks "Send":

1. State Management: The form reads the prompt, selected AI provider, and model, appending the user's message to the in-memory history.
2. AJAX Updates: If a user changes the AI provider, an AJAX callback (updateModelDropdown) instantly updates the model selector.
3. Generation: The form passes the baton to the AI generation service to build the prompt and fetch the response.
4. Validation & Logging: The generated YAML is validated, logged to the database alongside benchmark data, and the form storage is updated.
5. Rebuild: The page rebuilds to display the new chat bubble and the updated right-hand preview panel.

Secondary interactions follow similar targeted paths. Clicking "Retry" runs submitRetryForm to regenerate using the last known parameters, while "Apply Edits" from the preview panel triggers submitApplyEdits to re-validate and log a variant record.

Decoupling Logic: The Services Layer

If everything lived inside the form class, the module would be a maintenance nightmare. Instead, the ai_recipe_generator.services.yml file wires up highly specialized services.

• RecipeGenerationService: Manages AI provider connections, model selection, builds the system prompt, and calls the AI API.
• ContextExtractor: Gathers site context (like existing content types) and verifies YAML dependencies against installed modules.
• YamlServices: Centralizes all YAML syntax and recipe schema validation.
• RecipeStorageService: Handles database persistence, writing generation histories, storing edited variants, and fetching data for the sidebar.
• PreviewPanelBuilder: Transforms raw YAML into the interactive render array seen in the right-hand pane.
• BenchmarkDashboardService: Records benchmark data after every generation run for later analysis.

Beyond the Chat: The Module Ecosystem

The true benefit of this service-oriented architecture is code reusability. Because the heavy lifting is handled by services and shared Twig components, the module easily supports several sibling pages:

• RecipeGeneratorTestForm: A stripped-down, bare-bones generator. It reuses the provider/model pattern and YAML preview, but strips away the threaded chat UI.
• ArenaForm: A multi-model comparison tool. It leverages the same generation service but runs multiple models in a batch process, storing results in tempstore for side-by-side comparison.
• BenchmarkDashboardForm: The analytics wing. It skips generation entirely, instead reading the benchmark history to visualize performance.
• SettingsForm: A simple configuration page that stores the system prompt utilized by the generation service.

A Challenge

There is one challenge that I had faced, while making the history section, I was not sure whether or not it was being updated or created. I had to directly interact with the SQL section. A few commands which proved that data was being stored.

ddev drush sql-query "SELECT id, thread_id, prompt, yaml_valid FROM ai_recipe_generator_history;"

drush sql-cli

Now the yaml code was being generated, which often had some modules to install. I created the different sections - already installed, to be installed, invalid / hallucinated modules names. In order to do this had to verify whether the modules given by ai even actually exist.

How to Verify if a Drupal Module Exists: 5 Methods from the Community

I recently asked the community for the best ways to programmatically validate whether a Drupal module exists. I received a lot of great insights, tracking down everything from Packagist endpoints to Drupal core APIs.

Method 1: The Packagist Route

Suggested by: deadm3n

The initial idea was to hit the standard Packagist endpoint to check for the package JSON:

GET https://repo.packagist.org/p2/[vendor]/[package].json

One Obs: This didn't quite work as expected for Drupal-specific modules : (. But was a good approach.

Method 2: Project Browser UI

Suggested by: nixvcan

If you are looking for a visual or ecosystem-driven check, you can leverage the Project Browser module directly within Drupal, which lists available modules natively.

Method 3: Drupal's Composer Endpoint & Search APIs

Suggested by: cmlara

This approach focuses on basic Composer operations. You can look up a specific package if you know its full name using Drupal's dedicated Packagist endpoint:

GET https://www.drupal.org/files/packages/8/p2/drupal/field_updater.json

Searching the Endpoint

If you don't know the exact name, you can search the endpoint.

• Note: The standard Packagist spec typically uses q for queries, but Drupal currently uses s. Keep an eye on this, as it might change in the future.

GET https://packages.drupal.org/8/search.json?s=seo

Update Status XML: You can also use the Update Status XML, but it relies strictly on the Drupal.org machine name (which might not always match the Composer package name and excludes sub-modules). This might be a bit of bottleneck.

Method 4: Local Site vs. Global Ecosystem

Suggested by: sujal

We wanted to check if a module exists on the Drupal org not just if it there one our local!

If you just need to check your active site, the traditional Drupal approach works best. Read More

Method 5: The JSON:API Approach (My Method)

Discovered by: Myself

If you want to verify a module's existence globally on Drupal.org via code, you can query Drupal's official JSON:API for the project module content type:

GET https://www.drupal.org/jsonapi/node/project_module?filter[field_machine_name]=your_module_name

• Valid: The API returns a populated data array.
• Invalid: The data array returns empty.

Final Changes

Finally after completing all the changes, comes the tough part the linting and styling errors : ). Went though quite a few iterations after which the code was completed. That was the best relief - cspell, phpcs, php unit - all done!

Last part was pushing the code into gitlab. One of the tasks if you saw the tracker was learning about the Merge Train. So this time while pushing the code finally pushed it using it. You can read more about it in my other blog.

The Analogy: A Busy Airport Runway

You are managing the runway of a super busy airport (the Main Branch of Code). Pilots (Developers) are trying to land their planes (Merge Requests).

1. The Normal Merge (The Chaotic Runway)

The air traffic control looks at a plane 20 km away, sees that its engines work fine, and says: "You are cleared to land immediately."

The problem? Two minutes ago, another plane was cleared to land on that exact same runway. Because the controller didn't check what was currently happening on the ground, the two planes crash into each other.

• In Code: Your feature works fine alone. Another developer's feature works fine alone. But when you both merge directly into the main branch at the same time, they conflict and break the system.

There have been countless cases where developers have pushed code simultaneously has it has broken down 😅. So we sometimes in live website have different stages like - Development, QA, Staging & then finally - live production.

2. The Merge Train (The Pre-Flight Staging Queue)

Instead of letting planes land instantly, the airport sets up a strict, moving line on the taxiway.

Plane A gets in line. The tower runs a simulation: "If Plane A lands on the empty runway, is it safe?" Yes. Plane B gets in line right behind it. The tower runs a simulation: "Assuming Plane A lands safely, will Plane B be safe landing right behind it?" Plane C gets in line. The tower simulates: "If A lands, and then B lands, is it safe for C to land?"

The planes move down the track together like a train. They only get to touch the actual runway once the entire simulated sequence proves to be 100% safe.

This will help us so that nothing is in conflict. Super useful if there are many developers working on a project. In our case its just me, so might not be that useful.

3. Warnings vs. Errors (The Safety Inspector)

While the planes are in the Merge Train queue, a safety inspector walks by to check them.

An Error (Red Status): The inspector finds a broken wing on Plane B. Plane B is immediately kicked out of the line. The tower quickly reruns the simulation to see if Plane C can safely follow Plane A instead.

A Warning (Orange Status): The inspector notices Plane B has a scuffed coat of paint or a loose reading light above Seat 12B. It’s not perfect, but it is not going to cause a crash. The inspector notes it down, but lets the plane stay in the train to land.

4. Auto-Merge (The Valet Parking Attendant)

Imagine you are a pilot, and you are currently 50 miles away from the airport. You know your plane is in perfect condition, but there is a 30-minute line to get into the staging queue. You don't want to sit at the controls doing nothing while you wait for your turn.

You engage Auto-Merge. This is like handing the keys to a valet attendant. You can go sleep in the back of the plane. The valet will automatically steer your plane into the back of the Merge Train the exact second the gate opens for you, without you needing to touch a single button.

This is our entire story of Merging & Git. Untangling another vine in the open source jungle.

In the last week made quite a few structural changes that will help us. Have created the YAML extractor and parser which can extract the YAML component form any response of the LLM using Symfony to validate it. Made a Utility for this thereby making the code reusable.

Official Issue Tracker: Week 3 Tracker

Let me now give me glimpse for this.

Time to Dive Deep into this

YAML Validator & Extractor

Created a Utility folder under src and created a file named Yaml Processor. The concept of this file was simple, when you get an output from LLM, from whichever Service or Function you pull this from this will extract the YAML and give it to you.

Here it uses this : use Drupal\Component\Serialization\Yaml

This under the hood uses Symfony which helps to validate and extraction. Symfony is the underlying PHP framework that powers modern Drupal ( this is just one of the usecase)

<?php

namespace Drupal\ai_recipe_generator\Utility;

use Drupal\Component\Serialization\Yaml;

/**
 * Utility class to parse and extract YAML from AI responses.
 */
class YamlProcessor {

  /**
   * Cleans a response down to YAML text when possible.
   *
   * @param string $response
   *   The raw model response.
   *
   * @return string
   *   A normalized YAML string or the response with code fences removed.
   */
  public static function normalize(string $response): string {
    $parsed = self::extractAndParse($response);

    if (is_array($parsed)) {
      return trim(Yaml::encode($parsed));
    }

    $cleaned = preg_replace('/```(?:yaml|yml)?\s*|```/i', '', $response) ?? $response;
    return trim($cleaned);
  }

  /**
   * Attempts to extract and validate YAML from a given string.
   *
   * @param string $response
   *   The raw string response.
   *
   * @return array|null
   *   The parsed YAML as an array, or null if no valid YAML could be extracted.
   */
  public static function extractAndParse(string $response): ?array {
    // First try parsing the entire response as YAML.
    try {
      $parsed = Yaml::decode($response);

      if (is_array($parsed)) {
        return $parsed;
      }
    }
    catch (\Exception $e) {
      // Not valid YAML, continue with extraction.
    }

    // Extract YAML from markdown code blocks.
    $pattern = '/```(?:yaml|yml)?\s*(.*?)```/is';

    if (preg_match($pattern, $response, $matches)) {
      $yaml = trim($matches[1]);

      try {
        $parsed = Yaml::decode($yaml);

        if (is_array($parsed)) {
          return $parsed;
        }
      }
      catch (\Exception $e) {
        return NULL;
      }
    }

    return NULL;
  }

}

Reusable YAML Previewer

If you have seen my previous blog, the older YAML previewers they were not upto the mark. So improved that with having better parsers and lines. What I used for this was a template, using a html.twig format which helped to render properly anywhere, anyhow!

This is slightly difficult to think and then implement (tedious slightly) but since highly reusable, highly useful!

{#
/**
 * @file
 * Template for the fluid YAML previewer component with line numbers.
 */
#}
<div class="ai-yaml-preview-container" {{ attributes }}>
  <div class="ai-yaml-preview-header">
    <span class="ai-yaml-preview-title">{{ title|default('YAML Output Preview') }}</span>
    
    <button class="ai-yaml-copy-btn" onclick="
      const container = this.closest('.ai-yaml-preview-container');
      const code = container.querySelector('code').innerText;
      navigator.clipboard.writeText(code);
      const originalText = this.innerText;
      this.innerText = 'Copied!';
      setTimeout(() => this.innerText = originalText, 2000);
    ">Copy YAML</button>
  </div>
  
  <div class="ai-yaml-preview-body">
    {# This empty div will be filled with numbers by the JS below #}
    <div class="ai-yaml-line-numbers" aria-hidden="true"></div>
    
    <pre class="ai-yaml-preview-content"><code class="language-yaml">{{ yaml_string }}</code></pre>
  </div>
</div>

{# Inline script to generate line numbers based on the code length #}
<script>
  (function() {
    // Find all preview containers on the page
    const containers = document.querySelectorAll('.ai-yaml-preview-container');
    
    containers.forEach(container => {
      const codeBlock = container.querySelector('code');
      const linesContainer = container.querySelector('.ai-yaml-line-numbers');
      
      // Only process if it hasn't been filled yet
      if (codeBlock && linesContainer && linesContainer.innerHTML === '') {
        // Split by newline to get total lines
        const lines = codeBlock.innerText.split('\n');
        
        // Handle the case where the AI leaves a trailing empty line at the end
        const lineCount = lines[lines.length - 1] === '' ? lines.length - 1 : lines.length;
        
        let numbersHTML = '';
        for (let i = 1; i <= Math.max(1, lineCount); i++) {
          numbersHTML += i + '<br>';
        }
        linesContainer.innerHTML = numbersHTML;
      }
    });
  })();
</script>

Code Reduction

Let's understand the problem, we had 3 files for calling the LLM models & providers. All of them had separate functions. So if I ever wanted to change anything, I would have to change in all the three files : (

So we changed the calling part. for 2 (ArenaService & RecipeGenerationService) of them as they were the same replicas the third one at BenchmarkDashboardService was a different one. Clubbing them was fairly simple, just had to change the function calls.

Started fixing the Pipeline

Did the cspell checking and then the phpcs checking which was initially failing but then started fixing the same. For fixing the cspell introduced a file called: .cspell.json. This needed to have all the words in the document which I wanted to exclude form the checking.

Will write a separate blog on testing!

{
    "version": "0.2",
    "language": "en",
    "words": [
        "ai_recipe_generator",
        "chartjs",
        "crosshairs",
        "dalal",
        "fontawesome",
        "hrishikesh",
        "llm",
        "llms",
        "multichat",
        "onclick",
        "Starshot",
        "tempstore",
        "unconfigured",  
        "xaxis",
        "xmark",
        "yaml",
        "yaxis"
    ],
    "ignorePaths": [
        "vendor/**",
        "node_modules/**",
        "*.min.js",
        "*.min.css"
    ]
}

Thank you & catch you up next time!

If you are developing custom modules for Drupal 11, you already know that passing Drupal’s strict GitLab CI pipeline is a formidable challenge. Between CI pipelines failing over a single misspelled variable, coding standard violations, and Kernel tests failing to find databases, local environment setup is notoriously frustrating.

Setting up a modern Drupal 11 testing and CI environment locally using DDEV doesn't have to be a nightmare of version conflicts and obscure database errors. By understanding how to leverage CSpell, utilize Drupal's built-in formatting tools, and bridge PHPUnit to your Docker containers, you can build a bulletproof local pipeline that perfectly mirrors Drupal's strict GitLab CI.

Surviving CSpell (The Code Spell Checker)

One of the most common reasons a Drupal pipeline fails is CSpell. It scans your code—including YAML files, comments, and variable names—for spelling errors. The problem? It frequently flags technical acronyms, tool names (like ddev), and specific machine names as "misspelled."

Because DDEV includes Node.js, you can run CSpell locally via npx without installing it globally.

Step 1: Run the Spell Checker

ddev exec npx cspell "web/modules/custom/your_module/**/*"

# In some cases, even without typing "ddev exec npx" the code will work

Step 2: Creating CSPELL file

When CSpell flags a legitimate technical word, do not change your code. Instead, create a .cspell.json file in the absolute root of your project:

{
  "version": "0.2",
  "language": "en",
  "ignorePaths": [
    "vendor/",
    "node_modules/",
    "web/core/"
  ],
  "words": [
    "ddev",
    "phpcbf",
    "phpcs",
    "phpunit",
    "yourcustomword"
  ]
}

Step 3: Keep Your Dictionary Organized

Sorting your .cspell.json file alphabetically keeps it clean and makes it much easier to manage as your module grows. You can do this quickly without manual sorting:

Method A: The Quick VS Code Way (My preferred way)

1). Open .cspell.json in VS Code.

2). Select only the lines containing the words inside the words array.

3). Open the Command Palette (Ctrl + Shift + P or Cmd + Shift + P).

4). Type Sort Lines Ascending and press Enter. Add back any missing commas if the trailing word shifted.

Method B: The Command Line Way (Using jq) If you want to sort the entire JSON file perfectly via the terminal, use jq. Install it inside your WSL terminal (sudo apt install jq), then run:

This targets the words array, sorts it, and overwrites the file cleanly without breaking the JSON structure.

jq '.words |= sort' .cspell.json > temp.json && mv temp.json .cspell.json

Mastering PHP CodeSniffer (PHPCS) & Beautifier

Drupal has incredibly strict coding standards. A single missing space or incorrect docblock will fail the CI pipeline. To automate this, we need to install Drupal's core development tools.

Step 1: Install Drupal Core Dev Tools (The Right Way)

Before you can sniff or auto-format code, you need Drupal's development dependencies. However, Composer often blocks this due to historical security advisories in locked packages.

To fix this, edit your project root composer.json (not the core or module file) to allow the installation, and explicitly declare your Drupal version to prevent Composer from downloading outdated Drupal 8/9 packages. Add this audit configuration to bypass the locked security warnings:

"config": {
  "allow-plugins": {
    "composer/installers": true,
    "drupal/core-composer-scaffold": true,
    "drupal/core-project-message": true
  },
  "audit": {
    "block-insecure": false
  }
}

(Note: You may also need to loosen constraints if packages like drupal/coder conflict, e.g., "drupal/coder": "^8.3.30 || ^9.0").

Run the require command with your exact Drupal core version (e.g., 11.3.11):

composer require --dev "drupal/core-dev:11.3.11" --with-all-dependencies

Step 2: Auto-Fix with PHPCBF

Always run the PHP Code Beautifier and Fixer (PHPCBF) first. It acts like an auto-formatter, automatically correcting indentation, spacing, array syntax, and missing docblocks.

Run this command to safely auto-fix your entire custom module:

ddev exec ./vendor/bin/phpcbf --standard=Drupal,DrupalPractice --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md,yml web/modules/custom/your_module

Step 3: Manually Check with PHPCS

After the auto-fixer runs, use PHP CodeSniffer (PHPCS) to catch logical formatting errors that a machine can't safely fix (e.g., variables that are declared but never used, or missing parameter descriptions).

ddev exec ./vendor/bin/phpcs --standard=Drupal,DrupalPractice --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md,yml web/modules/custom/your_module

Conquering PHPUnit and the Database Dilemma

Unlike simple Unit tests, Drupal Kernel and Functional tests require a fully operational database to build temporary, miniaturized versions of your site. If you are using DDEV and executing commands from your host machine (like WSL or macOS terminal), PHPUnit will fail because it cannot see inside the DDEV database container.

Since we already installed the drupal/core-dev dependencies in Phase 2, here is how to bridge the connection.

Step 1: Configure phpunit.xml for DDEV

PHPUnit needs to know how to talk to DDEV. Copy Drupal's phpunit.xml.dist to create a phpunit.xml file in your project root, and ensure the variables under the block look exactly like this

<php>
    <ini name="error_reporting" value="32767" />
    <ini name="memory_limit" value="-1" />
    <env name="SIMPLETESTBASEURL" value="https://your-project.ddev.site" force="true" />
    <env name="SIMPLETEST_DB" value="mysql://db:db@db/db" />
    <env name="BROWSERTESTOUTPUTBASE_URL" value="https://your-project.ddev.site" />
  </php>

Why this matters: mysql://db:db@db/db is the default internal DDEV database credential string. It tells PHPUnit to route directly to the active Docker container.

Step 2: Run the Tests Inside DDEV

If you run ./vendor/bin/phpunit from your standard terminal, it will fail with a socket error. You must tell DDEV to execute the command inside the web container.

ddev exec ./vendor/bin/phpunit ./web/modules/custom/your_module/tests

Pro-Tip for Kernel Tests: If your test throws a ServiceNotFoundException, it means your custom module depends on another module that isn't loaded in the test environment. Ensure you declare all dependencies in your test class:

protected static $modules = ['yourmodule', 'dependentmodule'];

This is all, catch you up next time!

Drupal has a really interesting way for databases.

So rather than writing the direct SQL statements, which would be tedious and boring, it uses a .install file to handle this. This translates into a proper query that we are going to use, which is useful for storing structured information.

Let us go through this with help of an example.

<?php

/**
 * @file
 * Install, update and uninstall functions for the AI Recipe Generator module.
 */

/**
 * Implements hook_schema().
 */
function ai_recipe_generator_schema() {
  $schema['ai_recipe_generator_benchmarks'] = [
    'description' => 'Stores historical benchmark metrics for AI providers.',
    'fields' => [
      'id' => [
        'type' => 'serial',
        'not null' => TRUE,
        'description' => 'Primary Key.',
      ],
      'provider' => [
        'type' => 'varchar_ascii',
        'length' => 64,
        'not null' => TRUE,
        'default' => '',
      ],
      'model' => [
        'type' => 'varchar_ascii',
        'length' => 64,
        'not null' => TRUE,
        'default' => '',
      ],
      'prompt' => [
        'type' => 'text',
        'size' => 'big',
        'not null' => TRUE,
        'description' => 'The user prompt submitted to the AI.',
      ],
      'response' => [
        'type' => 'text',
        'size' => 'big',
        'not null' => TRUE,
        'description' => 'The raw generated text/YAML from the LLM.',
      ],
      'latency' => [
        'type' => 'int',
        'not null' => TRUE,
        'description' => 'Total response time in milliseconds.',
      ],
      'yaml_valid' => [
        'type' => 'int',
        'size' => 'tiny',
        'not null' => TRUE,
        'default' => 0,
        'description' => '1 if clean or recovered via sanitizer, 0 if completely unparsable.',
      ],
      'schema_compliant' => [
        'type' => 'int',
        'size' => 'tiny',
        'not null' => TRUE,
        'default' => 0,
        'description' => '1 if all required recipe keys are present.',
      ],
      'timestamp' => [
        'type' => 'int',
        'not null' => TRUE,
        'default' => 0,
      ],
    ],
    'primary key' => ['id'],
    'indexes' => [
      'provider_model' => ['provider', 'model'],
    ],
  ];

  return $schema;
}

Here as you can see the name is ai_recipe_generator.install (i.e. name of your module)

First let's understand what is a hook_schema().

hook_schema() is a specific function that allows a module to define its own custom database tables. It serves as a blueprint or map that tells Drupal exactly how to structure data storage for that module.

Now the next thing that would come to your mind is - What does this do anyways?

The ORM

It acts like a ORM - Object Relational Mapper. Let's us take a step back and understand what an ORM is.

The Object-Oriented World (Your Code): Written in languages like PHP, Python, or JavaScript, where data is treated as interconnected objects with properties and methods.

The Relational World (Your Database): Written in SQL (MySQL, PostgreSQL), where data is stored in rigid, flat tables consisting of rows and columns.

So to simply put

Without an ORM: Manually write the SQL queries

With an ORM: System writes SQL queries for you.

The ORM helps you write queries lightning fast & good ORMs have security out of the box. The only disadvantage however is that they add another layer of abstraction which can sometimes slow down the speed (in case of a bloated SQL).

Coming back to the .install file.

We can say that

A Recipe class maps to recipe table

$recipe->title maps to a title column

Also helps to decide the NOT NULL fields & Primark Keys.

Further this can automatically handles table creation + deletion on installing & uninstalling. Simple isn't it?

Some good toknowinfo

Standard Documentation Name: hook_install() What you write for your module: ai_recipe_generator_install() When Drupal runs it: Runs after the database table is created, perfect for inserting default data.

Standard Documentation Name: hook_uninstall() What you write for your module: ai_recipe_generator_uninstall() When Drupal runs it: Runs when removing the module, perfect for clearing out configuration settings.

Standard Documentation Name: hook_update_N() What you write for your module: ai_recipe_generator_update_10001() When Drupal runs it: Runs when a developer executes database updates on a live site.

The different types of keys in schemas.

Table-level keys

• description: A short explanation of what the table stores and its purpose.
• fields: The list of columns that make up the table.
• primary key: The column(s) used to uniquely identify each record.
• unique keys: The column combinations that must contain unique values.
• foreign keys: The relationships between this table and other tables.
• indexes: The columns that are indexed to improve query performance.

Field specification keys

• description: A brief explanation of what the field represents.
• type: The kind of data the field stores, such as text or numbers.
• mysql_type: A custom data type definition specifically for MySQL.
• pgsql_type: A custom data type definition specifically for PostgreSQL.
• sqlite_type: A custom data type definition specifically for SQLite.
• serialize: Indicates whether the field value is stored in serialized format.
• size: Defines the expected size range of the data stored in the field.
• not null: Specifies whether the field is required and cannot be empty.
• default: The value automatically assigned when none is provided.
• length: The maximum number of characters allowed in text fields.
• unsigned: Restricts numeric values to non-negative numbers.
• precision: The total number of digits allowed in a numeric value.
• scale: The number of digits allowed after the decimal point.
• binary: Enables case-sensitive storage and comparison for text fields.

Foreign key specification keys

• table: The name of the table being referenced.
• columns: The mapping between local columns and referenced columns.

Sources

Drupal Schema

Functions in Drupal Schema

This week we have built two things: LLM Benchmarking Dashboard & LLM Arena to show you which ones are the best. Both of these will be super useful while building our final product.

The Offical Issue Tracker: Week 2 Issues Tackled Let me give you a glipmse of what our output will look like.

The Benchmarking Dashboard

In order to capture the true essence of which model performs the best in the long run, had made a LLM benchmarking dashboard. Someone just by looking at charts can capture which model is most suitable for their usecase.

Metrics that provided the overall picture

1). The Top Banner: It had the total runs so far, along with the average response time and the average accuracy for the recipe generated.

2). The Visuals: Any dashboard is incomplete without a good visual. The first graph which shows the latency for the previous runs mapped across models is useful for finding the trend for model hits. The second graph is for using a bar graph for visualising the model avg. latency to compare which model is the faster as compared to others. Used the Chart module for the same.

3). Key Metric Table: This is the detailed table for per prompt summary. It covers: the provider, the model, the speed, whether the YAML is valid or not, whether the Schema proper or not as per Drupal Symfony, & finally tells us about the accuracy along with timestamps.

What is useful in this is that you can filter it along with sort the columns in ascending or descending order. Is if further colour coded so that you can quickly view the page at a glance.

Things I used to build this:

• Chart.js / Drupal Chart Module: To render the responsive, interactive graphs.
• Custom Database Schema (.install): To reliably save and query the historical benchmarking data.
• Drupal AJAX API: To ensure the table filters and dynamic sorting update seamlessly.
• Font Awesome Library: To have cool icons in the dashboard

The LLM Arena

This was particularly fun to build as this was for comparing the different responses. You get to type the custom prompt and then fire it across all the different models and providers.

You can have all the different models & providers, there is NO LIMIT!!

Further these is also an option to store the responses in the database so that they reflected in the schema. There is also a delete button for the same. If you want to remove some model-provider. Further you will see a very familiar screen that, while firing the prompts, it will look like new module install screen, this is because of the Batch API Screen.

Sources I used:

1. AJAX API: Model - Provider dropdown
2. Batch API: For firing all the prompts together
3. Font Awesome Icons: For the icons there

Laying out the Structure

Just like a good Drupal Practice (have to mention), have used AI to generate the image above.

1. Client (User Browser) Layer

Handles the user interface and visual presentation.

• User (Arena/Dashboard Interface): Renders the comparison forms, interactive data tables, and metrics dashboards.

• Frontend Components:

• JavaScript: Uses Chart.js to render interactive line and bar charts for model latency trends.

• Icons: Integrates Font Awesome for immediate visual cues (success/failure statuses).

• CSS: Uses css/arena.css and css/dashboard.css via .libraries.yml for custom, polished layouts.

• Client-Server Communication:

• AJAX API: Controls non-blocking form updates, dynamic filtering, and column sorting without page reloads.

• Batch API (Client-Side): Drives the real-time progress bar (similar to the module installation screen) during execution.

2. Drupal Application Logic Layer

The PHP backend that processes requests and orchestrates module logic.

• Form API (ArenaForm.php, BenchmarkDashboardForm.php): Handles form submissions and handles backend execution triggers.
• Services Layer (ArenaService.php, BenchmarkDashboardService.php): Houses decoupled, reusable core logic registered via ai_recipe_generator.services.yml.
• API Integration Engine:
• Drupal Batch API: Splits concurrent LLM requests into isolated chunks to prevent gateway timeouts and server lockups.
• Drupal AJAX API: Manages seamless, lightweight data passing between backend services and frontend components.

3. Data & External Integrations Layer

Manages persistent storage and outbound network requests.

• Local Database (.install): Uses a custom schema defined in the install file to save historical run stats, latency, timestamps, and schema validation flags.
• External LLM APIs: Handles outbound calls to external models (OpenAI, Anthropic, Gemini). Isolated by the Batch API so a timeout on one provider doesn't crash the session.

Thanks a lot for reading!!

Over the first week my focus was on establishing a proper base for the project. This was particularly fun as you can see your project come to life. These are some other chapters of the journal that you should definitely read!

I created a project: Creating a Module Project on Drupal (NO CODE) (With BONUS Section)

I learnt about PIRLS - Drupal's Core .yml files

Before you proceed any further, you should have a drupal project set up. If not, you can check it out here: Installing Drupal

Have added a bit more changes too, you can check it our here: Week 1 Official Tracker

Let's zoom out and see what we have built. UI might not be that great yet but that was not the focus of the first week.

You should clone the basic repo of the module and paste it in: web/modules/custom/ai_recipe_generator.

You might need to create this folder & add all the files. We use custom as we haven't made a deployment of the project yet. So once I did this I made. Now I have added ai_recipe_generator.info.yml, ai_recipe_generator_services.yml, ai_recipe_generator.routing.yml. I have made a blog on these files and what do these mean, you can check that out too.

I then created 2 things in src folder - Form & Services.

So we have two pages as you saw above. Let's understand the routing or the file urls

ai_recipe_generator.test_form:
  path: '/admin/config/development/ai-recipe-test'
  defaults:
    _form: '\Drupal\ai_recipe_generator\Form\RecipeGeneratorTestForm'
    _title: 'AI Recipe Generator (Test UI)'
  requirements:
    _permission: 'administer site configuration'

ai_recipe_generator.settings:
  path: '/admin/config/ai-recipe/settings'
  defaults:
    _form: '\Drupal\ai_recipe_generator\Form\SettingsForm'
    _title: 'AI Recipe Generator Settings'
  requirements:
    _permission: 'administer site configuration'

Each entry has the following

1 The URL Path

2 The Form File which it should render

3 The title of the Page

4 Permission Requirements

We have dependecies as well. This module as of now depends on the AI Module, Gemini Provider Module as well as the Key Module for managing all the keys. You have to install and enable all these modules for the AI Recipe Generator to function. This is actually cool as we are using the Drupal Ecosystem to do our tasks.

Phase 1: The Setup (Settings Form)

Before a user can generate a recipe, an administrator sets the rules.

1. Setting the Ground Rules: An admin visits the "AI Recipe Generator Settings" form and enters the System Instructions (e.g., "You are a senior Drupal developer...").
2. Saving to the Database: When the admin clicks "Save configuration," Drupal uses its configuration service (@config.factory) to safely store these instructions in the database for later use.

Phase 2: The User Request (Test UI Form)

This is where the actual generation happens.

3. User Input: A user opens the "AI Recipe Generator (Test UI)" form. They select their preferred AI Provider (like Gemini) and type exactly what they want to build into the Recipe Prompt box.
4. Triggering the AJAX Call: The user clicks the Generate Recipe button. Instead of reloading the whole webpage, the browser sends a quiet, background message (an AJAX Request) to the Drupal server containing the user's prompt and their chosen AI provider.

Phase 3: The Backend Brain (Drupal Services)

Once Drupal receives the AJAX request, it hands the work over to the custom services defined in your .yml file.

5. Gathering the Pieces: The main service (RecipeGenerationService) goes to work collecting three crucial pieces of information:

• The Rules: It pulls the saved "System Instructions" using @config.factory.
• The Context: It asks the ContextExtractor service to pull any relevant background information about your specific Drupal site.
• The Request: It takes the user's specific "Recipe Prompt" from the AJAX call.

6. Talking to the AI: The RecipeGenerationService combines the rules, the context, and the user's request into one massive prompt. It then uses the @ai.provider service to send this combined package over the internet to the external AI (e.g., Gemini).

Phase 4: The Result (AJAX Response)

7. Receiving the Recipe: The external AI processes the prompt, generates the Starshot Recipe YAML file, and sends it back to your Drupal server.
8. Updating the Screen: Drupal packages this generated recipe into an AJAX Response and sends it back to the user's browser. The browser reads this response and instantly displays the new recipe on the screen, completing the process without ever forcing the user to refresh the page.

How I set up a Drupal Project

This is the bare minimum as it allows us to TEST & SEE the progress in real time. But setting this up is often challenging for many of us. Especially venturing into first time integrations. I have broken it down step by step so that it becomes easier for you.

You might but AI for the steps but trust me it may guide you wrong 😭

You will need ddev & git installed on your computer

Step 1: Creating a project

Just be this step we can set up a sample project without any configurations. Here intead of drupal_sandbox, your name can be anything. Literally anything!

composer create-project drupal/recommended-project drupal_sandbox
cd drupal_sandbox

Step 2: Making the ddev config file

This file is responsible for handling your environment under the hood. Press ENTER after running this command. It takes care of the following:

1) The Engine Type (type): Tells the system what framework you are using (like Drupal 11). DDEV instantly optimizes the Nginx web server and PHP settings specifically for that framework's unique code structure.

2) The Front Door (docroot): Defines the exact folder that is exposed to the internet (like the web/ folder). It acts as a security barrier, blocking public access to your raw backend code, configuration files, and third-party dependencies.

3) The Toolbox (php_version, db_type): Locks in the exact version numbers for your programming language, database engine, and runtime tools so your local server perfectly matches your production server.

4) The Autopilot (hooks): Contains a list of custom terminal commands that you want executed automatically at specific moments—like running database migrations or flushing caches right after the containers turn on.

ddev config

Step 3: Start it

Now you should run ddev start. Chances are it might throw an error :(

ddev start

This typically happens due to port mapping issue. Now a quick fix around this is that you can change the port mapping in the .ddev/config.yml file at the line number 47 & 48. Update it with these lines and then do the restart.

router_http_port: 8080  
router_https_port: 8443

ddev restart

Step 4: Specifications Selection

Select Save & Continue for most of it. Now when prompted for the email, username & password. Type something that you remember. I usually type: admin (for username & password)

Congrats!

You have finally installed Drupal! Now you can start contributing here as well.

Say you are a restraunt owner, starting you the amazing food chain called - "More Food, Less Money". You attract a lot of hungry customers who want quality food. So to start and scale up, you have to do the following things

1. Get your Business License.

2. Decide on the Host & Menu.

3. Bing new staff & Kitchen Appliances

4. Set up good Decor & Ambiance. Ik you love an asthetic place ;)

5. Establish for a keycard system for security.

Here let's call it ai_chef the module

The Business Liscence - [module].info.yml

Before you can open, you need a license. This tells the city (Drupal) your restaurant's name, its description, and what basic utilities (dependencies) it requires to function. Without this, the city doesn't even know your restaurant exists.

name: 'AI Vegetarian Recipe Generator'
type: module
description: 'Integrates with the Gemini API to generate custom vegetarian recipes.'
core_version_requirement: ^10 || ^11
package: Custom AI
dependencies:
  - drupal:key

The Host & Menu - [module].routing.yml

When a customer asks for a table or a specific dish (a URL request like /about-us), the host uses this file to direct them to the exact right table or kitchen station (the PHP Controller) that will serve them.

ai_chef.menu_generator:
  path: '/admin/kitchen/generate-recipe'
  defaults:
    _controller: '\Drupal\ai_chef\Controller\RecipeController::buildMenu'
    _title: 'Generate New Recipes'
  requirements:
    _permission: 'generate veg recipes'

The Kitchen Staff & Appliances - [module].services.yml

You don't buy a new oven every time someone orders a pizza. This file registers your heavy-duty, reusable tools (PHP classes) and connects them to the main power grid (Dependency Injection). It ensures your module can efficiently share resources with the rest of Drupal.

services:
  ai_chef.gemini_service:
    class: Drupal\ai_chef\Service\GeminiRecipeService
    arguments: ['@http_client', '@config.factory']

The Decor & Ambiance - [module].libraries.yml

This manages your paint colors, lighting, and music (CSS and JavaScript). You don't want to pay for a mariachi band in the quiet dining room; this file lets you define groups of styles/scripts and load them only on the specific pages that need them.

kitchen_ambiance:
  version: 1.0
  css:
    theme:
      css/restaurant-theme.css: {}
  js:
    js/gemini-integration.js: {}
  dependencies:
    - core/drupal
    - core/jquery

The Keycard System - [module].permissions.yml

This dictates security. It defines the specific digital locks on your doors (e.g., "Access the VIP lounge" or "Edit the main menu") so the site administrator can hand out the right keycards to specific staff roles.

generate veg recipes:
  title: 'Generate Vegetarian Recipes'
  description: 'Allows staff to use the Gemini API to create new menu items.'
  restrict access: true

A cool way to remember this?

You struggle to remember all these things as this is a lot of juggling for you, :(

But don't worry, your best friend suggests you something to help you:

To remember the five main .yml files, think of stringing together a necklace of PIRLS (Pearls).

P - Permissions ([module].permissions.yml)

I - Info ([module].info.yml)

R - Routing ([module].routing.yml)

L - Libraries ([module].libraries.yml)

S - Services ([module].services.yml)

Some sources

Main Module Development Guide

Understanding info.yml

Routing & Controllers (routing.yml)

Services & Dependency Injection (services.yml)

Asset Management (libraries.yml)

So previously we had set up a project. Now we are going to initialise the git repo and add a few changes. First if you have created your project, you can move on into the Version Control section. This will contain instructions of what we should do further.

This was my link: Version Control

mkdir ai_recipe_generator

cd ai_recipe_generator

git init

git checkout -b 1.0.x

echo "AI Recipe Generator" > README.txt

git add README.txt

git commit -m "Initial commit."

git remote add origin git@git.drupal.org:project/ai_recipe_generator.git

git push origin 1.0.x

They are the explicit instructions of what we are going to do.

Copying without understanding is useless. Let's go through each step one by one.

Post this we had committed 3 more files of out own, which are equally crucial for the module development.

1 ai_recipe_generator.module.info

2 composer.json

3 .gitignore

Resources

1. Module Creation & .info.yml Documentation Creating Custom Modules (Main Hub): This is the central landing page for all module development tutorials in modern Drupal, covering everything from routing to creating custom blocks.

Defining the .info.yml File: This page provides the exact specifications, required properties, and core version requirement syntax for your module's metadata.

2. Composer Documentation for Modules Adding a composer.json File to a Module: This explains exactly why and how to add a composer.json file to your custom or contributed module, including the composer init steps specifically tailored for Drupal package types.

name: AI Recipe Generator
description: Creates recipes using AI.
package: AI

type: module
core_version_requirement: ^10.5 || ^11.2

dependencies:
  - ai:ai

{
    "name": "drupal/ai_recipe_generator",
    "description": "Creates recipes using AI.",
    "type": "drupal-module",
    "license": "GPL-2.0-or-later",
    "authors": [
        {
            "name": "Hrishikesh Dalal",
            "email": "204620-hrishikesh-dalal@users.noreply.drupalcode.org"
        }
    ],
    "require": {}
}

Somewhere where I struggled and made mistakes

If you have seen the video, you would know I had made a mistake initializing the git repo 😅. I made a commit to the main brand before setting up the 1.0.x which is crucial for creating forks and deployments. Well it sucked but it was a great source of learning.

Understanding the Concept of Remote in Git

Think of Git Remotes as a Cloud Backup or a Shared Office.

Imagine you are writing a book on your own private desk at home (Local Repository). You can write, delete, and organize pages however you want.

However, your publisher and co-authors are in a different building. To show them your work, you have a Shared Drafting Table (Remote Repository) in their office.

1. A "Remote": It's just a bookmark or a "saved contact" in your computer's address book that tells Git exactly where that Shared Table is located on the internet.

2. Origin: This is just the default nickname for that Shared Table. (But you could call it anything, backup, publish etc)

Managing Remotes: The Commands

Sometimes you need to change where your code is going (e.g., commit to a different fork or repository).

1. Check your current remotes

Before changing anything, see where your project is currently "talking" to.

The -v stands for "verbose." It shows you the URLs for fetching (downloading) and pushing (uploading).

git remote -v

2. Change a remote's URL

If the server location changes, but you want to keep the same nickname (origin), use this command:

git remote set-url origin https://git.drupalcode.org/issue/ai_recipe_generator-3592994.git

When to use: Use this if you accidentally typed the wrong URL during setup or if the project moved to a new server.

3. Add a second remote

You can have more than one! You might have one for a private backup and one for the public Drupal project.

git remote add backup https://git.drupalcode.org/issue/ai_recipe_generator-000001.git

4. Rename a remote

If you don't like the name origin and want to call it something else: (here drupal_server)

git remote rename origin drupal_server

5. Remove a remote

If you want to cut ties with a specific server:

git remote remove backup

Pro-Tip: If you ever get an error saying "Remote origin already exists," it means your project is already linked to a server. Use set-url to update it instead of add.

Eventually....

So after taking a short detour, we finally pushed our initial code to gitlab! 🎉🎉

Welcome to my GSoC journey where in I am going to take you through an adventure of events. This blog is for the Level 1. Or rather I should saying learning about how to "make the dish". We are going to create our very own Drupal Module Project!!

I will also append a Youtube link for the same if it does suit you better. Lets get into it!

Step 1: Understanding what all types of Projects you can create

When you head over to this site for project creation - Drupal Project Create. You will have 4 options.

Drupal offers a few different project types:

1. Module project: Contains PHP code that extends Drupal or adds new features.

2. Theme project: Changes the look and feel of a Drupal site.

3. General project: Contains code, but isn't a module, theme, or specific type.

4. Community project: Non-code projects used to manage groups or camps.

Since our aim is to build an AI Recipe Generator that adds brand-new functionality to the site, selecting the Module project was the clear choice.

Step 2: Have Git on your computer

The absolute bare minimum as all the code changes everything should be done by this. But if you reading this and are a techie, you must already be having git : )

Step 3: Creating a project

Now when you go over this link: Project Creation, you will have a ton of options. Let us go through each one of them one by one.

• Drupal core: The foundational software that runs the entire Drupal platform.
• Distribution project: An all-in-one starter kit that bundles Drupal with pre-selected features to quickly launch a specific type of website.
• Community project: An organizational space for managing Drupal groups, events, and people rather than website code.
• General project: A catch-all category for miscellaneous code, tools, and libraries that don't fit into the standard module or theme categories.
• Module project: A functional plugin that adds new features or changes how your website works.
• Theme project: The design package that controls the colors, layout, and overall visual appearance of your website.
• Theme Engine project: The behind-the-scenes system that translates your theme's visual design into something the Drupal platform can understand.
• Translation project: An outdated archive for language translations, which are now managed on a separate, dedicated website.

Step 4: The Nitty Gritties

Now when you go to the next page, there is this huge form that you need to fill. Let me take you across each filed one by one.

The Basic Identity

Name: AI Recipe Generator

• What it is: The project's human-readable title.
• Why I chose it: It clearly tells users exactly what the tool does right away.

Short name: ai_recipe_generator

• What it is: The machine-readable system name used for URLs and codebases.
• Why I chose it: It matches the readable name using standard Drupal convention (lowercase and underscores) for consistency.

Project type: Full project

• What it is: Defines if it's a temporary "Sandbox" or an official "Full project."
• Why I chose it: To get end-to-end control and official release packaging for this GSoC module.

Status and Classification

Maintenance status: Actively maintained

• What it is: Shows the community how much attention the project gets.
• Why I chose it: I will be actively monitoring, updating, and managing this code for the next 12 weeks and beyond.

Development status: Under active development

• What it is: Indicates the codebase's current maturity.
• Why I chose it: The module is currently being built from the ground up and evolving daily.

Module categories & Ecosystem: Artificial Intelligence (AI)

• What it is: Tags used to organize and filter Drupal projects.
• Why I chose it: Since the module relies on generative LLMs, this ensures the right audience finds it.

Dependencies: AI module

• What it is: Other modules required for this to work.
• Why I chose it: We are leveraging the existing Drupal AI core module to securely handle API configurations and process prompts.

Issue Tracking and Releases

Components: Code, Documentation, Miscellaneous, User interface

• What it is: Categories for issue queue tickets.
• Why I chose it: Granular tags keep the project organized and make bug triage much easier.

Enable issue tracker: Checked

• What it is: Allows the community to report bugs and submit patches.
• Why I chose it: Open source thrives on collaboration, and this is essential for community contributions.

Version options: Tagged releases, Development branch releases

• What it is: How Drupal packages the code for download via Composer.
• Why I chose it: It gives users the choice between a stable "Tagged" release or the bleeding-edge "Development" version.

The Description that I put is below.

<p>The AI Recipe Generator is a module designed to accelerate site building by utilizing Artificial Intelligence to generate Drupal Recipes dynamically.</p>

<p>By integrating with the Drupal AI ecosystem, this tool allows developers and site builders to input natural language prompts and automatically generate the necessary configuration, module dependencies, and structure required for a functional Drupal Recipe.</p>

<h3 id="module-project--features">Features</h3>
<ul>
  <li>Integrates directly with the Drupal AI module to process prompts.</li>
  <li>Dynamically generates <code>recipe.yml</code> files and associated configurations.</li>
  <li>Streamlines the creation of standard site features (e.g., blog setups, event content types) without manual YAML writing.</li>
</ul>

<h3 id="module-project--post-installation">Post-Installation</h3>
<p>Once installed, you will configure the generator through the AI module's interface. You must have an active AI provider configured via the core AI module to process prompts and begin generating recipes.</p>

<h3 id="module-project--additional-requirements">Additional Requirements</h3>
<p>This module requires the following dependencies:</p>
<ul>
  <li>AI (Artificial Intelligence) module ecosystem</li>
</ul>

<h3 id="module-project--recommended-libraries">Recommended modules/libraries</h3>
<p>There are currently no additional recommended modules beyond the required AI ecosystem dependencies.</p>

<h3 id="module-project--similar-projects">Similar projects</h3>
<p>While standard Drupal site-building tools exist, this project uniquely leverages generative LLMs and the new Drupal Recipe API to architect configurations via natural language.</p>

<h3 id="module-project--support">Supporting this Module</h3>
<p>This project is currently being developed as part of <strong>Google Summer of Code 2026</strong>.</p>

<h3 id="module-project--community-documentation">Community Documentation</h3>
<p>Weekly progress, architectural breakdowns, and documentation for this GSoC 2026 project are being documented under the <em>Engineering in the Wild</em> series.</p>

Further you can also add your logo here. It was also confusing for me to find out where the logo is.

You are almost done!!! You can review and see the details what they are. And then finally you can save and your project is successfully created! You can view my module here:AI Recipe Generator

Bonus: How to Add Maintainers

Most probably, you will be working with someone else. And it will be necessary to add someone there. Head over to the Maintainers tab and select whom you want to add in the search box. You can select the necessary changes to be made and then press enter!

Follow Along for my next journey

We all have been there where Google Summer of Code (GSoC) looks daunting to start, feeling its a tall mountain, difficult to climb. It looks like a challenge. Trust me I have been there. But in reality is just getting started and maintaining consistency. Let's now prep the kitchen!

The Spec Sheet

• Prep Time: 2.5 Months (On & Off)
• Cook Time: 12 Weeks
• Servings: Mainly you!
• Difficulty: Easy (if you use the best ingredients!)

Ingredients Needed - 3C's

1). Communication: The most important one. During the global GSoC welcome session, the organizers shared a powerful truth: our selection was 75% communication and only 25% coding

2). Consistency: If you are regular, it is a point that people will see you will to collaborate. (Although there is a work around this too)

3). Choosing: Make sure you choose the right repo & right tech stack that fits you!

Finding the right ingredients

The most difficult part in GSoC is I believe finding out which repo to contribute to rather than the actual contribution. Choosing between your* time, tech stack and project complexity*, it a task. Even I spent quite a lot of time on deciding which one to actually to contribute too.

Had used this site: GSOC Organisation Site. It helped me filter according to my tech stack (which was JS) and finally get to the repos. I had initially joined quite a few organisations as I had no clue how to go about it and shortlist it : )

I just got started, had not thought about the end output. What lingers when you start is where the easiest path forward is. Had tried RocketChat, and other repos where the tech stack was JS and available on github.

Why did I stick with Drupal?

COMMUNITY SUPPORT. There is a huge community there to help you if you get stuck. Somewhere down the line this made the difference which resulted in me never setting up another codebase of an organisation. Mind you, Drupal did have a steep learning curve, its not that easy to set up. But it worked in my favour once I set it up. Had posted a couple of doubts which truly helped me

You are going to get stuck! Work around it

I believed in this and whenever I got stuck I used to put a message in the group and continue. Sure it felt uncertain but the community response put me right path.

Important Learning

Before we move on to the rest of the journey, let me tell you one of the most important learning. If you approach GSoC as a competition you are going to be anxious and always in a mindset - The other person has done more issues, he/she is better than me I should do more.

A small change in mindset: How can I contribute more? How can I assist more? This is what even the mentors and org admins look for

My RECIPE for GSoC

Step 1: Interact with Mentors & Community Early On

Get in touch with your Mentor/s. They are going to guide you throughout your journey. And keep interacting with the community! In the GSoC welcome session with all contributors across all organisation, the organisers mentioned a point - if was 75% Communication, 25% Coding. That got you selected. This is the one of the most important part of your GSoC journey.

I had probably troubled my mentor a lot - asked a lot of questions. But he was also happy to guide me!

Step 2: Contribution & Documentation

In the organisation, contribute to the various issues. It will serve two purposes - making yourself familiar with the codebase & a record to you name. This will come in handy when the mentor is deciding which candidate to choose. Your PR might not be accepted, or you might have some bug in your code (happened a lot with me), it's alright, put comments on issue / slack. If the issue isn't accepted atleast you got engagement & interaction!

Document your progress. This is a thing which worked for me & a few people in Drupal had also done this. I had written a blog on Medium: Markdown Paradox. This was for an R&D task in my project description for which I wrote a blog as well as documented in word which I had shared with my mentor. A few others also had made blogs / a website for the same.

Bonus: You can add this in your proposal!

// What I put in my proposal

1 Personal Information
2 GSOC Information
3 Project Information
4 Abstract
5 Problem Statement
6 Technical Architecture & Implementation
  6.1 Validating & Caching
  6.2 Sample Implementation Code
7 Risk Analysis & Edge Cases
8 Detailed Timeline
9 Testing
10 Project Impact
11 Deliverables
12 Research Tasks
13 About Me & Community Experience

Step 3: Problem Statement & MVP

You should have a thorough understanding about the Problem Statement that you are picking to solve! It is extremely important that you solve it. Discuss on it and share your thoughts & ideas with your mentor. You could start with the R&D tasks mentioned and move ahead!

**MVP will be the star of the show! ** It showcases your idea of the problem statement and your technical prowess. It gives you a lot of brownie points as you have understood the implementation and what it takes to make a good project. I had also made an MVP and given it two voice-overs as an added bonus.

My MVP: https://github.com/Hrishikesh-Dalal/drupal-ai-recipe-generator

Step 4: Proposal Writing

This is really important if not the most important. This is your main criteria for judgement. What are your views on the project. Be sure to include architecture diagram, the drawbacks, migitations testing strategies etc.

Conclusion

Felt really amazing when i finally made it into GSoC. Happy to be there!