- Do I need Winter CMS installed to use winter/wn-backend-module?
- Yes. winter/wn-backend-module is the admin panel module of Winter CMS and hard-depends on the Storm module, Twig rendering, Winter's plugin registration system, and its backend auth and session conventions. It only fits when your product is explicitly a Winter CMS application or a compatible fork. In a plain Laravel app the fit is poor.
- How do I install winter/wn-backend-module?
- You do not install it directly. Require wintercms/winter in your project and the backend module arrives transitively as part of core. A standalone composer require is an anti-pattern because the module is versioned in lockstep with core and expects the full Winter stack. Run the Winter installer afterward to create the backend user and admin entry point.
- Which Laravel and PHP versions does winter/wn-backend-module support?
- Version support follows Winter CMS. The module's Composer constraints are pinned to the Winter CMS major version, which in turn pins the supported Laravel and PHP ranges. Check wintercms/winter's composer.json for the exact matrix before planning an upgrade. Backend screens and behaviors can break across Winter major versions, so pin your platform version.
- Can I use winter/wn-backend-module instead of Filament, Nova, or Backpack?
- Only if you are committing to Winter CMS as your platform. If you are building a vanilla Laravel product, evaluate Filament, Nova, Backpack, or Orchid instead, since those are composable admin packages designed for standalone Laravel. Bolting this module onto a bespoke Laravel admin is architectural drag, not integration.
- What does the Winter CMS backend module include out of the box?
- It ships base Controller, Widget, FormWidget, and ListColumn classes, plus controller behaviors such as ListController, FormController, RelationController, ReorderController, and ImportExportController. It also provides backend authentication through BackendAuth and BackendUser, RBAC permissions, navigation, the media manager, settings pages, dashboard widgets, and the LESS and JS asset pipeline.
- How do I customize backend navigation, forms, and list columns without editing the module?
- Put all customization in plugins and themes, never in the module itself, because it is a read-only split of the wintercms/wn monorepo. Use extension points such as navigation item registration, list column definitions, form widgets, settings pages, permission registrations, and dashboard widgets. If you truly must patch core, use composer-patches or a maintained fork with a named owner.
- Where do I report bugs or submit pull requests for this read-only mirror?
- Upstream, in the wintercms/wn monorepo, where issues and pull requests belong. This repository is a read-only mirror of modules/backend and may lag behind the canonical source. Any local fix requires composer-patches or a maintained fork, and you should watch upstream releases for security fixes.
- How do I handle security updates for backend authentication and permissions?
- Treat backend module bumps as platform upgrade projects rather than routine dependency bumps. This module owns backend authentication, sessions, permissions, and every admin screen, so it has the highest blast radius in the stack. Pin your Winter CMS version, follow upstream advisories, and rehearse upgrades before rollout. Consume fixes by updating Winter CMS core, not by patching the mirror.
- Can I upgrade winter/wn-backend-module independently of Winter CMS core?
- No. The module is versioned in lockstep with Winter CMS core, and there is no semver decoupled from core, no independent release cadence, and no commercial support or LTS for the module itself. Upgrade the platform as a whole and verify your plugin customizations afterward. Plan each backend bump as a platform upgrade project.
- Is winter/wn-backend-module MIT licensed and suitable for production?
- Yes, it is MIT licensed, so there is no procurement gate and licensing is favorable. Production suitability depends on Winter CMS as a platform rather than on this repository alone. Weigh the platform risks: tight version coupling, a niche community with October CMS lineage, maintainer concentration, and the read-only mirror model.