Wn Test Plugin Laravel Package

Technical Evaluation

Architecture fit winter/wn-test-plugin is not a library — it is a Winter CMS plugin (a Laravel-based CMS derived from October CMS 1.x). Its anatomy is the standard Winter plugin contract: a Plugin.php registration class, composer.json using the winter/wn-* naming convention, updates/version.yaml, migrations, models, controllers, and backend navigation/menu registrations. The description — "Playground for Winter CMS" — is decisive, and v3.0.0 reinforces it: every change in this release is either a demonstration of a FormWidget (fieldset, url, sensitive, repeaters, taglist), a reorganisation of those demos across tabs, or a migration to core-provided default views. This is a core-team fixture used to exercise plugin lifecycle and backend form behaviour, not a functional capability we would consume. As a dependency, architectural fit remains nil. As a reference implementation or scaffolding source, fit is high if and only if Winter CMS is already in our stack — and v3.0.0 is now the better reference, because it encodes current conventions rather than legacy ones.

Integration feasibility composer require winter/wn-test-plugin is technically possible (Winter resolves plugins into plugins/winter/testplugin), but it buys us nothing: the plugin contributes backend menu entries and demo forms, not business logic. There is still no public API surface, no service contract, and no documented extension points. v3.0.0 makes the dependency case slightly worse: it hard-requires Winter v1.2.8+ and removes the 68 create/update/preview/reorder/list-toolbar view files it previously shipped. Anything that installed it on an older Winter now renders empty pages. The realistic integration remains a fork-and-extract exercise, and the extraction target has shifted — the plugin is now thinner (less boilerplate to copy) but more valuable as a conventions reference ($formLayout, default views, controller-relative partial naming, typed model overrides).

Technical risk Low blast radius, non-trivial classification risk. MIT license is permissive and unproblematic. v3.0.0 resolves one open question and sharpens two others:

1. Maturity signal — reinterpreted. The release settles the "abandoned-but-stable?" question: this repo is actively maintained by the core team and tracks Winter core releases. That is not reassurance for dependency adoption — it means the package's version cadence is dictated by core's roadmap, not by consumer needs. 15 stars and 0 dependents still hold; nothing downstream has validated it as a dependency.
2. Version coupling is now explicit and hard. A major bump whose headline change is "minimum Winter v1.2.8, 68 files deleted, 68 pages blank on older core" is a textbook fixture-coupling release. Semver constraints here remain decorative in the consumer sense — v3.0.0 is not an API break for anyone, because there is no API.
3. Migration surface churn. .htm → .php partials, removal of BackendMenu::setContext() constructors, $bodyClass overrides and controller action overrides in favour of $formLayout, and added return-type declarations aligning CustomFile with the system File model. Each of these is a convention we would want in a scaffold — and each is a convention that will drift again with the next core release.
4. Release metadata remains odd. The 2026-08-26 dated tag still looks automated or generated rather than curated; v3.0.0 being a real, substantive cut softens but does not eliminate that concern.

No security concern anywhere in this release. The risk is entirely "do not mistake this for a supported package, and do not mistake its cadence for stability."

Key questions

• Is Winter CMS (or a planned Winter migration) actually in our architecture, or is this being evaluated speculatively? (v3.0.0 makes this gate harder: extraction now presumes Winter ≥ 1.2.8.)
• Does the plugin ship a test suite we can reuse as a CI pattern for our own plugins, and what does it cover? The release notes say nothing about tests — notably absent for a major version.
• Which Winter/Laravel/PHP version matrix is declared in composer.json post-bump, and how narrow is it now that 1.2.8 is the floor?
• Is the fancy $formLayout / default-views pattern stable enough to standardise on, or is it still settling in core?
• Is there any core-team commitment to supporting this repo, or is it explicitly a fixture that happens to be maintained?
• What is the actual job to be done — scaffold generation, CI reference, or a demo environment for stakeholder review?
• If we already extracted a scaffold from v2.x, does the delta to v3.0.0 justify a refresh, or do we accept the divergence?

Integration Approach

Stack fit Strictly conditional, and now version-conditional too. It fits only a Winter CMS codebase on v1.2.8 or later. If we are on Laravel proper, October CMS, Statamic, Craft, or Winter < 1.2.8, this package is out of scope and should be closed out of the evaluation backlog.

Migration path Do not add it as a runtime dependency. Two viable paths, both revised for v3.0.0:

1. Scaffold template (recommended). Fork the repository, pin to the v3.0.0 tag or its commit SHA, audit the structure, and fold the conventions into an internal plugin skeleton generator: Plugin.php, version.yaml, migration layout, lang files, test bootstrap, plus the new $formLayout controller pattern and controller-relative partial naming. Pin to v3.0.0 specifically — v2.x is now a worse template because it models removed patterns.
2. Dev-only fixture. If we need an integration test bed for our own plugin loader or CI pipeline, add it as a dev-only path repository in a throwaway Winter ≥ 1.2.8 environment, never in require.

Compatibility Verify declared constraints post-bump. The floor is Winter 1.2.8; confirm the ceiling and the associated Laravel/PHP lines. Confirm whether tests target PHPUnit or Pest and whether the plugin assumes Winter's orchestra/testbench harness — that determines how portable the patterns are to our CI. Note that the removal of 68 view files means anyone evaluating on an older Winter will see blank backend pages and may misdiagnose it as a broken package.

Sequencing

1. Confirm Winter CMS is on the roadmap and that we are on ≥ 1.2.8 (gate — stop here if not).
2. Fork v3.0.0, pin to SHA, audit composer.json, migrations, and test suite (0.5–1 day; smaller diff than v2.x given the file deletions).
3. Extract test/CI patterns and plugin structure — prioritising the $formLayout/default-views approach over harvested view boilerplate, which no longer exists here.
4. Validate the template by generating one real internal plugin against it.
5. Retire the upstream link; track our fork only.

Operational Impact

Maintenance After the one-time extraction, maintenance burden is ours and is small — a plugin skeleton is a few hundred lines. The v3.0.0 release changes the character of that maintenance rather than the volume: upstream is a maintained fixture with no consumer release discipline, so our fork is the artefact of record. Expect to revisit the scaffold whenever Winter core evolves backend form conventions again — the $formLayout and default-views migration in this release is a concrete example of conventions moving under us.

Support GitHub issues only, best-effort, by the Winter core team. No vendor, no SLA, no security advisory channel we can rely on. Acceptable for a reference artefact; unacceptable for anything on a production path. A major version with no test-suite mention and no migration guide beyond the release note bullets is consistent with fixture support, not package support.

Scaling Not applicable in the conventional sense — the plugin has no meaningful runtime load profile; it operates in the backend admin surface. The scaling question that does matter remains organisational: a scaffold derived from it scales across teams as a standard, whereas a vendored copy scales as N divergent forks. v3.0.0 raises the cost of divergence: a team on a v2.x-derived scaffold is now modelling deleted patterns.

Failure modes

• Hard version floor. On Winter < 1.2.8 the plugin's pages render empty — a silent failure that looks like a broken install rather than a version mismatch. Add a preflight assertion to any dev-only usage.
• Scaffold staleness. A scaffold extracted from v2.x now encodes removed constructors, $bodyClass overrides, .htm partials and shipped view boilerplate. Refresh or explicitly accept the divergence.
• Backend navigation and menu entries appear in admin with no business purpose — cosmetic clutter that confuses operators.
• Migration collisions if installed alongside plugins sharing table prefixes.
• Upstream drift as Winter's plugin API evolves; a fork freezes us at a known-good commit, which is the desired behaviour here.
• Accidental production install — low blast radius but non-zero: dead code in the plugin path, unowned, and invisible in dependency review because it looks like a legitimate winter/wn-* package.
• Constraint drift if anyone adds it to require and runs composer update; the v3.0.0 bump demonstrates that major versions here are driven by core compatibility, not consumer impact.

Ramp-up Low, and marginally lower than before: v3.0.0 removed 68 view files and the per-controller plumbing, so there is less surface to read. A Laravel-fluent engineer reads the plugin structure in half a day. The genuine learning value is in the current conventions — $formLayout, default views, typed model overrides, controller-relative partials — and in the test harness. Budget one engineer-day for evaluation plus extraction, contingent on Winter ≥ 1.2.8 being in scope.

TPM verdict Still do not adopt as a dependency. v3.0.0 confirms the repo is actively maintained but confirms it as a fixture — its release cadence, its hard Winter 1.2.8 floor, and its wholesale removal of view boilerplate all reflect core-team testing needs, not consumer needs. Approve a one-time, timeboxed extraction pinned to v3.0.0, gated on Winter CMS ≥ 1.2.8 being a confirmed part of the architecture. If Winter is not in scope, this package should be deprioritised regardless of its opportunity score.