- What is winter/wn-system-module?
- It is the System core module of Winter CMS, the October CMS fork, published as a read-only split of the Winter monorepo. It bootstraps and governs a Winter installation: module service provider registration, the plugin manager, settings persistence, the asset pipeline, backend widget scaffolding, update and migration tooling, translations, mail wiring, and the winter:* console commands. It is not a general-purpose library for standalone Laravel apps.
- Can I install winter/wn-system-module in a plain Laravel app?
- No. It hard-depends on winter/storm and expects the Winter boot cycle, database and model conventions, and backend scaffolding. Dropping it into vanilla Laravel or Lumen is a port, not an integration. If you are not already committed to Winter, use a plain Laravel admin package instead.
- Which Laravel and PHP versions does winter/wn-system-module support?
- The module is only correct in lockstep with the Winter release line it ships with, so its PHP and Laravel constraints come from the parent Winter metapackage. Check the composer.json of the exact Winter release you pin rather than inferring limits from this split repository. Do not hand-pin the module independently.
- How do I install winter/wn-system-module?
- You normally do not install it directly. Scaffold a Winter project with the official skeleton via composer create-project, and wn-system-module arrives transitively with its sibling modules at compatible versions. A direct composer require is reserved for edge cases and risks version skew.
- Should I require winter/wn-system-module directly in composer.json?
- No. The practical rule is to require the Winter core project skeleton and let the split packages resolve as a matched set. Requiring the module by hand invites drift from winter/storm and the rest of core. If you must reference it, pin it through the parent metapackage.
- What is the difference between winter/wn-system-module and winter/storm?
- Storm is the October-derived foundation providing behaviors, extendable classes, the event emitter, and database and model conventions. System sits on top of Storm and governs the running CMS: plugin management, settings, assets, updates, migrations, and backend scaffolding. You need both inside Winter, and neither is useful outside it.
- How do I upgrade winter/wn-system-module safely in production?
- Upgrade the whole Winter install, not the module in isolation, because System touches boot, settings, assets, and updates. Test the bump in staging against your plugins and custom backend customizations first. Keep an explicit pin-and-patch policy and treat a bad bump as an installation-wide risk, not a single-feature regression.
- How do I test a plugin that depends on the System module?
- Test inside a real Winter installation, since the module needs the full boot cycle, Storm, and the backend scaffolding to function. Use the official skeleton for a local development environment and exercise the public APIs your plugin consumes, such as PluginManager, SettingsManager, AssetManager, and VersionManager. Do not expect the module to work in a bare Laravel test harness.
- Is winter/wn-system-module compatible with October CMS, or is it a drop-in replacement?
- Winter is a deliberate fork of October CMS with a documented migration path, not a drop-in swap. Expect code touches around namespaces, configuration, and any October-specific plugins you depend on. Moving from a custom Laravel app is effectively a rewrite of the admin surface, so budget accordingly.
- What is the maintenance and exit risk of winter/wn-system-module?
- The split repo has no independent consumer base, changelog, or release cadence, and the maintainer pool and ecosystem are small relative to Laravel-first CMS options. Version coupling is strict, so upgrades must be driven by the parent Winter metapackage, and upstream fixes land in the monorepo rather than this mirror. If you patch locally you own a fork permanently, so plan for EOL and estimate porting cost before committing.