DEV Community: Dmitry

From Drupal to Obsidian: Exporting a Personal Knowledge Base to Markdown

Dmitry — Sun, 15 Mar 2026 23:00:00 +0000

For several years I used a small Drupal instance as my personal knowledge base. The main reason I chose Drupal in the first place was its powerful content modeling capabilities. Out of the box it provides content types, custom fields, and flexible taxonomy. Since I was already working with Drupal professionally, using it for personal knowledge management felt natural and efficient.

This post was originally published on my blog - https://dzhebrak.com/blog/from-drupal-to-obsidian/

Over time, however, I started to feel that the system was heavier than necessary for personal note-taking. Running a full CMS requires maintenance: updates, backups, hosting, and database management.

Obsidian appealed to me for several reasons. It stores notes as plain Markdown files, which means the data is future-proof and easy to manipulate with scripts. The entire knowledge base lives locally in a simple folder structure, yet the application provides powerful features like backlinking, graph visualization, and plugins.

The challenge was exporting structured content from Drupal and converting it into Markdown files that Obsidian could understand. My Drupal instance had few content types, some custom fields and tags. The goal was to export every node as a Markdown file with YAML front matter, so Obsidian could index the metadata and the content would be immediately readable.

Preparing Drupal for Export

Drupal's JSON:API module (included in core since Drupal 8.7) exposes all your content as a RESTful API with a consistent, well-documented response format. It was the obvious choice for programmatic access.

To authenticate the requests, I enabled the HTTP Basic Authentication module — also in Drupal core. This lets you pass credentials via standard HTTP headers, which is straightforward to use in a script without setting up OAuth or tokens.

Both modules can be enabled in one command:

drush en jsonapi basic_auth -y

Or through the admin UI at Extend (/admin/modules).

With these active, your content is accessible at endpoints like /jsonapi/node/article, returning a paginated JSON response with all field data included.

What Data I Needed

The example fields I cared about were:

Title — the node title, naturally
Body — the main article content in HTML (which I converted to Markdown)
Tags — a taxonomy term reference field, for Obsidian tags
field_related_links — custom multi-value link field containing external reference URLs

The JSON:API response nests taxonomy terms as relationships, so fetching tags required a quick include parameter: ?include=field_tags. Custom fields appear as first-class attributes in the response, so field_related_links came through without any special configuration.

The Export Script

Below is the script that handles the full export. It paginates through the JSON:API endpoint, converts each node's body HTML to Markdown, and writes individual .md files with YAML front matter to an output directory.

<?php declare(strict_types=1);

require_once __DIR__.'/vendor/autoload.php';

use League\HTMLToMarkdown\HtmlConverter;
use Symfony\Component\HttpClient\HttpClient;
use Symfony\Component\Yaml\Yaml;
use function Symfony\Component\String\u;

////////
$url = 'https://DRUPAL_DOMAIN/jsonapi/node/article?include=field_tags';
$username = '';
$password = '';
////////

set_time_limit(0);

$client = HttpClient::create();
$converter = new HtmlConverter();
$requestOptions = empty($username) && empty($password) ? [] : [
    'auth_basic' => [$username, $password],
];

do {
    $response = $client->request('GET', $url, $requestOptions)->toArray();

    $tags = [];
    foreach ($response['included'] ?? [] as $included) {
        $type = $included['type'] ?? null;
        $name = $included['attributes']['name'] ?? null;

        if ($type !== 'taxonomy_term--tags' || $name === null) {
            continue;
        }

        $tags[$included['id']] = $name;
    }

    foreach ($response['data'] ?? [] as $node) {
        $id = $node['id'] ?? null;
        $title = $node['attributes']['title'] ?? null;
        $html = $node['attributes']['body']['value'] ?? null;

        $nodeTagsIds = array_column($node['relationships']['field_tags']['data'] ?? [], 'id');
        $nodeTags = array_filter(array_map(
            fn($tagId) => $tags[$tagId] ?? null,
            $nodeTagsIds
        ));

        $markdownContent = $html ? $converter->convert($html) : null;
        $links = array_map(
            fn (array $link) => $link['uri'] ?? null,
            $node['attributes']['field_related_links'] ?? []
        );

        $title = u($title)->replaceMatches('/[\/:\*\?"<>|\\\\]/', ' ')->trim()->toString();

        $frontMatter = [
            'title' => $title,
            'tags' => array_map(
                fn (string $tag) => u($tag)->ascii()->lower()->replaceMatches('/(\s+|\.)/', '-')->trim()->toString(),
                $nodeTags,
            ),
        ];

        $linksCount = count($links);

        if ($linksCount === 1) {
            $frontMatter['source'] = current($links);
        } else if ($linksCount > 1) {
            $frontMatter['links'] = $links;
        }

        $frontMatterYaml = Yaml::dump($frontMatter);

        $outputFilename = sprintf('%s.md', $title);
        $outputFilepath = sprintf('%s/%s', __DIR__.'/output', $outputFilename);
        $outputContent = sprintf("---\n%s---\n%s", $frontMatterYaml, $markdownContent);
        file_put_contents($outputFilepath, $outputContent);
        printf("%s\n", $outputFilename);
    }

    $url = $response['links']['next']['href'] ?? null;
} while (!empty($url));

While the code may not be the most elegant solution, it effectively gets the job done, making it suitable for one-off tasks.

The script relies on several external packages, which can be installed via Composer:

composer require league/html-to-markdown symfony/http-client symfony/string symfony/translation-contracts symfony/yaml

I’ve also published the export script on GitHub, including a Docker setup to make it easier to run.

How to Use It

There are three things to configure at the top:

$url — set this to your Drupal site's JSON:API article endpoint, for example:

   https://your-drupal-site.com/jsonapi/node/article?include=field_tags

If you have a different content type, replace article with your machine name.

$username and $password — your Drupal user credentials if the website requires authentication. The account needs at least the access content permission.

Run the script with:

php export.php

The script will paginate automatically through all your nodes of the specified in the url type. When it finishes, you'll find one .md file per node in the output/ directory. File names are slugified from the node title to keep things readable.

Once the export is done, copy the contents of output/ into your Obsidian vault folder.

Final Thoughts

This migration turned out to be surprisingly straightforward thanks to Drupal’s strong API support. By enabling JSON:API and writing a small export script, it was possible to extract structured content and convert it into a portable Markdown format.

Moving from Drupal to Obsidian removed the overhead of maintaining a CMS while keeping the knowledge itself intact. Everything now lives in simple text files that are easy to version, sync, and manipulate with scripts.

For a personal knowledge base, that simplicity is hard to beat.

Programmatically sending emails with attachments in Drupal 10 using Symfony Mailer

Dmitry — Mon, 08 Apr 2024 04:00:00 +0000

Drupal Symfony Mailer is a module that introduces a new mail system based on the Symfony Mailer, the successor to the Swift Mailer library. It offers full support for HTML emails, file attachments, embedded images, and more.

This article details how to send HTML emails with attachments in Drupal programmatically. Let's assume you need to send a PDF file attached to an email. The PDF file can be stored as a media document, but depending on your requirements it could also be any file stored for example in a field of some content type.

Installation and Setup

The first step is to install and enable the Drupal Symfony Mailer module:

composer require 'drupal/symfony_mailer:^1.4'
vendor/bin/drush en symfony_mailer

For this demonstration, a custom module named mailer_example is created and enabled as well.

Creating a Custom Email Builder

In Drupal Symfony Mailer, the EmailBuilder is a plugin responsible for constructing the content of specific email types. It allows you to dynamically define the email's subject, body, available variables, and other settings based on the type of email being sent.

To create a custom EmailBuilder, you need to extend Drupal\symfony_mailer\Processor\EmailBuilderBase and override the build method:

<?php declare(strict_types=1);

namespace Drupal\mailer_example\Plugin\EmailBuilder;

use Drupal\Core\Entity\EntityTypeManagerInterface;
use Drupal\Core\File\FileSystemInterface;
use Drupal\Core\Plugin\ContainerFactoryPluginInterface;
use Drupal\file\Entity\File;
use Drupal\file\FileInterface;
use Drupal\media\Entity\Media;
use Drupal\symfony_mailer\Annotation\EmailBuilder;
use Drupal\symfony_mailer\EmailInterface;
use Drupal\symfony_mailer\Processor\EmailBuilderBase;
use Symfony\Component\DependencyInjection\ContainerInterface;

/**
 * @EmailBuilder(
 *     id = "mailer_example_builder",
 *     sub_types = {"default"},
 *     label = "Mailer example builder",
 *     common_adjusters = {"email_subject", "email_body",},
 *   )
 */
class ExampleEmailBuilder extends EmailBuilderBase implements ContainerFactoryPluginInterface {

  private const MEDIA_ID = 1;

  public function __construct(array $configuration, $plugin_id, $plugin_definition, private EntityTypeManagerInterface $entityTypeManager, private FileSystemInterface $fileSystem) {
    parent::__construct($configuration, $plugin_id, $plugin_definition);
  }

  #[\Override] public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition) {
    return new static($configuration, $plugin_id, $plugin_definition, $container->get('entity_type.manager'), $container->get('file_system'),);
  }

  public function build(EmailInterface $email) {
    $file = $this->getMediaFile(self::MEDIA_ID);

    if ($file instanceof FileInterface) {
      $email->attachFromPath($this->fileSystem->realpath($file->getFileUri()));
    }
  }

  private function getMediaFile(int $mediaId): ?File {
    $media = $this->entityTypeManager->getStorage('media')->load($mediaId);

    if ($media instanceof Media) {
      return $this->entityTypeManager->getStorage('file')
        ->load($media->getSource()->getSourceFieldValue($media));
    }

    return NULL;
  }

}

Within the build method, you can define the email's subject, body, and attach files using $email->attachFromPath($filepath). You can add as many files as needed with this method.

Adding a New Symfony Mailer Policy

A Mailer Policy defines how emails are sent from your Drupal site. It allows you to configure the email subject, body, set the email priority, and more.

Visit Configuration > System > Mailer and click Add policy.
Choose Mailer example builder (the label of your created EmailBuilder) as the type, then click Add and configure.
Add the desired content for the Subject and Body elements.

Remember that you can export the policy and place it in the config/install directory of your module.

Configuring SMTP Transport (Optional)

Depending on your setup, you might also need to add an SMTP transport.

Visit Configuration > System > Mailer > Transport, select SMTP, and click Add transport.
Specify your SMTP configuration (username, password, host name, port).

I use docker and mailhog/mailhog for testing emails in a local development environment, so my configuration looks like:

Host name: mail (specified in docker-compose.yml)
Port: 1025 (default mailhog SMTP port)

Sending the Email

Use email_factory service for injecting email factory and creating a new email using newTypedEmail method:

/** @var \Drupal\symfony_mailer\EmailFactoryInterface $emailFactory */
$emailFactory = \Drupal::service('email_factory');

$email = $emailFactory->newTypedEmail('mailer_example_builder', '');
$email->setTo('test@example.com');
$email->send();

The method takes an EmailBuilder plugin id (specified in the annotation) and sub-type as arguments.

Conclusion

The Drupal Symfony Mailer module empowers you to send programmatic emails with flexibility and control. By leveraging EmailBuilder and Mailer Policies, you can create dynamic and customizable email templates with attachments. This approach enhances your email communication's efficiency, maintainability, and content tailoring capabilities.

Translating entities in EasyAdmin with DoctrineBehaviors

Dmitry — Mon, 25 Sep 2023 13:15:07 +0000

In this article we will look at how to translate entities in EasyAdmin. We will create an "Article" entity, where we can translate title, slug and content into several languages, as well as add the ability to filter by translatable fields.

Database design approaches for multi-language websites

One of the challenges we face when developing multi-lingual applications is storing translatable entity properties. There are several database design approaches for this task, but the 2 most common ones are:

Single Translation Table Approach All translations are stored in a single table, the structure of which may look something like the following:

Additional Translation Table Approach A separate table containing only translations of that entity is created for each entity to be translated. Each row in such a table is a translation of all properties of the entity into a specific language. An example of the structure of such a table:

In this article, we will look at the second approach - Additional Translation Table.

Project setup

First, let's install EasyAdmin, as well as knplabs/doctrine-behaviors and a2lix/translation-form-bundle packages, which will allow us to simplify the implementation of multilingualism.

composer require easycorp/easyadmin-bundle knplabs/doctrine-behaviors a2lix/translation-form-bundle

We will add 3 languages: 2 of them will be mandatory when editing an entity (English and French), and 1 additional language (German). The default language will be English.

Create a config/packages/a2lix.yaml file with the following contents:

a2lix_translation_form:
    locale_provider: default
    locales: [en, fr, de]
    default_locale: en
    required_locales: [en, fr]
    templating: "@A2lixTranslationForm/bootstrap_5_layout.html.twig"

Create an entity Article with Symfony Maker. This entity should contain only non-translatable properties and must implement the TranslationInterface and use the Translatable trait:

namespace App\Entity;

use App\Repository\ArticleRepository;
use Doctrine\ORM\Mapping as ORM;
use Knp\DoctrineBehaviors\Contract\Entity\TranslatableInterface;
use Knp\DoctrineBehaviors\Model\Translatable\TranslatableTrait;
use Symfony\Component\PropertyAccess\PropertyAccess;

#[ORM\Entity(repositoryClass: ArticleRepository::class)]
class Article implements TranslatableInterface
{
    use TranslatableTrait;

    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column]
    private ?int $id = null;

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

And let's also add the magic __get method, thanks to which we can get translated properties (e.g., $article->getTitle()):

use Symfony\Component\PropertyAccess\PropertyAccess;

#[ORM\Entity(repositoryClass: ArticleRepository::class)]
class Article implements TranslatableInterface
{
    ...
    public function __get($name)
    {
        return PropertyAccess::createPropertyAccessor()->getValue($this->translate(), $name);
    }
}

Create a second entity that will contain the properties to be translated. In our example, these are title, slug and body. According to the naming convention, the name of this entity must be <X>Translation, where <X> is the name of the main entity (in our example, Article). Accordingly, the new entity is ArticleTranslation.

This entity must implement the TranslationInterface interface and use the TranslationTrait trait.

namespace App\Entity;

use App\Repository\ArticleTranslationRepository;
use Doctrine\DBAL\Types\Types;
use Doctrine\ORM\Mapping as ORM;
use Doctrine\ORM\Mapping\UniqueConstraint;
use Knp\DoctrineBehaviors\Contract\Entity\TranslationInterface;
use Knp\DoctrineBehaviors\Model\Translatable\TranslationTrait;
use Symfony\Bridge\Doctrine\Validator\Constraints\UniqueEntity;
use Symfony\Component\Validator\Constraints\Length;

#[ORM\Entity(repositoryClass: ArticleTranslationRepository::class)]
#[UniqueConstraint(name: "locale_slug_uidx", columns: ['locale', 'slug'])]
#[UniqueEntity(['locale', 'slug'])]
class ArticleTranslation implements TranslationInterface
{
    use TranslationTrait;

    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column]
    private ?int $id = null;

    #[ORM\Column(length: 255, nullable: true)]
    #[Length(min: 3)]
    private ?string $title = null;

    #[ORM\Column(length: 255, nullable: true)]
    private ?string $slug = null;

    #[ORM\Column(type: Types::TEXT, nullable: true)]
    private ?string $body = null;

    // GETTERS AND SETTERS
}

All fields are nullable, so empty translations can be saved for additional languages. I also added a unique index on locale and slug.

Now we need to create a migration for the new entities and run it:

bin/console make:migration
bin/console doctrine:migrations:migrate

Translating entities in EasyAdmin

Let's move on to creating the administrative backend using EasyAdmin. Create a new Dashboard and CRUD for the Article entity:

bin/console make:admin:dashboard
bin/console make:admin:crud

Add a link to Article crud in configureMenuItems() in the DashboardController:

...
class DashboardController extends AbstractDashboardController
{
    ...
    public function configureMenuItems(): iterable
    {
        yield MenuItem::linkToCrud('Articles', 'fas fa-pen', Article::class);
    }
}

We proceed to the implementation of the entity translation functionality in EasyAdmin.

Option 1

A quick solution is to create a new TranslationsSimpleField custom field in EasyAdmin, into which to pass an array with parameters for TranslationsType form type from the a2lix/translation-form-bundle package:

namespace App\EasyAdmin\Field;

use A2lix\TranslationFormBundle\Form\Type\TranslationsType;
use EasyCorp\Bundle\EasyAdminBundle\Contracts\Field\FieldInterface;
use EasyCorp\Bundle\EasyAdminBundle\Field\FieldTrait;

class TranslationsSimpleField implements FieldInterface
{
    use FieldTrait;

    public static function new(string $propertyName, ?string $label = null, $fieldsConfig = []): self
    {
        return (new self())
            ->setProperty($propertyName)
            ->setLabel($label)
            ->onlyOnForms()
            ->setRequired(true)
            ->setFormType(TranslationsType::class)
            ->setFormTypeOptions([
                'fields' => $fieldsConfig,
            ])
        ;
    }
}

An then return/yield that field from the configureFields() method of ArticleCrudController:

...
class ArticleCrudController extends AbstractCrudController
{
    ...
    public function configureFields(string $pageName): iterable
    {
        yield TranslationsSimpleField::new('translations', null, [
            'title' => [
                'field_type' => TextType::class,
                'required'   => true,
            ],
            'slug'  => [
                'field_type' => SlugType::class,
                'required'   => true,
            ],
            'body'  => [
                'field_type' => TextEditorType::class,
                'required'   => true,
            ],
        ]);
    }
}

But in this case, you will need to reverse engineer the EasyAdmin fields you want to use and their configurators, then manually pass options to each form type and load the resources and themes.

Option 2

Here's an idea. How about creating a new custom EasyAdmin TranslationsField field, and passing to it other EasyAdmin fields (that we need to translate) through addTranslatableField() method? With this implementation, we will be able to add translatable fields much easier:

...
class ArticleCrudController extends AbstractCrudController
{
    ...
    public function configureFields(string $pageName): iterable
    {
        yield TranslationsField::new('translations')
            ->addTranslatableField(TextField::new('title'))
            ->addTranslatableField(SlugField::new('slug'))
            ->addTranslatableField(TextEditorField::new('body'))
        ;
    }
}

I like the second approach better because it's cleaner and much easier to use later. And here's how we can do it.

Creating a custom TranslationsField field

Create a new class App\EasyAdmin\Field\TranslationsField. It must implement the FieldInterface interface and use the FieldTrait trait. And add the addTranslatableField() method:

namespace App\EasyAdmin\Field;

use A2lix\TranslationFormBundle\Form\Type\TranslationsType;
use EasyCorp\Bundle\EasyAdminBundle\Contracts\Field\FieldInterface;
use EasyCorp\Bundle\EasyAdminBundle\Field\FieldTrait;

class TranslationsField implements FieldInterface
{
    use FieldTrait;

    public const OPTION_FIELDS_CONFIG = 'fieldsConfig';

    public static function new(string $propertyName, ?string $label = null): self
    {
        return (new self())
            ->setProperty($propertyName)
            ->setLabel($label)
            ->onlyOnForms()
            ->setRequired(true)
            ->addFormTheme('admin/crud/form/field/translations.html.twig')
            ->addCssFiles('build/translations-field.css')
            ->setFormType(TranslationsType::class)
            ->setFormTypeOption('block_prefix', 'translations_field')
        ;
    }

    public function addTranslatableField(FieldInterface $field): self
    {
        $fieldsConfig = (array)$this->getAsDto()->getCustomOption(self::OPTION_FIELDS_CONFIG);
        $fieldsConfig[] = $field;

        $this->setCustomOption(self::OPTION_FIELDS_CONFIG, $fieldsConfig);

        return $this;
    }
}

Create a form theme admin/crud/form/field/translations.html.twig with the following content:

{% block a2lix_translations_widget %}
    {{ form_errors(form) }}

    <div class="a2lix_translations form-tabs">
        <ul class="a2lix_translationsLocales nav nav-tabs" role="tablist">
            {% for translationsFields in form %}
                {% set locale = translationsFields.vars.name %}

                {% set errorsNumber = 0 %}

                {% for translation in form | filter(translation => translation.vars.name == locale) %}
                    {% for translationField in translation.children %}
                        {% if translationField.vars.errors|length %}
                            {% set errorsNumber = errorsNumber + translationField.vars.errors|length %}
                        {% endif %}
                    {% endfor %}
                {% endfor %}

                <li class="nav-item">
                    <a href="#{{ translationsFields.vars.id }}_a2lix_translations-fields" class="nav-link {% if app.request.locale == locale %}active{% endif %}" data-bs-toggle="tab" role="tab">
                        {{ translationsFields.vars.label|default(locale|humanize)|trans }}
                        {% if translationsFields.vars.required %}<span class="locale-required"></span>{% endif %}
                        {% if errorsNumber > 0 %}<span class="badge badge-danger" title="{{ errorsNumber }}">{{ errorsNumber }}</span>{% endif %}
                    </a>
                </li>
            {% endfor %}
        </ul>

        <div class="a2lix_translationsFields tab-content">
            {% for translationsFields in form %}
                {% set locale = translationsFields.vars.name %}

                <div id="{{ translationsFields.vars.id }}_a2lix_translations-fields" class="tab-pane {% if app.request.locale == locale %}show active{% endif %} {% if not form.vars.valid %}sonata-ba-field-error{% endif %}" role="tabpanel">
                    {{ form_errors(translationsFields) }}
                    {{ form_widget(translationsFields, {'attr': {'class': 'row'}} ) }}
                </div>
            {% endfor %}
        </div>
    </div>
{% endblock %}

{% block a2lix_translations_label %}{% endblock %}

{% block a2lix_translationsForms_widget %}
    {{ block('a2lix_translations_widget') }}
{% endblock %}

I used the template "@A2lixTranslationForm/bootstrap_5_layout.html.twig" as a base, but modified it for EasyAdmin (tabs, required fields, number of errors).

Also, add a styles file build/translations-field.css with the following content:

.a2lix_translations > .nav-tabs .nav-item .locale-required:after {
    background: var(--color-danger);
    border-radius: 50%;
    content: "";
    display: inline-block;
    filter: opacity(75%);
    height: 4px;
    position: relative;
    right: -2px;
    top: -8px;
    width: 4px;
    z-index: var(--zindex-700);
}

Most likely you will use webpack in your work project, but to simplify the tutorial, I'll use css files.

Creating a Configurator for the TranslationsField

We also need a Configurator for the TranslationsField. Create a new class App\EasyAdmin\Field\Configurator\TranslationsConfigurator, which will implement the FieldConfiguratorInterface. The TranslationsField configurator must pass to TranslationsType required form types for each property to be translated with options for these form types.

namespace App\EasyAdmin\Field\Configurator;

use App\EasyAdmin\Field\TranslationsField;
use EasyCorp\Bundle\EasyAdminBundle\Collection\FieldCollection;
use EasyCorp\Bundle\EasyAdminBundle\Context\AdminContext;
use EasyCorp\Bundle\EasyAdminBundle\Contracts\Field\FieldConfiguratorInterface;
use EasyCorp\Bundle\EasyAdminBundle\Dto\EntityDto;
use EasyCorp\Bundle\EasyAdminBundle\Dto\FieldDto;
use Symfony\Component\Validator\Constraints\Valid;

class TranslationsConfigurator implements FieldConfiguratorInterface
{
    public function __construct(private iterable $fieldConfigurators)
    {
    }

    public function supports(FieldDto $field, EntityDto $entityDto): bool
    {
        return $field->getFieldFqcn() === TranslationsField::class;
    }

    public function configure(FieldDto $field, EntityDto $entityDto, AdminContext $context): void
    {
        $formTypeOptionsFields = [];

        $fieldsCollection = FieldCollection::new(
            (array) $field->getCustomOption(TranslationsField::OPTION_FIELDS_CONFIG)
        );

        foreach ($fieldsCollection as $dto) {
            /** @var FieldDto $dto */

            // run field configurator manually as translatable fields are not returned/yielded from configureFields()
            foreach ($this->fieldConfigurators as $configurator) {
                if (!$configurator->supports($dto, $entityDto)) {
                    continue;
                }

                $configurator->configure($dto, $entityDto, $context);
            }

            foreach ($dto->getFormThemes() as $formThemePath) {
                $context?->getCrud()?->addFormTheme($formThemePath);
            }

            // add translatable fields assets
            $context->getAssets()->mergeWith($dto->getAssets());

            $dto->setFormTypeOption('field_type', $dto->getFormType());
            $formTypeOptionsFields[$dto->getProperty()] = $dto->getFormTypeOptions();
        }

        $field->setFormTypeOptions([
            'ea_fields'   => $fieldsCollection,
            'fields'      => $formTypeOptionsFields,
            'constraints' => [
                new Valid(),
            ],
        ]);
    }
}

Since we will not return these fields in the configureFields() method of ArticleCrudController, EasyAdmin will not know anything about them by default. So we will manually run the configurators for the added fields, and load their assets (css and js).

Add this field configurator to config/services.yml:

App\EasyAdmin\Field\Configurator\TranslationsConfigurator:
    arguments:
        $fieldConfigurators: !tagged_iterator ea.field_configurator
    tags:
        - { name: 'ea.field_configurator', priority: -10 }

Creating a Form Type Extension

One more thing. EasyAdmin passes some properties required for display through the FormView variable ea_crud_form. Since EasyAdmin knows nothing about our fields, we will pass ea_crud_form value manually as well.

Create a new extension for the TranslationsType form type in the App\Form\Extension\TranslationsTypeExtension class with the following content:

namespace App\Form\Extension;

use A2lix\TranslationFormBundle\Form\Type\TranslationsType;
use EasyCorp\Bundle\EasyAdminBundle\Collection\FieldCollection;
use Symfony\Component\Form\AbstractTypeExtension;
use Symfony\Component\Form\FormInterface;
use Symfony\Component\Form\FormView;
use Symfony\Component\OptionsResolver\OptionsResolver;

class TranslationsTypeExtension extends AbstractTypeExtension
{
    public static function getExtendedTypes(): iterable
    {
        return [TranslationsType::class];
    }

    public function configureOptions(OptionsResolver $resolver)
    {
        $resolver->setRequired('ea_fields');
        $resolver->setAllowedTypes('ea_fields', FieldCollection::class);
    }

    public function finishView(FormView $view, FormInterface $form, array $options)
    {
        /** @var FieldCollection $fields */
        $fields = $options['ea_fields'];

        foreach ($view->children as $translationView) {
            foreach ($translationView->children as $fieldView) {
                $fieldView->vars['ea_crud_form'] = [
                    'ea_field' => $fields->getByProperty($fieldView->vars['name'])
                ];
            }
        }
    }
}

That's all we need. All that remains is to add the TranslationsField to the configureFields() method of the ArticleCrudController:

namespace App\Controller\Admin;

use App\EasyAdmin\Field\TranslationsField;
use App\EasyAdmin\Filter\TranslatableTextFilter;
use App\Entity\Article;
use EasyCorp\Bundle\EasyAdminBundle\Config\Filters;
use EasyCorp\Bundle\EasyAdminBundle\Controller\AbstractCrudController;
use EasyCorp\Bundle\EasyAdminBundle\Field\IdField;
use EasyCorp\Bundle\EasyAdminBundle\Field\SlugField;
use EasyCorp\Bundle\EasyAdminBundle\Field\TextEditorField;
use EasyCorp\Bundle\EasyAdminBundle\Field\TextField;

class ArticleCrudController extends AbstractCrudController
{
    ...
    public function configureFields(string $pageName): iterable
    {
        yield IdField::new('id')->hideOnForm();

        yield TranslationsField::new('translations')
            ->addTranslatableField(
                TextField::new('title')->setRequired(true)->setHelp('Help message for title')->setColumns(12)
            )
            ->addTranslatableField(
                SlugField::new('slug')->setTargetFieldName('title')->setRequired(true)->setHelp('Help message for slug')->setColumns(12)
            )
            ->addTranslatableField(
                TextEditorField::new('body')->setRequired(true)->setHelp('Help message for body')->setNumOfRows(6)->setColumns(12)
            )
        ;
    }
}

Now go to the "Create Article" page in the administrative backend, and you will see the title, slug, body translation fields:

Thanks to our TranslationsConfigurator field configurator and TranslationsTypeExtension form extension, all field parameters (e.g., help, columns, etc.) are passed automatically to TranslationsType.

Creating a filter for translatable fields

To be able to filter articles by translatable fields, create a new custom filter \App\EasyAdmin\Filter\TranslatableTextFilter with the following contents:

namespace App\EasyAdmin\Filter;

use Doctrine\ORM\QueryBuilder;
use EasyCorp\Bundle\EasyAdminBundle\Contracts\Filter\FilterInterface;
use EasyCorp\Bundle\EasyAdminBundle\Dto\EntityDto;
use EasyCorp\Bundle\EasyAdminBundle\Dto\FieldDto;
use EasyCorp\Bundle\EasyAdminBundle\Dto\FilterDataDto;
use EasyCorp\Bundle\EasyAdminBundle\Filter\FilterTrait;
use EasyCorp\Bundle\EasyAdminBundle\Form\Filter\Type\TextFilterType;

class TranslatableTextFilter implements FilterInterface
{
    use FilterTrait;

    public static function new(string $propertyName, $label = null): self
    {
        return (new self())
            ->setFilterFqcn(__CLASS__)
            ->setProperty($propertyName)
            ->setLabel($label)
            ->setFormType(TextFilterType::class)
            ->setFormTypeOption('translation_domain', 'messages')
        ;
    }

    public function apply(QueryBuilder $queryBuilder, FilterDataDto $filterDataDto, ?FieldDto $fieldDto, EntityDto $entityDto): void
    {
        $alias         = $filterDataDto->getEntityAlias();
        $property      = $filterDataDto->getProperty();
        $comparison    = $filterDataDto->getComparison();
        $parameterName = $filterDataDto->getParameterName();
        $value         = $filterDataDto->getValue();

        $queryBuilder
            ->leftJoin(sprintf('%s.translations', $alias), sprintf('%s_t', $alias))
            ->andWhere(sprintf('%s_t.%s %s :%s', $alias, $property, $comparison, $parameterName))
            ->setParameter($parameterName, $value)
        ;
    }
}

And then you can use it like any other filter in EasyAdmin:

...
class ArticleCrudController extends AbstractCrudController
{
    ...
    public function configureFilters(Filters $filters): Filters
    {
        return $filters
            ->add(TranslatableTextFilter::new('title'))
        ;
    }
    ...
}

You can see the full code on github https://github.com/dzhebrak/easyadmin-translation-form-demo/

👋 Need help with your PHP/Symfony project? Contact me, and let's explore how we can create exceptional web solutions tailored to your business needs.