On March 14 a new visual theme for Skład Muzyczny went live, codenamed Groove-2026. 🚀
The theme was built solo—from concept, through design tokens, to implementation and rollout (I’m not a PHP developer). 🛠️
The main goal was a bold, memorable "vintage comic" look while keeping accessibility (WCAG) and performance in check. Sounds like a standard e-commerce project? Maybe—until you look at the architecture the store runs on.
Clash of two worlds ⚔️
Day to day I work in tech like this portfolio—built on Next.js and React. Everything is a component, styles can be isolated, and the build system handles minification and optimal loading. When I need a new button, I create <Button />, pass props, use Tailwind CSS, and it just works. ⚛️
Meanwhile, for Groove-2026 I had to apply the same modern concepts (modularity, design tokens, a11y) on a platform running Symfony 1.0.19 (from 2010) with the Smarty 2.6.33 templating engine on PHP 7.4. Doing it without PHP knowledge meant extra humility and lots of “cold” work in a legacy stack. 🧩
How does that look in practice?
1. Styles and Modularization 🎨
In Next.js / React: Tailwind and CSS Modules solve scoping. Components are isolated.
In Smarty (Legacy): Before the rebuild I faced “spaghetti CSS” with 444 !important rules and a global scope. Instead of a bundler, I had to implement a layered, custom CSS loader in Smarty (_css_loader.html) with a PHP wrapper (_css_loader.php). The loader reads the current module and action from the Symfony context (sfContext::getModuleName(), getActionName()) and registers only the needed stylesheet files. The cart CSS loads in the cart, the blog CSS only on the blog, etc.
2. Variables (Design Tokens) 🧬
In Next.js / React: I define variables once in tailwind.config.ts (v3) and use utility classes across the project.
In Smarty (Legacy): I built a canonical system in native CSS on :root. Fonts (Bangers, Quicksand) are hosted locally as .woff2/.ttf for full control. Spacing, typography, and colors had to be manually unified across all 197 rebuilt template files (.html) to keep consistency and scalability for seasonal store changes.
3. Components vs. Templates 🧱
In Next.js / React: It’s state, props, and reusable view functions.
In Smarty (Legacy): A classic request–response cycle. To implement advanced accessibility—skip link to #main-content in every layout, aria-live regions for cart/search updates, full role="dialog"/aria-modal in modals—I had to modify server-generated static HTML and the built-in jQuery (v1.8.3 from 2012), carefully not breaking dozens of long-standing dependencies.
What does this rollout teach? 🤔
The biggest win here isn’t just the unique look (though those thick comic borders and heavy shadows do their job). The key is proving that modern engineering ideas (Design Tokens, modularization, WCAG) are completely framework-agnostic.
Groove-2026 shows that even on a mature, many-years-old e-commerce system you don’t have to stay trapped in tech debt. You can carry a pragmatic, rigorous engineering mindset from React into a legacy environment.
This was a solid, almost surgical operation on a live organism. And it was absolutely worth it—especially since I don’t know PHP.
Finally: the classic “works on my machine” from DEV didn’t 100% carry over to PROD. There are corners of the site where styles still don’t load—and that’s intentional: work continues, there’s stuff to fix, and the theme keeps evolving. What’s next? The plan is to move the store to Next.js with newer tech and architecture, but not yet—maybe in a while (maybe in a week 😉).