DEV Community: Wolf

When the pillars collapse one after another

Wolf — Tue, 11 Aug 2026 09:50:22 +0000

Most of what I write about here has something to do with software: systems, architecture, tools, failures, and the occasional attempt to understand why something that looked perfectly stable suddenly isn’t.

This one is different.

Over the past few months, several of the things I considered stable parts of my life have either disappeared or started to move at roughly the same time. Not all of them are technical problems. In fact, most of them cannot be fixed with a better abstraction, another test, or a carefully planned migration.

Still, I noticed that I kept thinking about what was happening in the language I know best: systems, dependencies, redundancy, cascading failures, architecture and rebuilding.

So this is not really a software article.

But it might be an engineer’s way of thinking about what happens when the system in question is your own life.

What happens when life does not collapse all at once, but loses its structural support one pillar at a time?

There are things in life that we rarely think about as long as they work. A relationship, a career, a home, family, friendships, health, plans for the future. They form the structure around us so naturally that after a while we stop seeing them as separate things. Together, they simply become what we call my life.

It is only when one of them disappears that we notice how much weight it was carrying.

When that happens, the first reaction is usually not to question the whole structure. We compensate. If a relationship ends, work suddenly becomes more important. It provides routine, purpose, people, problems to solve and a reason to get up in the morning. If work becomes difficult, perhaps home and family become the safe place instead. If the future becomes uncertain, familiar routines keep the present predictable.

In other words, we redistribute the load.

As a software engineer, I cannot help seeing a familiar pattern in this. We design systems with the assumption that components will fail. A resilient system is not one in which nothing ever breaks; it is one that can tolerate something breaking without taking everything else down with it. We introduce redundancy, isolate failures and try very hard not to create single points of failure.

Human lives work surprisingly similarly, except that nobody sits down at twenty-five and draws an architecture diagram for the next fifty years.

We accumulate dependencies instead.

A partner gradually becomes responsible for most of our emotional intimacy. An employer provides not only money but identity, structure, social contact and a sense of usefulness. A city becomes synonymous with home. Family represents continuity. A particular idea of the future gives meaning to decisions made in the present.

None of this feels dangerous while everything is running.

Then one component fails.

And usually, the system survives.

The interesting part begins when another one fails shortly afterwards.

When failure stops being isolated

There is a significant difference between having several problems and experiencing cascading failure.

If one important part of life disappears, the remaining parts absorb some of its weight. That is one of the ways we recover. But it also means that those remaining structures suddenly matter more than they did before.

After losing one source of stability, it is natural to think: at least I still have my work. At least I still have my family. At least I still know where I belong. At least this part of my future is certain.

Those sentences are comforting because they define the boundary of the damage. Something has been lost, but the rest of the map still exists.

If one of those remaining certainties then starts to disappear as well, the effect is strangely disproportionate. The second loss does not merely add another problem. It changes the meaning of the first one. What previously looked like damage to one part of life starts to look like uncertainty about the structure itself.

The question changes from "How do I deal with this?" to "What exactly is still stable?".

That is a much harder question.

In engineering terms, redundancy only helps while redundant components remain independent. If one failure increases the load on another component, which then becomes more likely to fail, you have the beginning of a cascade.

Life does not follow engineering diagrams, of course. A relationship is not a service, a family is not a cluster and an employer is not an availability zone. You cannot replicate your father across three data centers, and there is no sensible SLA for friendship.

Still, the analogy exposes something that I find uncomfortable: many things I think of as parts of my identity are actually infrastructure.

“I am a software engineer.”
“I am someone’s partner.”
“I work for this company.”
“This city is my home.”
“This is what I will probably be doing five years from now.”

These sentences sound like descriptions of a person. But they also describe relationships between that person and external systems. Employers can disappear. Relationships can end. Cities can become unaffordable or unfamiliar. Families change. Bodies change. Plans become obsolete.

When several of those things move at once, it can feel as if identity itself is being dismantled.

Perhaps it is not.

Perhaps what is being dismantled is the structure that made identity easy to describe.

The urge to rebuild

This is usually the point where advice starts arriving.

Find a new job. Meet someone new. Move somewhere else. Start a project. Set goals. Establish routines. Reinvent yourself. Look forward instead of backward.

There is nothing inherently wrong with any of that. Eventually, some form of rebuilding is necessary. Human beings need attachment, purpose, structure and other people. The goal cannot reasonably be to become independent of everything that might someday disappear.

But I have started to wonder whether rebuilding too quickly has its own risk.

If a building collapses and the first priority is to replace every missing wall exactly where it used to be, there is not much opportunity to ask whether the old floor plan was actually good.

A new relationship can occupy exactly the same structural position as the old one. A new employer can become the same source of identity and security. A new five-year plan can restore the reassuring illusion that the future has agreed to cooperate.

The materials change, but the architecture remains untouched.

This is where the metaphor of an empty field becomes more useful to me than the metaphor of ruins.

An empty field initially sounds bleak. There is no shelter, no obvious orientation and nothing telling you where anything belongs. If you have spent years maintaining a structure, the absence of one looks like failure.

But an empty field has one property that a finished building does not have: it has not yet decided what it must become.

That does not automatically make loss a gift. I dislike the tendency to turn every painful event into an inspirational lesson. Some losses are simply losses. Things that mattered are gone, and there is no obligation to be grateful for that.

Freedom itself is not always pleasant either. Freedom that you deliberately choose can feel exhilarating; freedom produced by losing things you wanted to keep can feel remarkably similar to abandonment.

And yet both can be true at once.

An empty field can be frightening because nothing is there, and valuable because nothing is fixed.

You do not have to thank the bulldozer to notice the horizon.

What can be carried?

Maybe, then, the first question after a collapse should not be "What do I build next?".

Maybe it should be "What survived?".

Not in the sense of searching for some mystical, immutable “true self” underneath everything else. I am not convinced such a thing exists. People are shaped by their relationships, environments, work and history. Remove all context from a person and there may not be some perfectly preserved essence waiting underneath.

But some things are more portable than others.

An employer can disappear, but skills travel. A project can end, but experience remains. Plans can fail without destroying curiosity. A relationship can end without erasing the capacity to love. Institutions can disappear while values remain. Creative work can survive circumstances that completely change the context in which it was created.

Perhaps these things are not pillars at all. Pillars support us from outside. These are things we carry.

That distinction seems increasingly important to me.

The usual story about personal crisis has a satisfying narrative arc. Something collapses, the protagonist struggles, learns what really matters, rebuilds a better life and eventually looks backward from a position of renewed stability. It is a good structure for books, talks and films because it has an ending.

Actual life has an inconvenient middle.

There is a period in which you know what has ended but do not yet know what begins next. The old blueprint no longer applies, but there is no new one. There may be possibilities without preferences, freedom without direction and hope without anything concrete to attach it to.

We seem strangely uncomfortable with that state. We treat uncertainty as a temporary defect that should be resolved as efficiently as possible.

I am no longer sure that is always useful.

There may be value in spending some time between buildings.

Not indefinitely. Not as an excuse to withdraw from life. But long enough to look at the old structure without immediately trying to reproduce it.

Which parts actually supported me? Which parts merely occupied space? Which compromises had quietly become load-bearing? Which rooms had I stopped entering years ago? Which dependencies were unavoidable, and which ones did I create because they made life easier to predict?

And perhaps the most important question: if nobody handed me the old blueprint again, would I really design the same building?

I do not have an answer yet.

That is partly why I wanted to write this now rather than years later, when memory might have rearranged everything into a clean story about adversity and personal growth. I am more interested in the unresolved part: the point at which enough familiar structures have become uncertain that rebuilding the old life no longer seems like the only imaginable objective.

Losing one pillar makes you reach for the others. Losing several can make you question the architecture.

Maybe that does not mean everything has failed.

Maybe it means there is finally a difference between rebuilding stability and rebuilding the past.

If you ever find yourself standing on that empty field, there may be no reason to start pouring concrete immediately. You can stand there for a while. Look at what is still with you. Look at what you actually miss and what you only assumed you were supposed to replace.

Then, eventually, decide what deserves to be built again.

This article has also been published on Medium.

UI Kernel: Design Tokens as Symfony infrastructure

Wolf — Fri, 03 Jul 2026 22:34:20 +0000

For years, Symfony teams solved UI scaling one of two ways.

Either you adopted a JavaScript build pipeline — Webpack Encore, Vite, npm scripts — and a utility CSS framework like Tailwind.

Or you stayed "PHP-first" and watched every project grow its own app.css, its own spacing scale, its own dark-mode hacks, and its own Bootstrap overrides.

Both paths work. Neither scales cleanly across agencies, products, and long-lived admin UIs.

UI Kernel (symfinity/ui-kernel, current line 0.3.x) is Symfinity's answer on the Symfony side: treat design tokens as infrastructure — resolved in PHP, emitted as CSS custom properties, consumed by Twig and component CSS — without making Node the gatekeeper of your theme.

This article explains the CSS story first, then where Symfony fits in — including the 0.3.x theme engine (runtime switching, overlays, and inheritance).

The problem tokens solve

Hard-coded hex values in templates do not scale.

When primary blue lives in forty places, rebranding is a grep exercise. When dark mode is bolted on with @media (prefers-color-scheme: dark) and ad hoc overrides, contrast breaks in corners nobody tested. When spacing is "whatever looked fine in Figma," components drift apart.

Design tokens are the fix: named, semantic variables (--color-text, --space-md, --radius-lg) that components reference instead of raw values.

That idea is not new. What changed recently is how we author and validate those tokens in CSS — especially for colour.

Why OKLCH matters for palettes

Classic spaces — RGB, HSL — are easy to compute but bad at matching human perception.

A "50% lightness" yellow and a "50% lightness" blue do not look equally bright. Darkening with hsl() or Sass darken() shifts hue and brightness in unpredictable ways. Building a ten-step brand ramp that stays accessible was always guesswork.

OKLCH (lightness, chroma, hue in the Oklab model) is perceptually uniform: equal steps on the L axis feel like equal brightness changes across hues. That makes ramps, states (hover, active), and dark-mode pairs far more predictable.

In modern CSS you can write tokens directly:

:root {
  --text: oklch(0.30 0.03 260);
  --surface: oklch(0.97 0.01 260);
  --accent: oklch(0.60 0.14 255);
}

Progressive enhancement still matters — ship sRGB fallbacks, layer OKLCH behind @supports:

:root {
  --text: #222326;
  --accent: #005fcc;
}

@supports (color: oklch(0.5 0.1 0)) {
  :root {
    --text: oklch(0.30 0.03 260);
    --accent: oklch(0.60 0.14 255);
  }
}

For state colours, color-mix(in oklch, …) keeps blends on the perceptual axis instead of muddy RGB averages.

Contrast: WCAG today, APCA tomorrow

Accessibility checks still anchor on WCAG 2.x contrast ratios (4.5:1 body text, 3:1 large text/UI). OKLCH helps because L tracks perceived lightness — pairs with sufficient L separation tend to pass, which is why token-driven systems can enforce contrast at generation time instead of in every component file.

APCA (Advanced Perceptual Contrast Algorithm) is the direction of travel for WCAG 3. Good practice in 2026: design with APCA awareness, audit with WCAG for compliance paperwork. They usually agree; where they diverge, APCA often reflects real-world legibility better (thin type, dark UI, wide gamut).

Tools worth bookmarking

These are the references I reach for when building or reviewing token palettes — independent of Symfony:

OKLCH Color Picker & Converter — oklch.com — pick, convert, P3/Rec2020 preview, palette building with APCA (Evil Martians)
Evil Martians OKLCH ecosystem guide — Exploring the OKLCH ecosystem — Harmonizer, apcach, and related tooling
Atmos OKLCH picker — atmos.style/color-picker/oklch — fast format conversion plus WCAG/APCA hints
HubTools color picker — hub-tools.com/tools/color-picker — OKLCH/LAB/P3, harmonies, CVD simulation, W3C token export
APCA introduction — APCA easy intro — readable explainer for the contrast model
W3C Design Tokens Community Group — designtokens.org — format spec for portable token files

From CSS files to Symfony infrastructure

Node-centric pipelines (Style Dictionary, Tailwind config, theme JSON → build step) fit design agencies. They hurt Symfony teams who want Flex install, YAML config, and AssetMapper without a second repository for tokens.

UI Kernel inverts the default:

Tokens live as data — W3C DTCG-shaped theme layers (colour, spacing, radius, motion, typography references).
PHP resolves and validates — lineage (Balanced, Semantic, Utility), light/dark variants, OKLCH ramp math, contrast-aware semantic colours.
CSS is emitted server-side — custom properties on [data-theme="…"], wrapped in cascade layers (kernel.tokens, kernel.profile) for predictable stacking with ux-blocks-* tiers.
Twig wires the page — boot script, layer order, and theme CSS in the layout; no Encore entry for "theme variables."

Minimal layout (order matters — boot script first avoids a flash of the wrong theme):

{# templates/base.html.twig #}
<head>
    {{ ui_kernel_theme_boot_script() }}
    {{ ui_kernel_layer_order()|raw }}
    {{ ui_kernel_css()|raw }}
</head>

Or use the bundle partial, which emits the same three calls:

{% include '@UiKernel/_head.html.twig' %}

Configuration stays in familiar Symfony paths:

# config/packages/symfinity_ui_kernel.yaml
symfinity_ui_kernel:
    default_theme: semantic
    default_variant: semantic
    schema_version: '2.0'

Install is Composer + Flex — same story as any other bundle:

composer require symfinity/ui-kernel

What you do not need for theming: Tailwind as the token source of truth, a Sass pipeline for variables, or Encore/Vite solely to compile :root { --… }.

What you still use Symfony for: AssetMapper for component JS/CSS paths, Stimulus for micro-interactions, UX Twig Components for leaves — AssetMapper is plumbing, not your design system.

Runtime theme engine (0.3.x)

Static token emission was the 0.2.x story. 0.3.x adds a theme engine on top — still server-resolved, still no Node build step.

Runtime switching

Users pick light, dark, or auto without redeploying CSS. The boot script sets data-theme before first paint; preference cookies (symfinity_ui_kernel_lineage, symfinity_ui_kernel_scheme) persist the choice.

Scheme API

PATCH /_ui/theme/scheme returns resolved theme id, colorScheme, and refreshed CSS when the client needs server-side dark-mode resolution.

Theme shell

ui_kernel_theme_shell() emits layout chrome (lineage + light/dark/auto controls) wired to the same preference model.

Overlays

Config user_tokens merge atop the registry theme; app config/themes/{lineage}/ overrides bundle lineages; optional session preview on designated preview hosts (pairs with symfinity/ui-designer in dev).

Theme inheritance

Optional extends on a variant entry in theme.meta.yaml merges a parent theme layer before child overrides — multi-hop chains with cycle detection (0.3.1).

Capability probe

ui_kernel_theme_capabilities() reports which engine features are active (runtime_switch, user_token_overlay, nested_theme, and others).

Built-in lineages still ship as W3C DTCG files under config/themes/{lineage}/ (theme.meta.yaml + {variant}.dtcg.yaml), not a bespoke preset blob. Consumer apps drop overrides in the same layout; merged variants appear in ThemeRegistry.

Authoring UI for composition graphs, import/export, and the visual studio at /ui-designer lives in symfinity/ui-designer (dev-only, requires ui-kernel ^0.3.1) — the kernel stays the runtime contract.

How this stays scalable

Semantic tokens, not utility soup

Components and UX Blocks reference roles and semantic variables (data-ui-role, --ui-color-accent, spacing rhythm) — not p-4 text-gray-600 copied across Twig files.

The kernel owns the look spine; symfinity/ux-blocks-* packages own component CSS that consumes those variables. Boundary stays explicit: kernel emits tokens and global profile rules inside @layer kernel.*; blocks emit role selectors inside @layer blocks.*. Call ui_kernel_layer_order() before theme CSS so integrator CSS can override predictably.

One theme graph, many surfaces

The same resolved token graph can feed:

Web layouts — static emission plus 0.3.x runtime switching, overlays, and inheritance without forking app.css
Email HTML with inline-safe subsets (horizon)
PDF/print (horizon)
CLI/TUI structured output (horizon)

That is the payoff of server-resolved tokens versus "whatever landed in public/build/app.css last Tuesday."

OKLCH inside, CSS outside

Internally, Symfinity generates palettes in OKLCH for perceptual ramps and ref resolution. Public CSS still ships browser-ready strings (sRGB hex/rgb(), with P3 where supported). You get palette math without asking every integrator to hand-author oklch() literals in YAML.

Works with what you already run

UI Kernel complements Symfony UX — it does not replace Live Components, Turbo, or Stimulus.

Typical Stage A path:

Install kernel for tokens on the layout shell.
Drop UX Blocks into existing Twig.
Add font-manager when typography tokens need real webfonts.

Plain Twig + your own CSS remains valid for marketing pages. The stack targets long-lived product and admin UI where theme drift hurts.

When Tailwind or Encore still make sense

Honest scope:

Tailwind — excellent for marketing microsites, rapid prototypes, or teams already standardized on utility CSS. Symfinity does not ask you to rip it out on day one.
Encore/Vite — still right when you need a heavy JS application bundle, legacy React/Vue islands, or org-wide frontend tooling unrelated to tokens.

UI Kernel draws a line: theming and design-system variables are Symfony infrastructure, not npm devDependencies.

If your pain is "every client has a different primary colour and our admin UI looks nothing like last year's project," tokens in PHP beat another tailwind.config.js fork.

Try it locally

After adding the symfinity/recipes Flex endpoint:

composer require symfinity/ui-kernel

Handbook: ui-kernel docs — quick start, themes (0.3.x), upgrade guide.

What's next

UI Kernel roadmap: 0.3.x theme engine (current) → 0.4.x token engine (computed tokens, references, expressions) → 0.5.x generator engine. See ROADMAP.md.

Don't miss the introduction series to Symfinity:

For package-level deep dives already published:

Articles on further Symfinity package tiers are planned — ui-designer (theme authoring studio) and UX Blocks deep dives are on the list.

Explore packages and source at github.com/symfinity.

Updated 2026-07-05 for ui-kernel 0.3.x (runtime switching, cascade layers, theme inheritance).

The rule behind every Symfinity package

Wolf — Wed, 24 Jun 2026 20:00:14 +0000

Whenever I start a new package, I try to follow a simple rule.

If a package does not improve developer experience, it probably should not exist.

That sounds obvious. But it has become the guiding principle behind Symfinity.

A package must solve a real problem

The first question is simple:

Would I actually use this package in my next project?

If the answer is no, it probably belongs in an experiment repository instead.

That is how symfinity/font-manager and symfinity/omnia-ipsum started: I needed fonts and placeholder content on the next greenfield, not another abstract slot in a roadmap slide.

A package must be Symfony-native

I do not want packages that fight Symfony. I want packages that feel like they belong there.

Symfony-native, for Symfinity, means:

Composer-first — install with composer require, not a parallel plugin manager
Flex recipes where they earn their keep — sensible defaults, manifest-driven wiring, overrides in the usual Symfony config paths
Standard bundle shape — Extension, Configuration, services tagged the Symfony way; no hidden bootstrap magic
Hooks you already know — Twig, Console, AssetMapper, and HTTP integration that follow Symfony docs, not a second framework inside the framework
Predictable integration — if you know Symfony, you know where to look

Minimal surprises. No ecosystem lock-in dressed up as convenience.

A package must require little configuration

Configuration is sometimes necessary.

Excessive configuration is usually a sign that something can be improved.

The best configuration is often the one users never have to write.

A package must work alone

Every Symfinity package should provide value on its own.

If somebody installs only one package, the experience should still be worthwhile.

No ecosystem lock-in. No artificial dependencies.

Install only symfinity/font-manager or only symfinity/omnia-ipsum and you should still get a complete answer to that one problem.

A package should work better together

At the same time, packages should share conventions.

The more packages you combine, the more benefits you should get.

Not because they are tightly coupled.

Because they speak the same language.

The principle

If I had to summarize the philosophy behind Symfinity in a single sentence, it would be this:

Independent packages. Shared conventions.

That idea influences every design decision.

And it will continue to guide the project as it grows.

What's next

This article is the third part of a short introduction series to Symfinity.

For package-level deep dives already published:

Articles on further Symfinity package tiers are planned, this is just the beginning.

Explore packages and source at github.com/symfinity.

Why Symfony projects feel more fragmented than ever

Wolf — Wed, 24 Jun 2026 19:49:28 +0000

Let me start with something important.

I love Symfony

In my opinion, Symfony remains one of the best foundations for serious PHP applications.

So this is not criticism of Symfony. It is an observation about modern projects.

Symfony Is Great at Solving Individual Problems

Symfony gives us excellent building blocks—routing, dependency injection, security, forms, Messenger, Twig, the UX initiative, AssetMapper, Flex recipes, and more.

The ecosystem is huge and mature. That is a strength.

And Symfony keeps improving the glue: Flex recipes wire bundles in predictably, AssetMapper reduces frontend build-tool sprawl for many apps, and the UX packages give us shared patterns for live components and Stimulus.

Those tools genuinely reduce fragmentation within Symfony.

The side effect of success

Even with better defaults, modern Symfony projects often still stack:

Twig Components and UX packages from different vendors
Asset management and font handling from different ecosystems
Design systems and documentation tooling with their own conventions
Frontend build tooling where AssetMapper is not enough

Each piece solves a legitimate problem. But the overall picture becomes harder to understand. The project starts to feel like a collection of systems rather than a single system.

Placeholder content might come from one package, fonts from a workflow that still touches npm, UI primitives from a third library—each fine on its own, none sharing install steps or naming.

Death by configuration

The challenge is rarely one specific configuration file. The challenge is understanding where everything lives.

Which configuration belongs to which package?
What is a default?
What is overridden?
What came from a recipe?
What came from a bundle?

The more moving parts a project has, the more difficult those questions become.

Looking for Consistency

What I wanted was not less flexibility. I wanted more consistency.

The same conventions.
The same installation experience.
The same developer experience.
The same language across multiple concerns.

Symfony supplies the building blocks and much of the integration machinery.

What was still missing for me was a cross-cutting layer: packages that solve recurring app needs — fonts, placeholders, UI foundations — while agreeing on how they install, configure, and compose.

That is a different job from replacing Flex or AssetMapper.

The Symfinity Perspective

Symfinity is my attempt to create that consistency layer.

Not by replacing Symfony. Not by hiding Symfony.

But by building packages that share common conventions and integrate naturally with each other — and with the Symfony tools you already use.

Conclusion

Symfony's flexibility is one of its greatest strengths.

But flexibility also creates opportunities for fragmentation—especially across packages from different authors and eras.

The goal of Symfinity is not to remove flexibility.

The goal is to reduce friction.

What's next

This article is the second part of a short introduction series to Symfinity.

For package-level deep dives already published:

Articles on UI Kernel and the ux-blocks-* component tiers are planned.

Explore packages and source at github.com/symfinity.

This article was previously published on medium.com.

Why building Symfony-native packages instead of doing infrastructure again and again

Wolf — Wed, 24 Jun 2026 18:58:50 +0000

For years, I did what many Symfony developers do. Whenever I needed a feature, I searched for a package:

Need fonts? Go to Google Fonts and wire it up in the assets.
Need placeholder content? Add a package, implement helpers, call in Twig.
Need a frontend toolkit? Make a choice and wire it up in the assets and in Twig.
Need documentation tooling? Add another package and implement again.

None of these decisions were wrong. Most of the tools were excellent. But after building project after project, I noticed a pattern.

The same infrastructure, again and again

Every new project started with roughly the same checklist:

Fonts
Placeholder content
Assets
UI helpers
Documentation tooling
Project conventions

The business logic was always different. The infrastructure was usually the same. Yet I kept rebuilding or reconfiguring it.

Fonts often meant a separate frontend toolchain on top of PHP. Placeholder content meant yet another API shape and Twig integration to wire up. Each choice was reasonable; together they ate the first days of every greenfield.

When Symfony stops being the whole story

Symfony itself is fantastic.

Routing, Dependency Injection, Security, Messenger, Twig, Console, Events — these are not the problem.

The problem starts when a project grows.

Soon there is:

Composer
npm
Build tools
Frontend frameworks
Asset pipelines
Configuration files everywhere

Nothing is broken.

But the cognitive load keeps growing.

A different idea

At some point I stopped asking:

“Which dependency should I add next?”

And started asking:

“Why am I solving the same infrastructure problem for the tenth time?”

That question eventually became Symfinity. Not as a framework. Not as a Symfony replacement. Just as a collection of Symfony-native solutions for recurring problems.

The first packages I packaged for real use were practical ones: symfinity/font-manager for multi-format font export without leaving Composer and AssetMapper, and symfinity/omnia-ipsum for placeholder content with one Twig-facing API instead of ad hoc fixtures.

The goal

Every package should:

Solve a real problem
Feel native to Symfony
Require minimal configuration
Work independently
Integrate naturally with other Symfinity packages

A package should be useful even if it is the only Symfinity package in a project.

Conclusion

Symfinity did not start with a grand vision of building an ecosystem. It started with a simple observation: I was rebuilding the same infrastructure over and over again. Eventually, packaging those solutions became the more sensible option.

What's next

This article is the first part of a short introduction series to Symfinity.

Part 2: Why Symfony projects feel more fragmented than ever
Part 3: The rule behind every Symfinity package

For package-level deep dives already published:

Articles on further Symfinity package tiers are planned, this is just the beginning.

Explore packages and source at github.com/symfinity.

This article was previously published on medium.com.

Omnia Ipsum: Unified placeholder content for Symfony

Wolf — Wed, 24 Jun 2026 18:16:39 +0000

Rethinking fake content in Symfony projects

A prototype web page displaying pure placeholder content
When building early UI prototypes or shaping design systems in Symfony, placeholder content becomes a constant companion. Lorem ipsum text. Dummy profile photos. Placeholder videos. Silent audio. Temporary avatars. Realistic fake user data. Every project needs them — and yet most setups rely on a patchwork of libraries, links and hardcoded values.

Omnia Ipsum aims to fix that by giving Symfony developers a single, elegant toolkit for placeholder content of all kinds.

In this article, I will walk you through the motivation behind the project, the conceptual patterns it follows, and its most advanced features — all designed to make your prototyping workflow faster, cleaner and more maintainable.

Motivation: Why a placeholder library?

Most Symfony projects start the same way:

You add lorem ipsum text manually into Twig templates.
You grab placeholder images from an external service.
You generate avatars using yet another site.
You paste in temporary YouTube or stock video URLs.
You install Faker separately whenever realistic data is needed.

The result is inconsistent, fragmented and difficult to maintain.
And even worse: placeholder content often leaks into production unless guarded carefully.

The idea behind Omnia Ipsum was simple:

“If your UI needs placeholder content, it should come from one place — predictable, configurable, and accessible directly from Twig.”

This cuts down on boilerplate, cognitive overhead, and the "temporary chaos" of early-stage templates.

Quick Start

Prerequisite

Go to github.com/symfinity/recipes and follow the instructions to add the required recipe repository.

Installation

composer require --dev symfinity/omnia-ipsum

Usage

Use the Twig functions immediately:

<img src="{{ omnia_image(600, 400) }}" alt="Placeholder">
<img src="{{ omnia_avatar('John Doe', 100) }}" alt="Avatar">

<video src="{{ omnia_video(1920, 1080) }}" controls></video>
<audio src="{{ omnia_audio(10) }}" controls></audio>

<h1>{{ lorem_title() }}</h1>
<p>{{ lorem_paragraphs(3) }}</p>

<p>{{ fake('name') }} – {{ fake('email') }}</p>
<p>{{ fake_text(200) }}</p>

Everything is a Twig function

Omnia Ipsum provides a set of expressive Twig helpers:

omnia_image(width, height)
omnia_avatar(name, size)
omnia_video(width, height)
omnia_audio(seconds)
lorem_paragraphs(count)
fake('email')
fake_text(200)

Advanced Features

Multiple Image Providers

{{ omnia_image(800, 600, provider='picsum') }}
{{ omnia_image(800, 600, provider='dummy') }}
{{ omnia_image(800, 600, provider='dummyimage', background='#3355ff') }}

Automatic Avatar Generation

{{ omnia_avatar('Alice Johnson', 128) }}

Placeholder Video & Audio

<video src="{{ omnia_video(1920, 1080) }}" controls></video>
<audio src="{{ omnia_audio(5) }}" controls></audio>

Integrated Lorem Ipsum Utilities

{{ lorem_title() }}
{{ lorem_sentences(3) }}
{{ lorem_paragraphs(2) }}

Faker Integration

{{ fake('name') }}
{{ fake('email') }}
{{ fake('address') }}
{{ fake_text(120) }}

Extensible Architecture

Developers can add custom providers or extend generator logic via Symfony services.

When to Use Omnia Ipsum

Ideal for:

Design systems
Component libraries
Prototyping complex UIs
Responsive layout testing
Admin dashboards
Workshops and trainings

Conclusion

Omnia Ipsum provides a unified, elegant API for all placeholder content commonly needed in Symfony projects.

If you want cleaner templates, faster prototyping, and a more structured workflow, Omnia Ipsum is a strong addition to your toolbox.

Try it now: symfinity/omnia-ipsum

If you find it useful, star the repository and share it with your Symfony community.

What's next

Don't miss the introduction series to Symfinity:

Another package-level deep dive:

Font Manager: Multi-Format Font Export for Symfony

Articles on further Symfinity package tiers are planned, this is just the beginning.

Explore packages and source at github.com/symfinity.

This article was previously published on medium.com.

Font Manager: Multi-format Font export for Symfony

Wolf — Wed, 24 Jun 2026 18:15:42 +0000

The Problem

Typography should be one of the simplest parts of a project.

In reality, it often ends up scattered across multiple layers:

Bootstrap: $font-family-base variables
Tailwind: JavaScript configuration
TypeScript: type definitions
Design systems: W3C Design Tokens

The same font information gets copied and maintained in several places. Every update means touching multiple files, hoping everything stays in sync.

It's repetitive, error-prone, and easy to get wrong.

So I built Font Manager.

Define your fonts once and export them in whatever format your project needs — CSS, Bootstrap variables, Tailwind configuration, TypeScript definitions, design tokens, and more.

The Solution

A simple Twig function:

{{ font_manager('Ubuntu', '400 700') }}

Configuration:

symfinity_font_manager:
    export:
        formats:
            - scss_bootstrap
            - tailwind_config
            - typescript_definitions

One lock command:

php bin/console fonts:lock

Every format, automatically generated. Perfectly synced.

Bootstrap Example

Before:

// Manually copy font name
$font-family-base: 'Ubuntu', sans-serif;  // ❌ Duplication
@import 'bootstrap/scss/bootstrap';

After:

symfinity_font_manager:
    export:
        formats: [scss_bootstrap]

php bin/console fonts:lock

// app.scss
@import './assets/styles/fonts-bootstrap';  // ← Auto-generated
@import 'bootstrap/scss/bootstrap';

Bootstrap uses your fonts automatically. No manual mapping. No duplication.

Tailwind Example

symfinity_font_manager:
    export:
        formats: [tailwind_config]

// tailwind.config.js
const fonts = require('./assets/fonts-tailwind.config.js');  // ← Auto-generated
module.exports = {
  theme: { extend: { fontFamily: fonts.fontFamily } }
};

<p class="font-sans">Your custom font, via Tailwind.</p>

TypeScript Example

symfinity_font_manager:
    export:
        formats: [typescript_definitions]

import { fonts, type FontFamily } from './assets/fonts';

applyFont(element, 'sans');     // ✓ Valid
applyFont(element, 'invalid');  // ✗ TypeScript error!

Typos caught at compile time.

The 12 Formats

CSS, SCSS, JavaScript, Design Tokens — pick what you need:

php bin/console fonts:formats

CSS: Variables, Modules, @layer
SCSS: Variables, Bootstrap, Mixins
JavaScript: ESM, Tailwind, TypeScript
Design System: JSON, W3C Tokens, Figma, Style Dictionary

Build Tools

AssetMapper, Webpack, or Vite? Auto-detected.

Output paths adjust automatically. No config needed.

Design Systems

Export to Figma Tokens, Style Dictionary, or W3C Design Tokens:

formats:
    - design_tokens
    - figma_tokens

npx style-dictionary build  # CSS, iOS, Android from one source

Design once. Ship everywhere.

Privacy Options

Not just Google — choose your provider:

symfinity_font_manager:
    default_provider: 'bunny'  # GDPR-compliant, zero tracking

Google, Bunny, Fontsource, or Local. Same API. Your choice.

How It Works

Architecture: Strategy pattern. Each format is a separate exporter.

Dependency resolution: Automatic. css_modules needs css_variables? Handled.

Build detection: Scans for webpack.config.js, vite.config.js, asset_mapper.yaml.

Output paths: Adjusted per build tool. AssetMapper → assets/styles/. Webpack → assets/.

Commands:

php bin/console fonts:formats           # List all formats
php bin/console fonts:format:info scss  # Usage instructions
php bin/console fonts:export            # Export manually

Migrating from google-fonts

One command:

php bin/console fonts:migrate-from-google-fonts

Config, templates, manifest — all updated automatically.

Prerequisite

Go to github.com/symfinity/recipes and follow the instructions to add the required recipe repository.

Installation

composer require symfinity/font-manager

That’s it. Symfony Flex does the rest.

Quick Start

{{ font_manager('Ubuntu', '400 700') }}

Dev: CDN
Prod: Self-hosted (after fonts:lock)

Add exports:

symfinity_font_manager:
    export:
        formats: [scss_bootstrap, tailwind_config]

Lock:

php bin/console fonts:lock

Use:

@import './fonts-bootstrap';
@import 'bootstrap/scss/bootstrap';

Done.

Conclusion

Typography shouldn’t waste your time or violate privacy law.
With font-manager, you can design freely in development, ship safely in production, and forget about fonts altogether.

One Twig function. Multiple providers. Twelve export formats. Zero manual mapping.

That’s Font Manager.

Try it now: symfinity/font-manager

If you find it useful, star the repository and share it with your Symfony community.

What's next

Don't miss the introduction series to Symfinity:

Another package-level deep dive:

Omnia Ipsum: Unified Placeholder Content for Symfony

Articles on further Symfinity package tiers are planned, this is just the beginning.

Explore packages and source at github.com/symfinity.

This article was previously published on medium.com.

DEV Community: Wolf

When the pillars collapse one after another

What happens when life does not collapse all at once, but loses its structural support one pillar at a time?

When failure stops being isolated

The urge to rebuild

What can be carried?

UI Kernel: Design Tokens as Symfony infrastructure

The problem tokens solve

Why OKLCH matters for palettes

Contrast: WCAG today, APCA tomorrow

Tools worth bookmarking

Further reading (CSS and design systems)

From CSS files to Symfony infrastructure

Runtime theme engine (0.3.x)

Runtime switching

Scheme API

Theme shell

Overlays

Theme inheritance

Capability probe

How this stays scalable

Semantic tokens, not utility soup

One theme graph, many surfaces

OKLCH inside, CSS outside

Works with what you already run

When Tailwind or Encore still make sense

Try it locally

What's next

Don't miss the introduction series to Symfinity:

For package-level deep dives already published:

The rule behind every Symfinity package

A package must solve a real problem

A package must be Symfony-native

A package must require little configuration

A package must work alone

A package should work better together

The principle

What's next

For package-level deep dives already published:

Why Symfony projects feel more fragmented than ever

I love Symfony

Symfony Is Great at Solving Individual Problems

The side effect of success

Death by configuration

Looking for Consistency

The Symfinity Perspective

Conclusion

What's next

For package-level deep dives already published:

Why building Symfony-native packages instead of doing infrastructure again and again

The same infrastructure, again and again

When Symfony stops being the whole story

A different idea

The goal

Conclusion

What's next

For package-level deep dives already published:

Omnia Ipsum: Unified placeholder content for Symfony

Rethinking fake content in Symfony projects

Motivation: Why a placeholder library?

Quick Start

Prerequisite

Installation

Usage

Everything is a Twig function

Advanced Features

Multiple Image Providers

Automatic Avatar Generation

Placeholder Video & Audio

Integrated Lorem Ipsum Utilities

Faker Integration

Extensible Architecture

When to Use Omnia Ipsum

Conclusion

What's next

Don't miss the introduction series to Symfinity:

Another package-level deep dive:

Font Manager: Multi-format Font export for Symfony

The Problem

The Solution