Weave Code
Adminata Laravel Package
idct/adminata
Adminata is a Laravel package for admin data management, offering utilities to organize and expose backend data for administrative interfaces. It integrates with Eloquent models to streamline common admin panel tasks.
At a glance
Frequently asked questions about Adminata
- Is idct/adminata a Laravel package?
- No. idct/adminata is a Symfony bundle (IDCT\Adminata) that hard-forks the Sonata Admin stack, including admin, block, doctrine, exporter, form, and twig extensions. It has no Laravel service provider, no Eloquent integration, and no Blade views. Any Laravel framing in a ticket should be treated as a mislabel and re-routed to a Symfony team.
- Can I use Adminata in a Laravel application?
- In practice, no. The bundle depends on Symfony's DI container, event dispatcher, Doctrine ORM, Twig, and Symfony Form/Security, none of which map cleanly to a Laravel stack. Composer might resolve it in isolation, but there is no adapter layer, so you would be building an integration from scratch. For Laravel admin panels, use a Laravel-native package instead.
- How do I install idct/adminata?
- There is no documented install guide. The intended path is a Symfony application: require idct/adminata with Composer, register the bundle in config/bundles.php, and port the Sonata configuration keys to the fork. Because the package declares a conflict with the Sonata packages it forked, you must remove sonata-project/* first. Treat installation as an atomic cutover on a spike branch, not a gradual adoption.
- Which Symfony and PHP versions does Adminata support?
- The repository does not publish a supported version matrix. Since it is a hard fork of Sonata Admin, you should expect Symfony 6.4/7.x and PHP 8.2+ to be the realistic targets, but verify composer.json constraints yourself. Also check whether all six forked bundles are released in lockstep, because mismatched constraints can break resolution.
- Why does Adminata conflict with sonata-project packages?
- A hard fork keeps the same service IDs, DI aliases, config keys, and template inheritance chains under a new namespace, so it cannot coexist with upstream Sonata. The package declares the conflict explicitly to force Composer to choose one stack. That makes integration an atomic swap: you cannot co-install both for side-by-side comparison or gradual migration.
- What license does idct/adminata use?
- The repository metadata reports NOASSERTION, which means legal cannot approve it without clarification. Upstream Sonata is MIT, and a fork must retain the original copyright and license notices. Ask the maintainer to publish an explicit license file before any production use.
- How do I migrate from Sonata Admin to Adminata?
- Start on a spike branch and replace sonata-project/* with idct/adminata, then swap Sonata\AdminBundle\... references to IDCT\Adminata\.... Port config/packages/sonata_*.yaml to the fork's keys, re-register admin services and tags, and re-point templates. Expect a non-trivial sweep of attributes, DI aliases, and route names, and keep Sonata pinned on main as a fallback until the fork proves out.
- Does Adminata preserve AbstractAdmin, security voters, and exporter contracts?
- The fork is intended to preserve Sonata's surface under a new namespace, but that is unproven. Hard forks routinely leak Sonata\ references in DI aliases, service IDs, config keys, attributes, and template chains. Validate AbstractAdmin, AdminInterface, security voters, filters, custom form types, and the Exporter/Block contracts with a low-risk CRUD admin before scheduling a full migration.
- Is idct/adminata production-ready and actively maintained?
- There is no production signal: zero stars, zero dependents, and no documented CI or test coverage. It is a single-vendor hard fork, so every upstream Sonata security patch must be manually re-applied, and the Tailwind v4/TailAdmin layer adds a second upgrade treadmill. Assign an internal owner with real Symfony depth and keep a fallback plan.
- What are alternatives to Adminata for an admin panel?
- For Symfony teams already on Sonata Admin, staying on upstream Sonata or evaluating EasyAdmin is lower risk than a zero-adoption hard fork. For Laravel teams, use Laravel-native tools such as Filament or Nova rather than forcing a Symfony bundle. If you need Sonata's model, wait for the fork to publish a license, version matrix, and sync policy.
Weaver
How can I help you explore Laravel packages today?