Wn Test Plugin Laravel Package

Product Decisions This Supports

• Platform commitment (build vs. buy, at the framework layer): This package is Winter CMS's own executable specification of its plugin extension points — controllers, models, migrations, form/list widgets, relations, permissions, settings, and backend navigation. v3.0.0 sharpens that value: by deleting 68 controller view files and relying on the core default views introduced in Winter v1.2.8, it now documents the modern minimal-view controller pattern as the intended target state. That is a direct input to how much view-level code we should be carrying in our own plugins.
• SDK / API stability roadmap: Because core maintains this as a test fixture, the extension points it covers are the ones most likely to be regression-tested. v3.0.0 widens that covered surface — fieldset, url, and sensitive form widgets, nested datepicker inside a fieldset, grouped and simple repeaters side by side, taglist relation modes, and the fancy form layout via the new $formLayout property. Gaps in coverage remain a reasonable proxy for which APIs are less protected.
• Upgrade-cost and maintenance-debt modelling: The release is a worked example of the platform's own migration path, and the arithmetic is a product signal. Sixty-eight shipped view files became zero; per-controller BackendMenu::setContext() constructors and $bodyClass overrides were replaced by a single declarative property. Every view file we duplicate in our own plugins is now demonstrably debt against a core contract. That reframes "customize the backend UI" from a per-screen decision into a portfolio-level cost.
• QA and release-gate scoping: The conformance checklist got richer, not just larger. It now covers field grouping semantics that save as top-level fields, sensitive-input masking inside repeaters, URL suggestions, and layout selection — all behaviours worth mirroring in our own fixtures rather than inventing from scratch.
• Version-compatibility gate for our own tooling: The hard floor at Winter v1.2.8 is itself a decision input. This fixture is no longer readable as advice valid against "any Winter version," which means any internal documentation, starter plugin, or code generator derived from it inherits that floor explicitly.
• Onboarding and documentation strategy: Still substitutes for tribal knowledge — arguably better than before, since the current release demonstrates the prescribed pattern rather than a legacy one. A new engineer reading this learns the idiom we actually want, not the idiom we are migrating away from.
• Vendor and dependency risk assessment: Unchanged and still decisive — 15 stars, 0 dependents, MIT, first-party ownership. This is an internal fixture, not an ecosystem library. Vendor a version-pinned snapshot for reference; do not track it as a dependency. Note that pinning now carries a compatibility obligation (Winter ≥ 1.2.8) that a loose snapshot did not.
• Diligence flag on the release itself: v3.0.0 is a breaking major with a raised platform floor and a documented empty-render failure mode on older core. Treat any prior snapshot, excerpt, or copied pattern as needing re-verification against this tag before citing it. (The previously noted anomalous 2026 release timestamp remains unrebutted in this data and should still be checked before treating cadence as a health signal.)

It does not support end-user feature decisions, and it should not appear on a dependency inventory as a shipped component.

When to Consider This Package

Consider it when:

• You are building or maintaining Winter CMS plugins and want a single canonical reference for every supported extension point — now including the widget types and layout conventions added in v3.0.0.
• You are planning a migration off duplicated backend views and want an upstream-sanctioned end state to migrate toward, with the failure mode (empty pages on core < 1.2.8) stated in advance.
• You own a downstream distribution or theme/plugin marketplace and need regression fixtures to validate against upstream changes, including a compatibility floor.
• You are evaluating Winter CMS as a platform and need to judge plugin capability depth without a paid discovery engagement.
• You need test scaffolding for your own plugin CI and want to model it on the maintainers' own fixture.
• Your team has no internal plugin exemplar and onboarding cost is a measurable drag.

Look elsewhere when:

• You are on Winter core older than v1.2.8. The fixture's controllers now depend on core default views; ported patterns will render empty pages, and the failure is silent rather than an error.
• You need a production runtime dependency — this is a playground, and 0 dependents means no field-hardening under third-party load.
• You need documented, versioned API guarantees or a support SLA; this carries none, and the v3.0.0 breaking release is a live demonstration of that.
• You are on October CMS, plain Laravel, or another CMS — the patterns translate loosely, the code does not.
• You are selecting a starter kit or scaffolding generator for real projects; this is a fixture, not a template with upgrade paths.
• You need community support breadth — 15 stars means you are relying on maintainer attention, not an ecosystem.

How to Pitch It (Stakeholders)

For executives: This remains a zero-cost, zero-risk reference asset published by the Winter CMS maintainers under MIT — something we read and copy patterns from, never something we ship or depend on. The new v3.0.0 release strengthens the case and adds a concrete cost story: upstream deleted 68 view files and replaced per-controller boilerplate with single-property declarations, which is a direct measure of how much duplicated backend code we are carrying for no product benefit. Reading this release tells us which of our customisations are now platform-provided and can be retired. Adoption cost is a few engineering hours of analysis; downside is nil because nothing enters our runtime. The one constraint to note is a hard minimum core version, which we should confirm we meet before acting on it.

For engineering: Treat it as the upstream conformance suite for plugin development, now at a breaking major. Four things changed that matter to us: (1) Winter v1.2.8 is the floor — controllers now rely on core default views, so the 68 create/update/preview/reorder and list toolbar views are gone and these pages render empty on older core; (2) rename .htm partials to .php in anything we mirror; (3) delete the per-controller BackendMenu::setContext() constructors, $bodyClass overrides, and Pages::index()/create()/update() overrides in favour of the new $formLayout property; (4) add return type declarations to any custom File-derived model methods (getPartitionDirectory, getStorageDirectory, getPublicPath, isLocalStorage) to stay signature-compatible. The bug fixes are worth absorbing as warnings rather than copying blindly: broken $-rooted partial paths, a URL field labelled "Email", and dead doc anchors are exactly the class of defect that survives in fixtures with no third-party load — so do not assume copied examples are correct. New material worth mining for our own docs: the fieldset pattern (grouped legend, nested datepicker, still saves as top-level fields), the url field with suggestions, the sensitive widget inside a repeater, and the simple-vs-complex grouped repeater pair. Continue to pin a vendored snapshot in-repo, now pinned to this tag and to the core version floor, and keep it out of the dependency manifest — SemVer discipline is not on offer. Recommend a time-boxed spike (1–2 days) to diff v3.0.0 against whatever we previously vendored, extract the extension-point inventory and the migration checklist into our own docs, and flag which of our plugins still ship redundant backend views.