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!

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!