Forem: Serhii

Building multilingual runtime collections in a Filament plugin

Serhii — Wed, 15 Apr 2026 20:46:01 +0000

Building multilingual runtime collections in a Filament plugin

I just released v1.2.0 of Filament Studio, a Filament v5 plugin I am building for runtime collections, custom fields, dashboards, filters, and APIs.

The short version: this release adds multilingual support.

The longer version: adding multilingual support to a runtime data model is not the same as adding a translations JSON column and moving on.

Filament Studio is built for admin panels where the data model changes after the app is already running. A user can create a collection, add fields, manage records, build dashboards, and expose API endpoints without writing a new migration and Filament resource for each new content type.

That flexibility creates a specific problem for translations.

If the fields are defined at runtime, translation behavior also has to be defined at runtime.

The problem I wanted to solve

In real admin systems, multilingual content is rarely all-or-nothing.

A collection might support English and French.

Inside that collection:

title should be translated
description should be translated
price should stay shared
published_at should stay shared
is_featured should stay shared

That means translation behavior belongs at the field level, not only at the record or collection level.

I also wanted the feature to work across the whole plugin:

generated Filament forms
EAV storage
query builder reads and writes
REST API responses
OpenAPI documentation
fallback behavior
version snapshots

Otherwise it would feel like a partial feature.

Global and collection config

Multilingual support is opt-in.

// config/filament-studio.php
'locales' => [
    'enabled' => true,
    'available' => ['en', 'fr', 'de'],
    'default' => 'en',
],

You can also enable it through the environment:

STUDIO_LOCALES_ENABLED=true

Each collection can then define its own supported locales and default locale:

$collection->update([
    'supported_locales' => ['en', 'fr'],
    'default_locale' => 'en',
]);

If a collection does not define supported locales, it uses the global list.

Per-field translation

Each field now has a translatable flag.

That lets a collection mix localized and shared data:

title        translatable
description  translatable
price        shared
published_at shared
is_featured  shared

This is the part of the design I care about most. In multilingual admin work, not every value is content. Some values are facts, flags, prices, dates, or relationships. Treating all of them as translatable creates noise and sometimes bugs.

Storage model

Filament Studio uses an EAV model because fields are created at runtime.

For v1.2.0, the studio_values table now includes a locale column.

For translatable fields, values are stored per locale.

For shared fields, one value is used regardless of active locale.

The uniqueness boundary is:

record_id + field_id + locale

That allows a record to have different localized values for the same runtime field without creating new database columns for every translated field.

Locale resolution

I added a dedicated LocaleResolver service so the rules live in one place.

The active locale is resolved in this order:

?locale= query parameter
X-Locale header
session
collection default
global default

That gives API consumers a direct way to request a locale, while the admin panel can remember the selected locale in the session.

Query builder API

The EavQueryBuilder now supports a locale() method:

$data = EavQueryBuilder::for($collection)
    ->locale('fr')
    ->getRecordData($record);

Create and update operations can also target a locale:

$record = EavQueryBuilder::for($collection)
    ->locale('fr')
    ->create([
        'title' => 'Mon Titre',
    ]);

EavQueryBuilder::for($collection)
    ->locale('fr')
    ->update($record->id, [
        'title' => 'Titre mis a jour',
    ]);

There is also getAllLocaleData() for retrieving every translation at once:

$allData = EavQueryBuilder::for($collection)
    ->getAllLocaleData($record);

Example result:

[
    'title' => [
        'en' => 'My Title',
        'fr' => 'Mon Titre',
    ],
    'price' => 29.99,
]

Translatable fields return locale maps. Shared fields stay plain.

Fallback metadata

I did not want fallback behavior to be silent.

If an API client asks for French and a field falls back to English, the client should be able to detect that.

So getRecordDataWithMeta() returns fallback information:

$result = EavQueryBuilder::for($collection)
    ->locale('fr')
    ->getRecordDataWithMeta($record);

Example:

[
    'data' => [
        'title' => 'Mon Titre',
        'slug' => 'my-slug',
    ],
    'fallbacks' => ['slug'],
]

That tells the caller that slug came from the default locale.

REST API support

API endpoints now accept locale selection through query params:

curl -H "X-Api-Key: your-key" \
     "https://your-app.com/api/studio/posts?locale=fr"

or through headers:

curl -H "X-Api-Key: your-key" \
     -H "X-Locale: fr" \
     "https://your-app.com/api/studio/posts"

Responses include metadata:

{
  "data": {
    "uuid": "550e8400-e29b-41d4-a716-446655440000",
    "data": {
      "title": "Mon Titre",
      "slug": "my-slug",
      "price": 29.99
    }
  },
  "_meta": {
    "locale": "fr",
    "fallbacks": ["slug"]
  }
}

For single-record reads, all_locales=true returns every locale:

curl -H "X-Api-Key: your-key" \
     "https://your-app.com/api/studio/posts/550e8400?all_locales=true"

OpenAPI docs

When multilingual support is enabled, the generated OpenAPI docs include:

locale query parameter
X-Locale header parameter
all_locales query parameter
_meta.locale
_meta.fallbacks

This felt worth doing because API features are easy to misunderstand when the docs do not show the request and response shape.

Admin UI and versioning

In the Filament admin, multilingual collections now get a locale switcher on record pages.

Editors can switch locale and edit only the fields that should change for that locale.

Version snapshots also store all locale values for translatable fields:

{
  "title": {
    "en": "My Title",
    "fr": "Mon Titre"
  },
  "slug": {
    "en": "my-slug"
  },
  "price": 29.99
}

That way restoring a version does not only restore whichever locale happened to be active at the time.

Why I am sharing this

This was one of those updates that made the package feel more practical.

The first version of a dynamic admin builder can look good with just runtime fields and generated forms.

But real projects keep asking for the less glamorous pieces:

permissions
APIs
versioning
tenancy
filtering
multilingual content

That is the direction I am trying to push Filament Studio.

GitHub: https://github.com/flexpik/filament-studio

Packagist: https://packagist.org/packages/flexpik/filament-studio

If you have built multilingual admin panels in Laravel, I would like feedback on the model:

should translation behavior live per field?
is fallback metadata useful in practice?
would all_locales=true work for your API use cases?
what edge cases am I missing?

I built a Filament plugin for runtime collections, custom fields, dashboards, and APIs

Serhii — Mon, 06 Apr 2026 10:54:30 +0000

I built a Filament plugin for runtime collections, custom fields, dashboards, and APIs

I built Filament Studio because I got tired of the same cycle in Laravel projects.

The admin panel starts simple.

Then requirements change.

A client wants a new content type.

Then custom fields.

Then better filtering.

Then dashboards.

Then API access.

Then tenant-specific data.

Then version history.

Then another special case nobody planned for.

At that point, what looked like a straightforward Filament setup turns into more migrations, more models, more resources, more filters, and more maintenance.

That gets old fast.

So I built a plugin for Filament v5 that lets you create and manage data collections at runtime, define fields through the UI, manage records, build dashboards, and expose API endpoints without creating a new table and Filament resource every time the model changes.

The plugin is called Filament Studio.

The problem I wanted to solve

Filament is excellent when the data model is already clear and relatively stable.

But some projects are not like that at all.

You might be building:

a flexible internal CMS
a client-specific admin panel
an operations dashboard
a multi-tenant back office
a content platform where structure changes over time

In those projects, the data model is usually the part that keeps moving.

And every change has a cost.

A new content type is not just "add a few fields."

It usually means:

another migration
another model
another Filament resource
another set of forms and table columns
another round of filters and policies
another layer of maintenance

I wanted a way to stay inside Filament while making the admin side much more flexible.

What Filament Studio does

Filament Studio turns Filament into a runtime-configurable data platform.

With it, you can:

create collections from the admin UI
define custom fields without writing migrations for each collection
manage records with generated forms, tables, and filters
build dashboards with metrics and chart panels
expose REST API endpoints with API key authentication
enable versioning and soft deletes
scope everything by tenant
control access with policies and permissions
extend the system with custom field types, panel types, hooks, and schema modifiers

I was not trying to build a toy form builder.

I wanted something that still feels useful when the project becomes real.

Why I chose an EAV-based approach

The core of Filament Studio is an EAV storage model.

Instead of creating a new database table for every collection, the plugin stores:

collection definitions
field definitions
records
typed values

That gives the plugin room to support runtime schema changes without forcing a migration every time someone adds or edits a field.

I know EAV has a reputation.

Sometimes that reputation is deserved.

But in this case, the tradeoff made sense because I was not trying to model one stable domain perfectly.

I was trying to give teams a flexible way to build evolving admin-managed data systems inside Filament.

The important part was making it practical:

typed storage columns
generated Filament components
useful filtering
dashboards
API support
extensibility hooks
production-oriented features like tenancy and authorization

What's built in

Filament Studio already includes a lot of what I usually end up rebuilding by hand.

Dynamic collections

You can create collections in the admin panel and define fields visually.

The plugin currently includes 33 built-in field types across categories like:

text
numeric
boolean
selection
date and time
file
relational
structured
presentation

That makes it useful for more than simple text-entry forms.

Dashboard builder

There is also a dashboard builder with 9 panel types, including metrics, lists, time-series charts, bar charts, pie charts, and more.

That matters because once teams have data, the next thing they ask for is visibility.

Advanced filtering

I also wanted filtering to be good enough for real admin use, not just "search one text column."

So the plugin includes:

a visual filter builder
nested AND/OR logic
dynamic variables
saved presets
type-aware operators

REST API

Filament Studio can generate REST API endpoints with:

API key authentication
per-collection permissions
rate limiting
OpenAPI documentation

Production-oriented features

A lot of packages stop at the demo layer.

I wanted this one to go further, so it also supports:

multi-tenancy
authorization
record versioning
soft deletes
lifecycle hooks
schema modification callbacks
custom field and panel extensions

Who I think this is useful for

I think Filament Studio is most useful for three groups.

Laravel and Filament developers

If you like building with Filament but do not want every new admin requirement to trigger another round of scaffolding, this gives you a more flexible starting point.

Agencies

If you build custom admin panels for clients, this can reduce the amount of repetitive work involved in creating content structures, dashboards, and internal workflows.

Startup teams

If your internal systems and content models are still evolving, runtime collections can be easier to live with than constantly reshaping your app around new admin requirements.

What I wanted the plugin to feel like

I did not want this to feel like a disconnected "builder product" bolted onto Laravel.

I wanted it to still feel like it belongs in a Filament application.

That meant:

native-looking forms and tables
sensible extension points
support for real authorization models
room for custom field types and custom panels
documentation good enough that people can actually adopt it

I also spent time on screenshots and docs because I think open-source packages need to earn trust quickly.

If someone lands on the repository, they should immediately understand what the plugin does, what it looks like, and whether it is serious.

Why I'm sharing it now

I am sharing Filament Studio because I think it fills a real gap in a certain kind of Laravel project.

Not every app needs runtime-defined collections.

But when a project does need flexibility, the usual alternatives are messy:

keep hardcoding every change
overbuild a custom internal CMS
stitch together several tools
give up on having a clean workflow inside Filament

I wanted a better option.

If this sounds useful, I'd love feedback

If you work with Laravel and Filament and this solves a problem you've run into, take a look:

GitHub: https://github.com/flexpik/filament-studio
Packagist: https://packagist.org/packages/flexpik/filament-studio

If it looks useful:

star the repo
try it in a project
tell me what you'd build with it
tell me what feels missing

The most useful feedback at this stage is not just "looks nice."

It is "this would help me build X" or "I would need Y before using it."

That kind of feedback is what makes open-source tools better.

10 Reasons Why PrestaShop Is the Best E-commerce Platform for Your Business

Serhii — Tue, 21 Mar 2023 10:01:02 +0000

Introduction

Are you looking to start or expand your e-commerce business? With so many platforms available, it can be challenging to determine which one is the best fit for your specific needs. In this article, we will delve into 10 reasons why PrestaShop is the best e-commerce platform for your business, and why it should be at the top of your list.

1. User-friendly Interface

Intuitive dashboard
PrestaShop boasts a user-friendly interface with an intuitive dashboard that even beginners can easily navigate. The admin panel is designed with simplicity in mind, making it easy to manage your online store with minimal effort.

Easy customization
With PrestaShop, customizing your online store is a breeze. You can easily modify the look and feel of your site, add new features, and make changes to your store's layout without any coding knowledge.

2. Wide Range of Features

Built-in SEO tools
PrestaShop comes with a set of built-in SEO tools that help you optimize your online store for search engines. These tools include customizable meta titles, descriptions, and URLs, making it easy to improve your store's search engine rankings.

Powerful analytics
The platform offers robust analytics features that allow you to track your store's performance and make data-driven decisions. You can monitor sales, visitor behavior, and other key metrics with ease, helping you optimize your business strategy and grow your revenue.

3. Extensive Theme Selection

PrestaShop offers a vast selection of professionally designed themes, ensuring that your online store looks attractive and engaging. You can choose from a wide variety of free and premium themes, making it easy to find one that matches your brand identity and appeals to your target audience.

4. Scalability

PrestaShop is a highly scalable e-commerce platform, making it an ideal choice for businesses of all sizes. As your business grows, you can easily add new features, products, and categories without experiencing any significant slowdowns or performance issues.

5. Multilingual and Multi-currency Support

Operating an international e-commerce business? PrestaShop has you covered with its multilingual and multi-currency support. The platform allows you to offer your products in multiple languages and accept payments in various currencies, making it easier for you to cater to a global audience.

6. Large Community and Support Network

Active forums
PrestaShop has a large and active community of users, developers, and experts who are always ready to help. The platform's forums are filled with knowledgeable individuals who can offer advice, tips,and troubleshooting assistance whenever you need it.

Documentation and tutorials
PrestaShop also provides extensive documentation and tutorials, ensuring that you have all the resources you need to manage your online store effectively. These resources cover a wide range of topics, from basic setup to advanced customization and optimization techniques.

7. Cost-effective Solution

PrestaShop is an open-source platform, which means it's free to download and use. This makes it an attractive option for small businesses and startups on a tight budget. While there are some premium features and themes available for purchase, the core functionality of the platform is available at no cost.

8. High-level Security

Security is a top priority for any e-commerce business. PrestaShop takes this concern seriously by providing a secure platform that is regularly updated to address potential vulnerabilities. The platform also offers features like SSL support and PCI compliance, ensuring that your customers' sensitive data is protected.

9. Seamless Third-party Integrations

PrestaShop is highly compatible with various third-party services and applications, making it easy to integrate your online store with other tools and platforms. From payment gateways to shipping providers and marketing tools, PrestaShop's extensive ecosystem allows you to build a comprehensive e-commerce solution tailored to your specific needs.

10. Mobile-friendliness

With the ever-increasing importance of mobile commerce, having a mobile-friendly online store is essential. PrestaShop's responsive design ensures that your website looks great and functions smoothly on all devices, providing a seamless shopping experience for your customers.

Conclusion

In conclusion, PrestaShop is an excellent e-commerce platform that offers a wide range of features, scalability, and a user-friendly interface, making it an ideal choice for businesses of all sizes. By choosing PrestaShop, you can build a powerful online store that is easy to manage, secure, and ready to scale as your business grows.

FAQs

Q1: Can I migrate my existing online store to PrestaShop?

Yes, PrestaShop offers tools and resources to help you migrate your existing online store from another platform to PrestaShop. You can also seek assistance from the community or hire a professional to handle the migration process.

Q2: Does PrestaShop offer hosting services?

PrestaShop does not provide hosting services directly. However, the platform is compatible with various hosting providers, allowing you to choose the best hosting solution for your specific needs.

Q3: How customizable is PrestaShop?

PrestaShop is highly customizable, allowing you to tailor the appearance and functionality of your online store to suit your preferences. With a wide range of themes and modules available, you can create a unique shopping experience for your customers.

Q4: Is PrestaShop suitable for large-scale e-commerce businesses?

Yes, PrestaShop is designed to accommodate businesses of all sizes, including large-scale enterprises. Its scalability and extensive feature set make it an excellent choice for businesses with a large product catalog and high sales volume.

Q5: Can I use my own domain name with PrestaShop?

Yes, you can use your own domain name with PrestaShop. The platform allows you to connect your custom domain to your online store, ensuring that your branding remains consistent across all channels.