Nitra Theme Bundle Laravel Package

Getting Started

This is a Symfony2 bundle that provides a Nitra-branded theme for cedriclombardot/admingenerator-generator-bundle (the Symfony2 admin generator), not a Laravel package. If you are a Laravel developer, treat this as a reference-only artifact — the patterns are Twig/YAML/DI driven and will not drop into an Eloquent/Blade codebase.

Minimal steps to evaluate or resurrect it:

1. Require both the generator and the theme in a Symfony2 (2.8-era) project:

   composer require nitra/nitra-theme-bundle
   

   You will almost certainly need "minimum-stability": "dev" and to pin Symfony to ~2.8, because the bundle predates Symfony 3 and has no tagged compatibility.
2. Register it in app/AppKernel.php:

   new Nitra\ThemeBundle\NitraThemeBundle(),
   

   Ensure AdmingeneratorGeneratorBundle is registered as well.
3. Point the admin generator at the theme in your config.yml (or per-module generator.yml) under the admingenerator / theme node, typically theme: nitra.
4. First use case: scaffold one admin module for an existing Doctrine entity and inspect the rendered list/edit views — the theme's value is entirely in its Twig templates and CSS/JS, so verify those load before touching anything else.

Where to look first: the bundle's Resources/views/ tree (the actual theme), its Resources/public/ assets, and DependencyInjection/ for the service/parameter names it expects the generator to consume.

Implementation Patterns

The theme only does something useful once the admin generator is producing CRUD pages, so the day-to-day workflow is generator-first:

• Theme selection per module. Keep the global default in config.yml, then override theme: nitra in individual generator.yml files where you want the Nitra look without disturbing other modules.
• Template override precedence. Rather than editing vendor files, mirror the theme's Twig paths under app/Resources/AdmingeneratorGeneratorBundle/views/ (or your app's bundle override path) so per-project tweaks win over the bundle. This is the standard Symfony override chain and the only sane way to customize an unmaintained bundle.
• Block-level customization. The theme templates are built around Twig {% block %} sections (form, list, filters, actions). Extend the theme's base template and override individual blocks instead of copying whole templates — it keeps upgrades (if any ever come) tractable.
• Asset pipeline. The Nitra theme ships CSS/JS (and historically LESS). Run assets:install --symlink and whatever preprocessor step the bundle documents; then assetic:dump if you're on the Assetic era. Plan for this step to be manual and fragile.
• Generator config as the integration surface. Configure columns, form types, filters, and batch actions in generator.yml; let the theme own presentation. Don't cross the streams — business/presentation logic in the theme templates is where this package rots fastest.
• Composer pinning. Wrap the dependency in your own composer.json constraints and commit composer.lock; there are no stable releases to fall back on, so reproducibility depends entirely on you.
• Fork-and-vendor if you must ship. Given zero stars and zero dependents, the realistic production pattern is to fork it into your own VCS namespace, patch Twig/Symfony compatibility, and depend on your fork.

Gotchas and Tips

• Abandoned and unmaintained. Zero stars, zero dependents, no score — assume no security fixes, no PHP 7/8 support, no Symfony 3+ support, and Twig APIs that were removed years ago. Budget for a migration or a rewrite rather than "fixing" it.
• Not a Laravel package. No service provider, no facades, no Blade. Any instructions implying php artisan are wrong for this repo.
• Twig version mismatch is the #1 breakage. Templates written for Twig 1.x will throw on {% spaceless %}, deprecated filters, and changed form_theme semantics. Pin Twig or patch templates.
• Silent theme fallback. If the theme name doesn't resolve, the generator quietly falls back to its default theme — you'll debug "my Nitra styles disappeared" for an hour before realizing the theme name is misspelled or the bundle isn't registered.
• Override path confusion. Symfony resolves app-level overrides only if the path mirrors the bundle name exactly (AdmingeneratorGeneratorBundle vs. the theme bundle name). Get the casing right.
• Asset staleness. Cached/compiled assets from a previous assetic:dump will mask template changes. Clear app/cache and re-dump after any theme edit.
• Extension points are shallow. There is no meaningful DI configuration to tune — the bundle's surface is essentially templates plus assets. If you need behavior changes, you're overriding templates or the generator's own services, not this bundle.
• Debugging tactic. When a page renders wrong, bin/console (or app/console) debug:twig on the resolved template path — it tells you instantly whether the Nitra template, your override, or the generator default is winning.
• Recommendation. Evaluate it only as a reference for Twig theming patterns; do not adopt it for new work. If you need an admin UI today, use EasyAdmin/Sonata (Symfony) or Filament/Nova (Laravel) instead.