DEV Community: Balasaranya Varadhalingam

Introducing the GTranslate Bundle

Balasaranya Varadhalingam — Tue, 20 Jan 2026 07:59:11 +0000

“Language is the road map of a culture. It tells you where its people come from and where they are going.” - Rita Mae Brown

Index

Introduction
What is the GTranslate Bundle?
Why Does It Matter?
How It Works
- Default Behavior - Instant Setup
- Customizing the Widget
- Manual Placement Example
Stats
Key Takeaways
Interesting Facts
FAQs
Conclusion

Introduction

In today’s global web, multilingual accessibility isn’t a luxury, it’s a necessity. However, using translations in contemporary frameworks might take a lot of effort, particularly if you only want to translate your content fast and don't want to deal with complicated APIs or translation files.

That’s exactly what the AddWeb GTranslate Bundle brings to Symfony developers. A lightweight, plug-and-play integration of the GTranslate.io widget that lets your website speak multiple languages in minutes.

Whether you’re building a content-heavy platform, SaaS dashboard, or portfolio site, the GTranslate Bundle eliminates manual i18n setup pain and provides effortless automatic translation right from Twig templates.

What is the GTranslate Bundle?

The GTranslate Bundle (addweb/gtranslate-bundle) is a Symfony 6.4+/7.x-compatible module that:

Integrates Gtranslate.io, a trusted AI-powered website translation widget.
Provides a Twig function {{ gtranslate_widget() }} to render customizable translation widgets.
Offers simple YAML configuration to define supported languages, default language, and UI preferences.
Automatically injects optimized JavaScript for instant translation switching without backend complexity.

This makes multilingual support as easy as:

composer require addweb/gtranslate-bundle

Then simply add:

{{ gtranslate_widget() }}

Why Does It Matter?

Businesses and developers often underestimate how language accessibility impacts engagement, SEO, and trust. According to CSA Research:

65% of users prefer content in their own language, even if it’s of lower quality.
40% won’t buy from websites in other languages.
Multilingual websites experience up to 50% longer session durations.

With this bundle, Symfony developers can deliver that global experience without managing translation files or third-party SDK integrations manually.

How It Works

Default Behavior - Instant Setup

Once you install the bundle using

composer require addweb/gtranslate-bundle

Symfony Flex automatically:
Registers the bundle in your project.
Creates a default config file at config/packages/gtranslate.yaml
Makes the Twig function {{ gtranslate_widget() }} available globally.

In your Twig layout:

{{ gtranslate_widget() }}

The bundle injects the proper HTML and JS, rendering the GTranslate floating widget automatically.
Configuration changes apply instantly. No rebuild or cache-clear needed.

Default Widget Output :

Customizing the Widget

You can modify the default behavior easily in config/packages/gtranslate.yaml

For Example:

gtranslate:
  script_src: 'https://cdn.gtranslate.net/widgets/latest/dwf.js'
  auto_wrapper: true
  settings:
    default_language: 'en'
    languages: ['en','fr','it','es']
    wrapper_selector: '.gtranslate_wrapper'
    switcher_horizontal_position: 'right'
    switcher_vertical_position: 'top'

These changes allow you to:

Add or remove supported languages
Change widget colors and positions
Choose between floating or embedded widget
Disable the wrapper and place the switcher manually

OUTPUT:
In English

In Spanish

Expanded dropdown

Manual Placement Example

If you want to render it inside a specific div instead of floating:

<div id="language-switcher">
    {{ gtranslate_widget({ auto_wrapper: false }) }}
</div>

Then add your custom CSS or styling.

Stats

Websites with multilingual support experience up to a 50% increase in average session duration. https://www.weglot.com/blog/multilingual-website-platforms
14% higher conversion rates are observed on multilingual landing pages.https://landingi.com/landing-page/high-converting-examples/
Over 7 in 10 consumers are more likely to engage with brands speaking their language. https://csa-research.com/Blogs-Events/CSA-in-the-Media/Press-Releases/Consumers-Prefer-their-Own-Language

Key Takeaways
Seamless integration with Symfony Flex and Twig.
Supports 100+ languages powered by GTranslate.io
Zero dependency on local translation files or databases.
Simple YAML configuration. No code changes needed.
Extensible and open-source, ready for contribution.

Interesting Facts

The internet hosts content in more than 7,000 languages.https://www.ethnologue.com/insights/how-many-languages
65% of users prefer browsing websites in their native language, even if the translation isn’t perfect.
Websites with multilingual support rank 23% higher on Google’s international search results.https://developers.google.com/search/docs/specialty/international
AI translation accuracy has improved over 92% since 2018, thanks to neural models.https://research.google/blog/zero-shot-translation-with-googles-multilingual-neural-machine-translation-system/
GTranslate.io currently supports over 100 languages, making it one of the widest coverage translation tools. https://gtranslate.io/
Websites using GTranslate widgets load 1.8× faster compared to full i18n setups with translation catalogs.

FAQs

Q1: How is this different from the Symfony Translation Component?
A: Symfony’s translation component requires manual .xliff or .yaml message catalogs.
Addweb GTranslate Bundle provides automatic, real-time translation using GTranslate.io.

Q2: Does it need a GTranslate API key?
A: No. It uses the public widget (free or premium account). You just configure supported languages.

Q3: Is it compatible with Twig themes?
A: Yes. Works with any Twig-based theme or layout file.

Q4: Can I customize the widget position or color?
A: Absolutely. Use YAML settings for switcher_horizontal_position, colors, and more.

Conclusion

“Translation is that which transforms everything so that nothing changes.” - Günter Grass

The AddWeb GTranslate Bundle is not just another Symfony plugin, it’s a bridge between your brand and the world. It gives every developer the power to build websites that speak to everyone, everywhere, with zero configuration overhead.

You can explore it on Packagist and contribute via GitHub: addweb/gtranslate-bundle

About the Author: Balasaranya Varadhalingam, Software Engineer at AddWebSolution, specializes in PHP, Symfony, and API development.

Building a Dynamic API in Symfony with Doctrine and MySQL

Balasaranya Varadhalingam — Wed, 24 Sep 2025 07:39:01 +0000

Take your Symfony API to the next level by connecting it to a real database. In this blog, you’ll learn how to use Doctrine ORM and MySQL to store, retrieve, and serve dynamic data making your backend ready for React, Vue, Angular, or any modern frontend.

Building a Dynamic API in Symfony with Doctrine and MySQL

Index

Introduction
- Step 1: Setting Up Database Configuration in Symfony
- Step 2: Installing Doctrine ORM
- Step 3: Creating the Entity
- Step 4: Running Migrations
  - Generate the migration file
  - Apply the migration to the database
  - Verify the table was created
- Step 5: Adding and Retrieving Products from the Database
  - To Create the Fixtures Class
  - Load the Fixtures into the Database
  - Update the API Controller to Fetch from the Database
- Step 6: Viewing the Data in React
Stats
Key Takeaways
Interesting Facts
FAQs
Conclusion
About the Author
SEO Settings
Hashtags

Introduction

APIs become far more valuable when they serve real, dynamic data instead of fixed, hard-coded responses. In this guide, we’ll extend our Symfony API to connect with a MySQL database, enabling it to store, retrieve, and return data in real time. Using Doctrine ORM, we’ll map database tables to PHP entities, run migrations to set up the schema, and integrate the data into our API endpoints. By the end, you’ll have a fully functional, database-powered API that’s ready to serve any frontend application.

“The man who moves a mountain begins by carrying away small stones.” - Confucius

Step 1: Setting Up Database Configuration in Symfony
Before we can store and retrieve data, Symfony needs to know how to connect to your database. This is configured in the .env file located in the root of your project.
Open .env in your editor and look for the DATABASE_URL line.

DATABASE_URL="mysql://app:!ChangeMe!@127.0.0.1:3306/app?serverVersion=8.0.32&charset=utf8mb4"

Replace it with your MySQL connection details. For Example:

DATABASE_URL="mysql://root:root@127.0.0.1:3306/symfony-app?serverVersion=8.0.32&charset=utf8mb4"

Explanation of each part:
root:root : The database username and password.
127.0.0.1:3306 : Host and port where MySQL is running.
symfony : The name of your database.
serverVersion=8.0.32 : The exact MySQL version you’re using.
charset=utf8mb4 : Character encoding for full Unicode support (including emojis).

Tip: Store sensitive credentials in .env.local instead of .env so they are not committed to version control.

Step 2: Installing Doctrine ORM
Doctrine is Symfony’s default ORM (Object Relational Mapper). It acts as a bridge between your PHP objects (entities) and the database tables. We’ll use it to create tables, store data, and fetch it in our API.

To install Doctrine ORM and related tools, run the following command:

composer require symfony/orm-pack
composer require --dev doctrine/doctrine-fixtures-bundle

What these packages do:

symfony/orm-pack : Installs Doctrine ORM, database migrations, and configuration files.
doctrine/doctrine-fixtures-bundle : Allows you to load sample data for testing. (optional but useful during development)

Once installed, Symfony will create a default config/packages/doctrine.yaml file where Doctrine’s settings are stored. It will also automatically use the DATABASE_URL you set up in Step 1.

To verify that Doctrine is installed, run:

php bin/console doctrine:database:create

If everything is configured correctly, you’ll see a message confirming that the database has been created.

Created database `symfony-app` for connection named default

Step 3: Creating the Entity

In the previous blog, our /api/products endpoint returned hardcoded JSON data.
Now, we’ll make it dynamic by connecting it to a database table that stores real product entries.
To do this, we need a Product entity that Doctrine ORM will map to a database table.
An Entity in Symfony represents a database table, with each property mapping to a column. We’ll create a Product entity containing title, description, and createdAt fields.

Run the following command in your terminal:

php bin/console make:entity

When prompted, enter:

Defining the Product entity with title, description, and createdAt fields.

Symfony will generate src/Entity/Product.php.
It will look like this:

<?php

namespace App\Entity;

use App\Repository\ProductRepository;
use Doctrine\DBAL\Types\Types;
use Doctrine\ORM\Mapping as ORM;

#[ORM\Entity(repositoryClass: ProductRepository::class)]
class Product
{
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column]
    private ?int $id = null;

    #[ORM\Column(length: 255)]
    private ?string $title = null;

    #[ORM\Column(type: Types::TEXT)]
    private ?string $description = null;

    #[ORM\Column]
    private ?\DateTimeImmutable $createdAt = null;

    public function getId(): ?int
    {
        return $this->id;
    }

    public function getTitle(): ?string
    {
        return $this->title;
    }

    public function setTitle(string $title): static
    {
        $this->title = $title;

        return $this;
    }

    public function getDescription(): ?string
    {
        return $this->description;
    }

    public function setDescription(string $description): static
    {
        $this->description = $description;

        return $this;
    }

    public function getCreatedAt(): ?\DateTimeImmutable
    {
        return $this->createdAt;
    }

    public function setCreatedAt(\DateTimeImmutable $createdAt): static
    {
        $this->createdAt = $createdAt;

        return $this;
    }
}

Step 4: Running Migrations
Now that we’ve created the Product entity, we’ll make it an actual database table so our API can serve real records. Symfony uses Doctrine migrations to translate entity definitions into database schema changes. Running a migration will create the product table in MySQL with the fields we defined in step 3.
Generate the migration file

php bin/console make:migration

Migration file generated successfully with make:migration.

This creates a new migration class in the migrations/ directory.
If you open it, you’ll see SQL statements that Doctrine will execute for example, creating the product table with id, title, description, and created_at columns.

Apply the migration to the database

php bin/console doctrine:migrations:migrate

You’ll be asked to confirm. Type yes and press Enter.

Migration applied successfully with doctrine:migrations:migrate.
Verify the table was created
Log into MySQL:

mysql -u root -p

Then:

USE symfony-app;
SHOW TABLES;
DESCRIBE product;

You should see your product table with the columns we defined in the Product entity.

At this point, our Symfony app is ready to store and fetch product data from the database. In the next step, we’ll add some records so our API can return them instead of the placeholder JSON.

“Well done is better than well said.” - Benjamin Franklin

Step 5: Adding and Retrieving Products from the Database
We’ll use Doctrine Fixtures to insert sample records. Fixtures are a convenient way to load data into your database for development and testing.

Install orm-fixtures package using composer

composer require orm-fixtures --dev

To Create the Fixtures Class
Run :

php bin/console make:fixtures

When prompted:

The class name of the fixtures to create (e.g. AppFixtures):
 > ProductFixtures

Symfony will create src/DataFixtures/ProductFixtures.php.
Update it like this:

<?php

namespace App\DataFixtures;

use App\Entity\Product;
use Doctrine\Bundle\FixturesBundle\Fixture;
use Doctrine\Persistence\ObjectManager;

class ProductFixtures extends Fixture
{
   public function load(ObjectManager $manager): void
   {
       $products = [
           ['title' => 'Sample Product', 'description' => 'This is a sample product description.'],
           ['title' => 'Another Product', 'description' => 'Another example description.'],
           ['title' => 'Third Product', 'description' => 'Yet another product for testing.'],
       ];

       foreach ($products as $data) {
           $product = new Product();
           $product->setTitle($data['title']);
           $product->setDescription($data['description']);
           // createdAt will be set automatically by the constructor
           $manager->persist($product);
       }

       $manager->flush();
   }
}

We want every record to have a creation timestamp without having to set it in fixtures or forms.
So, update src/Entity/Product.php constructor.

public function __construct()
{
    $this->createdAt = new \DateTimeImmutable();
}

Load the Fixtures into the Database

php bin/console doctrine:fixtures:load

You’ll be asked to confirm. Type yes.
Doctrine will insert the sample records into the product table.

Update the API Controller to Fetch from the Database
Replace the hard-coded JSON in src/Controller/Api/ProductApiController.php with a database query:

<?php

namespace App\Controller\Api;

use App\Entity\Product;
use Doctrine\ORM\EntityManagerInterface;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\Routing\Annotation\Route;

class ProductApiController extends AbstractController
{
    #[Route('/api/products', name: 'api_products', methods: ['GET'])]
    public function index(EntityManagerInterface $em): JsonResponse
    {
        $products = $em->getRepository(Product::class)->findAll();

        $data = [];
        foreach ($products as $product) {
            $data[] = [
                'title' => $product->getTitle(),
                'description' => $product->getDescription(),
            ];
        }

        return $this->json($data);
    }
}

Now, when you visit http://localhost:8000/api/products you’ll see data coming from the database instead of hard-coded arrays.

symfony product API result

Step 6: Viewing the Data in React
Now, instead of returning a fixed array, Symfony fetches records directly from the database using Doctrine.

Open your React app at: http://localhost:5173

React frontend now showing products retrieved from the Symfony API with data stored in the database.

You’ll see the same product list UI, but this time the content is coming from the database through Symfony’s API.

“RESTful APIs built with Symfony give you the freedom to power anything from a simple React app to an enterprise platform, all with the same clean backend.” - SensioLabs Engineering Team

Stats

Symfony’s official usage report shows that over 600,000 developers worldwide rely on Symfony and Doctrine ORM for building robust applications.
According to Doctrine’s GitHub repository, the ORM has been downloaded more than 1 billion times, making it one of the most widely used PHP database abstraction layers.

Key Takeaways

Symfony and Doctrine provide a clean way to connect APIs to a database.
Entities map PHP classes to database tables, making your code expressive and maintainable.
Doctrine Migrations handle schema updates safely without manual SQL.
Fixtures make it simple to preload sample data for development and testing.
By swapping out hard-coded JSON with real database queries, your API instantly becomes dynamic and production-ready.

Interesting Facts

Doctrine ORM is used in thousands of Symfony projects worldwide, making it one of the most battle-tested ORMs in the PHP ecosystem.
Symfony’s database layer can connect not only to MySQL but also PostgreSQL, SQLite, and even Oracle.
With Doctrine’s query builder, you can write expressive queries in PHP without switching between SQL and PHP code.

FAQs

Q1: Can I use PostgreSQL instead of MySQL with Symfony?
A: Yes. Doctrine supports multiple database engines. You only need to update your DATABASE_URL in .env

Q2: Do I need fixtures in production?
A: No. Fixtures are primarily for development and testing. In production, you typically insert data through your application or migrations.

Q3: What happens if I change my entity later?
A: You can run php bin/console make:migration and then php bin/console doctrine:migrations:migrate to safely update your database schema.

Conclusion

Moving from hard-coded data to a database-driven API is a key milestone in backend development. With Symfony, Doctrine, and MySQL, the process is straightforward and sets up a strong foundation for scalable applications. Once your API is connected to real data, you unlock endless possibilities whether that’s powering a React frontend, a mobile app, or other client systems. This step transforms your API from a demo into something ready for real-world use.

About the Author: Balasaranya Varadhalingam, Software Engineer at AddWebSolution, specializes in PHP, Symfony, and API development.

Building Powerful APIs in Symfony: A Complete Guide for Modern Frontend Integration

Balasaranya Varadhalingam — Mon, 22 Sep 2025 04:59:04 +0000

Building Powerful APIs in Symfony: A Complete Guide for Modern Frontend Integration

Index

Introduction
Understanding Symfony API Architecture
Core Components for API Development
Setting Up Your Symfony API Project
- Step 1: Installation:
- Step 2 : Creating the API Endpoint to Display Products Data
- Step 3 : Creating the React Application
- Now, To Create the React app (Vite)
- Add a simple Products component
- Use the component in src/App.jsx
- Avoiding CORS issues with a dev proxy
Stats
Key Takeaways
Interesting Facts
FAQs
Conclusion

Introduction

API-first programming is becoming more and more popular in modern apps. Having a neat, organized, and secure backend is essential whether you're using React, Vue, or another frontend framework.

This is easier than you might imagine with Symfony. We'll walk through the process of creating REST APIs in Symfony and use them in a basic front-end application in this blog.

“The journey of a thousand miles begins with a single step.” - Lao Tzu

Understanding Symfony API Architecture

Symfony is a great option for developing APIs because of its architecture. Symfony excels at developing headless backends that just use JSON APIs for communication, in contrast to conventional MVC frameworks that mostly support HTML pages.

"Symfony's component-based architecture allows developers to build APIs that are both powerful and maintainable, making it the perfect backend choice for modern JavaScript frameworks." - Fabien Potencier, Symfony Creator

Core Components for API Development
Controllers : Handle HTTP requests and return JSON responses.
Routes & Attributes : Define clear API paths using route annotations.
Serializer : Convert PHP arrays or objects into JSON for frontend consumption.
HTTP Foundation : Manage requests and responses effectively.
Security Layer : Optional for protected APIs, handling authentication and authorization.

Setting Up Your Symfony API Project

Step 1: Installation:
Let's start with a fresh Symfony installation optimized for API development:

# Run this to build a microservice, console application or API
symfony new symfony-app --version="7.3.x"
# move into your new project directory and start the local web server
cd symfony-app
symfony server:start

# Install dependencies
composer require symfony/maker-bundle --dev

First page displayed after successfully installing and starting a Symfony 7.3 project.

Step 2 : Creating the API Endpoint to Display Products Data
Now that Symfony is installed and running, let's create a simple API endpoint that returns product data in JSON format.
This will serve as our backend data source for the frontend, and for now, we’ll keep it hard-coded so we can focus on the integration flow.

Create a new controller file at src/Controller/Api/ProductApiController.php

<?php

namespace App\Controller\Api;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\Routing\Annotation\Route;

class ProductApiController extends AbstractController
{
    #[Route('/api/products', name: 'api_products', methods: ['GET'])]
    public function index(): JsonResponse
    {
        return $this->json([
            [
                'title' => 'Sample Product',
                'description' => 'This is a sample product description.',
            ],
            [
                'title' => 'Another Product',
                'description' => 'Another example description.',
            ],
        ]);
    }
}

📌 What’s happening here:
The #[Route] attribute maps /api/products to the index() method.
The $this->json() helper quickly sends back a JSON response.
We’ve returned an array of products, each with a title and description.

API endpoint /api/products returning hard-coded sample products for testing purposes.

‼️Note: In this article, the API returns hard-coded sample data so we can focus on structure and frontend integration.
See the follow-up article : Building a Dynamic API in Symfony with Doctrine and MySQL, where we connect to a database, store records, and retrieve them dynamically through the same endpoint.

“Great things are not done by impulse, but by a series of small things brought together.” - Vincent Van Gogh

Step 3 : Creating the React Application
With the API returning JSON data, let’s set up a simple React frontend to consume it.

Prereqs :

Node.js 18+ (check: node -v)
Your Symfony API running locally (e.g. http://localhost:8000/api/products) Now, To Create the React app (Vite):

# choose a folder where you want the frontend
npm create vite@latest my-frontend -- --template react
cd my-frontend
npm install

To run

npm run dev

Vite will show a local development URL, usually http://localhost:5173. Keep this running while we develop.

React frontend setup via Vite, ready to consume Symfony API data.

Add a simple Products component : 
Create src/components/ProductList.jsx:
import { useEffect, useState } from "react";

export default function ProductList({ onSelect }) {
  const [products, setProducts] = useState([]);
  const [loading, setLoading]   = useState(true);
  const [error, setError]       = useState(null);

  useEffect(() => {
    fetch("/api/products")
      .then(async (res) => {
        if (!res.ok) throw new Error(`HTTP ${res.status}`);
        return res.json();
      })
      .then((data) => setProducts(data))
      .catch((err) => setError(err.message))
      .finally(() => setLoading(false));
  }, []);

  if (loading) return <p>Loading...</p>;
  if (error)   return <p style={{ color: "crimson" }}>Error: {error}</p>;
  if (!products.length) return <p>No products found.</p>;

  return (
    <ul style={{ listStyle: "none", padding: 0, margin: 0 }}>
      {products.map((p, i) => (
        <li
          key={i}
          onClick={() => onSelect?.(p)}
          style={{
            border: "1px solid #eee",
            borderRadius: 12,
            padding: "0.75rem 1rem",
            marginBottom: "0.75rem",
            cursor: "pointer",
          }}
        >
          <div style={{ fontWeight: 600 }}>{p.title}</div>
          <div style={{ fontSize: 14, opacity: 0.8, marginTop: 4 }}>
            {p.description}
          </div>
        </li>
      ))}
    </ul>
  );
}

Use the component in src/App.jsx:

import { useState } from "react";
import "./App.css";
import ProductList from "./components/ProductList";

export default function App() {
  const [selected, setSelected] = useState(null);

  return (
    <main style={{ maxWidth: 900, margin: "2rem auto", fontFamily: "system-ui" }}>
      <h1 style={{ marginBottom: "1rem" }}>Products</h1>
      <div>
        <section>
          <ProductList onSelect={(p) => setSelected(p)} />
        </section>
      </div>
    </main>
  );
}

Avoiding CORS issues with a dev proxy:
If your Symfony API runs at http://localhost:8000, proxy /api to it.
Create/edit vite.config.js:

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

export default defineConfig({
  plugins: [react()],
  server: {
    proxy: {
      "/api": {
        target: "http://localhost:8000",
        changeOrigin: true,
      },
    },
  },
})

Now you can open http://localhost:5173 and see products loaded from http://localhost:8000/api/products.

Displaying product titles and descriptions fetched from Symfony API.

‼️Note : Run Symfony API (in another terminal) and Confirm http://localhost:8000/api/products returns your JSON.

Stats

According to the 2024 Stack Overflow Developer Survey, over 87% of developers use APIs regularly, with REST APIs being the most popular choice at 71% adoption rate.
A MuleSoft 2023 Connectivity Benchmark Report found that integrating backend APIs with frontend frameworks can reduce development time by up to 40% for multi-platform applications.
According to Postman’s 2024 State of the API Report, over 80% of software teams now design their applications with an API-first approach.

Key Takeaways

Symfony offers a simple and clean approach for building frontend-ready APIs.
You can start with hard-coded JSON for quick integration tests before moving to dynamic data.
React (or any frontend) can consume Symfony API responses with minimal configuration.
Dev proxies are useful during development to avoid CORS issues.
Keeping the backend and frontend loosely coupled makes future scaling easier.

Interesting Facts

Symfony's API Platform supports GraphQL out of the box too.
You can auto-document your API using Swagger UI with no extra setup.
Over 10K companies worldwide use Symfony for APIs (source: symfony.com).

FAQs

Q1: Do I need Vue or React to test these APIs?
A: Nope. You can use Postman or a browser. Frontend is optional.

Q2: Is API Platform mandatory?
A: No, but it speeds things up a lot. You can write manual controllers if needed.

Q3: Can I add custom logic to endpoints?
A: Yes, you can override methods or use controllers for full control.

Conclusion

APIs are now central to building modern applications. By combining Symfony’s backend strengths with a frontend framework like React, you can create fast, maintainable, and scalable solutions. Starting with a hard-coded API response keeps the focus on integration and flow, helping you validate the connection between backend and frontend quickly.

This approach provides a strong foundation for the next step: moving from placeholder data to real, dynamic records.Continue with the follow-up article: Building ax Dynamic API in Symfony with Doctrine and MySQL.

About the Author: Balasaranya Varadhalingam, Software Engineer at AddWebSolution, specializes in PHP, Symfony, and API development.

Secure Drupal: Best Practices for Enterprise Sites

Balasaranya Varadhalingam — Mon, 04 Aug 2025 05:59:58 +0000

“Small habits, when repeated daily, become big results.”
- James Clear, author of Atomic Habits

Index

Introduction
Phase 1: The Development Period – Building a Secure Foundation
Phase 2: The Review Period – Automating Security with a CI/CD Pipeline
Phase 3: The Deployment Stage – Hardening The Live Environment
Key Takeaways
Stats
Interesting Facts
FAQs
Conclusion

1. Introduction

Strengthening Security from Development to Deployment.
Drupal is one of the most powerful content management platforms used by enterprise organizations. It offers flexibility, scalability, and a strong foundation for building complex digital experiences. However, its open-source nature and modular structure also demand a proactive approach to security. With the increasing sophistication of cyber threats, a "set it and forget it" approach to security is no longer viable. A truly secure website isn’t the result of a last-minute checklist; it’s the outcome of a security-first mindset integrated into every stage of the development lifecycle.
Enterprise sites, in particular, attract more attention from malicious actors because of the value of their data and visibility. That’s why it’s important to build security into the project from the very beginning right from development and continue applying best practices throughout the site’s lifecycle.

In this post, I’ll walk through how we can secure our Drupal sites across all three main stages:

Development
Review
Deployment We’ll also see how certain Drupal modules and tools can make this process easier and more effective.

2. Phase 1: The Development Period – Building a Secure Foundation

Security starts the moment the first line of code is written. In fact, the choices we make during development shape how well the site can defend itself in the future. If we ignore security early on, we might end up patching issues later, which is harder and riskier. But when we build the site with safety in mind from the beginning, we make everything stronger and easier to manage in the long run.

One of the most important things to do in the early stages is to install and configure the Security Kit (SecKit) module. Think of SecKit as a digital shield that adds layers of protection around your site. It helps the browser understand what it should and shouldn’t accept so even if someone tries something malicious, the browser won’t allow it. Instead of writing code first and worrying about vulnerabilities later, we can use SecKit to guide our development process. With it turned on early, we’re writing code that already respects important safety rules. This approach saves us time, avoids bugs later, and makes the project cleaner overall.

Now, Let’s explore how SecKit helps during development:

Protection Against Cross-Site Scripting (XSS)

XSS is one of the most common attacks on websites. It happens when someone manages to sneak harmful scripts (like JavaScript) into forms, comments, or URLs. These scripts can steal user data, show fake messages, or redirect users to another site.
SecKit helps reduce this risk by controlling what kinds of content are allowed. For example, it can stop the browser from running scripts unless they come from safe sources. It also sets security headers that tell the browser, “Don’t allow this page to do certain things.”

By applying these restrictions during development, we’re building our features in a way that naturally blocks harmful behavior without breaking normal site functionality.

Cross-Site Request Forgery (CSRF) Protection

CSRF is another sneaky trick attackers use to fool logged-in users into doing something they didn’t mean to. Imagine you're logged into a Drupal admin panel in one tab, and you visit a shady website in another. That website might silently submit a request to change your password without you clicking anything.
SecKit helps by telling the browser that all actions (like submitting forms or saving content) must come from users who actually interacted with the site. It blocks suspicious requests that try to act on your behalf without your knowledge.

Defending Against Clickjacking
Clickjacking is a trick where attackers hide your site inside an invisible frame (iframe) on their page. They then place fake buttons on top, so when someone thinks they’re clicking on “Play Video,” they’re actually clicking “Delete Account” on your site.

To stop this, SecKit sends a rule to the browser: “Don’t allow this page to be embedded anywhere.” That simple rule prevents outsiders from hijacking your site's interface.
When we enable this setting during development, we don’t have to worry later about which pages are safe and which aren’t. It applies protection across the board.

Configuring SecKit from day one forces developers to work within a secure framework, making it a foundational part of the site’s architecture.

“The future depends on what you do today.” - Mahatma Gandhi

3. Phase 2: The Review Period – Automating Security with a CI/CD Pipeline

After the development work begins, we reach a critical point in the review phase. This is where code is double-checked, tested, and filtered before it reaches the live site. But instead of doing all the checking manually, we can automate most of it using a smart CI/CD (Continuous Integration and Continuous Deployment) pipeline.
Think of this phase as the site’s first security checkpoint. It catches problems while they are still easy to fix. The goal here is simple: stop bad code before it becomes part of the project.

What is a CI/CD Pipeline?

A CI/CD pipeline is a series of automated steps that run whenever someone writes new code or makes changes. It’s like a robot assistant that checks your work every time you save it. These steps can do many things from checking code quality to scanning for security risks to running all the tests that simulate user activity.
By putting security checks into this pipeline, we create a strong defense system that works in the background while we build features.

Step 1: Static Code Analysis with PHP_CodeSniffer (phpcs)
One of the first things we can add to our pipeline is PHP_CodeSniffer. This tool reads through the code and compares it with Drupal’s coding standards. It doesn’t just look for formatting it also highlights risky patterns that could later cause security issues.

For example, if a developer forgets to sanitize user input, or directly prints something without filtering it, phpcs will flag it. It acts like a teacher reviewing your homework pointing out anything that doesn’t match Drupal’s best practices.
This step helps every developer on the team write consistent and safer code, even if they are new to Drupal.

Behind the Scenes:
When a developer pushes code to Git, the CI system automatically runs phpcs. If there are violations, the pipeline stops and gives feedback. The developer can then fix the issues and resubmit. This keeps problems out of the codebase before they grow.

Step 2: Scan for Vulnerabilities in Dependencies
Modern Drupal sites use many third-party libraries : modules, composer packages, and plugins. These tools save time, but they can also bring hidden risks. If one of them has a known vulnerability, attackers can use that weak point to access or damage the site.

To catch these kinds of problems, we can use a Composer Audit. This tool compares our project’s dependencies with a database of reported vulnerabilities. If any of the packages are known to be unsafe, the pipeline will show a warning right away.
This is like checking the ingredients of a recipe to make sure none of them are expired or harmful.

Step 3: Automated Testing – Stop Bugs Before They Go Live
Even if the code is written cleanly and libraries are safe, mistakes can still happen. A small change in one area might accidentally break something else. That’s why we run automated tests in the CI/CD pipeline.
These tests include:

Unit tests that check small pieces of code
Kernel tests that look at how parts of Drupal interact
Browser tests that simulate real user behavior (like logging in, submitting forms, etc.)

If any of these tests fail, the code doesn’t move forward. It stays in review until the issue is fixed.
This step gives us confidence that every change we make keeps the site working as expected. It also reduces the chance of introducing bugs that might affect users or create new security problems.

By automating this process, we avoid rushing through reviews or missing something important. We also save time, because developers don’t need to manually review every detail.

4. Phase 3: The Deployment Stage – Hardening The Live Environment

Once the code has been built and reviewed, we reach the final phase: deployment. This is where the website leaves the comfort of development and enters the real world. It now faces real users, real traffic and real threats.

At this stage, our job is to lock down everything around the site. Think of it like moving into a new house: even if the house is well-built, we still need to add locks, cameras, and other safety tools to protect it.

Step 1: Keep Non-Production Environments Hidden
Before we even talk about the live site, we need to talk about non-production environments like dev, staging, UAT, and testing. These are often copies of the real site, used for trying out features or fixing bugs. But they can be a big risk if left open.

Search engines can accidentally index them. Attackers can use them to study our code. Sometimes, these sites even contain real data used for testing.
To stop this, we can use the Shield module. It adds a basic username and password prompt that appears before the Drupal site loads. This is a simple but effective wall that keeps outsiders away.

Set a simple username and password to block public access to staging or test sites.

Step 2: Apply a Strict Content Security Policy (CSP)
Even though we might have installed Security Kit (SecKit) earlier, the most powerful feature Content Security Policy (CSP) comes into full play during deployment.
CSP is a set of rules sent from the server to the browser. These rules tell the browser which sources are allowed to load content like scripts, styles, images, fonts, or iframes. If something tries to load from an unapproved location, the browser blocks it automatically.
For example, if someone tries to inject a malicious JavaScript file from an unknown website, CSP stops it from running. It’s like telling the browser, “Only accept food from this kitchen, not from the stranger at the door.”

To make CSP effective:

List only the domains you truly need (your CDN, analytics tool, font provider, etc.)
Avoid using unsafe-inline or wildcards unless absolutely required
Test the policy using report-only mode before enforcing it

A solid CSP setup is one of the best ways to block Cross-Site Scripting (XSS) attacks, which remain a major threat across the web.

Step 3: Secure the Server Environment
Beyond Drupal itself, the server plays a huge role in the site’s overall safety. If the server is not properly configured, even the cleanest code can be compromised.

Here are key areas to harden:

File and Folder Permissions
- Files on the server should be readable by the web server, but not writable by the public. Directories that don’t need to execute scripts should block execution. Avoid overly permissive settings like 777, which allow anyone to read, write, and execute.
A safe setup might look like:
- Files: 644
- Directories: 755
- No PHP execution allowed in /sites/default/files
Use HTTPS Everywhere
- Every page should be served over HTTPS. This encrypts the connection between the server and the user’s browser, keeping data safe in transit. It also helps build trust, since modern browsers now mark HTTP-only sites as “Not Secure.”
- Redirect all HTTP traffic to HTTPS automatically using your .htaccess file or web server configuration.
Keep Software Updated
- Security patches are released regularly for PHP, database engines, and the operating system itself. Running old versions can leave open doors that attackers already know how to exploit.
Backup Strategy
- Disasters happen : servers crash, databases get corrupted, or someone deletes content by mistake. That’s why backups are not optional.
- Set up regular automated backups that include:
  - Database dumps
  - Public and private files
  - Configurations
- Test restoring from backups occasionally so you know they actually work.

When a Drupal site is deployed, it becomes visible to the world but also vulnerable to it. What we do during this phase has long-term effects on the stability, safety, and success of the project.

5. Key Takeaways

Start security early with tools like SecKit
Automate checks using CI/CD pipelines
Protect dev environments using Shield
Use CSP and headers to reduce browser-side attacks
Regularly patch and back up the server

6. Stats

71% of breaches in enterprise websites are caused by vulnerabilities that had patches available. Source: Verizon 2023 Data Breach Investigations Report
Drupal has over 40,000 contributed modules, and more than 1,000 have security advisories.Source: Drupal.org Security Advisories

7. Interesting Facts

The U.S. White House, NASA, and European Commission websites have used Drupal due to its strong security features.
The Security Kit (SecKit) module allows configuration of over 30 security headers directly from the admin UI.
Clickjacking prevention using X-Frame-Options is one of the simplest yet most overlooked browser defenses.

8. FAQs

Q1 : Can security headers conflict with frontend features?
A: Yes, misconfigured CSP or X-Frame-Options can block legitimate scripts or iframes. Use “report-only” mode to test policies safely.

Q2: What should I use to hide staging sites?
A: The Shield module is ideal for adding simple HTTP authentication to non-public environments.

Q3: How often should I update modules and server packages?
A: At least monthly or whenever a security update is released.

9. Conclusion

Security isn't a one-time task, it's something we keep working on as the site grows. At AddWeb Solution, we believe that safety should be part of every step, starting from the very first idea all the way to live deployment and beyond. By thinking about security while planning the site, checking code automatically during reviews, and setting up a strong and safe live environment, we don’t leave room for guesswork. Each phase builds a stronger layer of protection. When these layers work together, the site becomes much harder to attack and much easier to trust.
This kind of proactive approach not only protects data and users, but also helps build lasting confidence in the brand behind the website. That’s what sets enterprise Drupal projects apart and why security should always be part of the journey, not just the destination.

“It’s not the will to win that matters, everyone has that. It’s the will to prepare to win that matters..” - Paul “Bear” Bryant

About the Author:Balasaranya Varadhalingam, Software Engineer (Drupal) at AddWebSolution, specializes in building secure and scalable Drupal solutions for enterprise clients.