Part of the 1.7/1.8 → 2.0 migration path (see the Grav 2.0 blog plan).
system/migrate/migrate.php (new): single-file standalone wizard
extracted to a 1.x webroot by the grav-plugin-migrate-to-2 kickoff. Uses
only PHP stdlib — no 1.x or 2.0 classes are loaded. Auths against
user/accounts/*.yaml (bcrypt, super-admin required), runs preflight,
snapshots user/, extracts the staged 2.0 zip, imports content, evaluates
plugins against blueprint + getgrav.org curated compatibility, installs
decisions, runs a health check, and promotes the stage into webroot.
Common/GPM/Local/Package::inferCompatibility(): grav >= 2.0 dependencies
now resolve to ['2.0']. IndexCommand/InfoCommand/UpdateCommand gain a
magenta '2.0' badge alongside the existing 1.7/1.8 badges.
Installer/Install.php: restores the preflight machinery that was
collateral-damaged by the safe-upgrade removal. generatePreflightReport,
allowPendingPackageOverride, allowIncompatibleOverride, and the
detection helpers (detectPendingPackageUpdates, detectIncompatiblePackages,
detectPsrLogConflicts, detectMonologConflicts, readBlueprintCompatibility,
inferCompatibleVersions) are ported back so SelfupgradeCommand's
1.7→2.0 gate actually runs. inferCompatibleVersions extended to emit
['2.0'] for grav >= 2.0 dependencies. Safe-upgrade backcompat stubs
(forceSafeUpgrade, getLastManifest) untouched.
Enables the 1.7 SelfupgradeCommand to handle preflight reports from the 1.8
package's Install.php. When upgrading from 1.7 to 1.8, the command now:
- Calls generatePreflightReport() on the new package's installer
- Shows incompatible plugins with disable/continue/abort choices
- Handles pending updates, PSR/log and Monolog conflicts interactively
- Disables plugins via direct YAML config write (no RecoveryManager on 1.7)
Also adds:
- GPM Local/Package: computed compatibility property from blueprints
- CLI badges: IndexCommand, InfoCommand, UpdateCommand show 1.7/1.8 badges
The `schedule` field in backup profile configuration was never checked
when registering backup jobs with the scheduler. This meant backups
would always run on schedule even when `schedule: false` was set.
Fixes#4039