Upgrading
Upgrading wonderpress-core
wonderpress-core is a Composer dependency of the theme, declared in wp-content/themes/<theme>/composer.json and pinned by the lock file beside it. Both the lock file and vendor/ are committed, so a deploy needs no Composer step and a checkout is reproducible without one.
To take a new core:
cd wp-content/themes/<theme>composer update wndrfl/wonderpress-core
Commit the resulting composer.lock and vendor/ changes. Nothing installs into wp-content/mu-plugins, and nothing needs a CLI bump. The version constraint lives in the theme’s composer.json and nowhere else; the CLI names the package and deliberately does not restate a version, so the two cannot drift.
Migrating a site that predates core 2.0.0
Sites scaffolded before 2.0.0 carry core in wp-content/mu-plugins/. WordPress loads mu-plugins long before any theme, so on those sites the old copy always wins: by the time the theme’s newer copy in vendor/ loads, the old one has already declared its functions, and PHP cannot redeclare them.
That matters more than it sounds. The 2.0.0 theme no longer carries the asset pipeline or the baseline theme supports itself; it expects the package to provide them. An old copy winning therefore means no compiled CSS or JS and no supports: a site that breaks quietly, in a place nobody would think to look.
So core detects it and says so. When the copy that won is older than the one that stood down, an admin notice names both versions and the path to delete.
To migrate: delete wp-content/mu-plugins/wonderpress-core*. There is nothing to move; the theme already carries its own copy in vendor/.
Upgrading the CLI
npm install -g @wndrfl/wonderpress-cliwonderpress version
The CLI’s @wndrfl/static-kit-cli dependency range is the coordination point between the two projects, released in lockstep, so upgrading the CLI also advances the Static Kit tooling used for new scaffolds. Existing static/ trees in your projects are untouched until you act on them; the partial manifests record the exact paths that were created, so partial remove keeps working across layout generations.
Checking what you are actually running
which wonderpress && wonderpress version && npm ls -g @wndrfl/wonderpress-cliA linked development install shows an -> and a path. If you contribute to the toolkit itself, the contributor workflow (npm link, core ref overrides with WONDERPRESS_CORE_REPO, packaging checks with npm pack) is documented in the wonderpress-cli repository.