Upgrading WISECP

334 Aufrufe Markdown

Upgrading moves your installation to a newer WISECP version. The upgrade runs in steps, keeps a copy of everything it overwrites, and checks the result before handing the panel back.

Opening the Screen

The upgrade is started from Updates in the panel. That article covers the screen itself; this one covers what a safe upgrade looks like around it.

How an Upgrade Runs

An upgrade is not a single action. Each version is applied in order — download, extract, database, configuration, apply — with an optional backup in front and a finish step at the end. When you are several versions behind, every version in between is applied fully and in sequence rather than being skipped.

No step tries to finish inside one request. When its time budget runs out it records where it got to and returns, and the next call continues from there. The progress bar in the browser, the scheduled task and the command line all drive the same run, so closing the browser does not stop an upgrade that is already going.

Before You Start

A full backupTake one and verify it can be restored. The upgrade's own copy covers the last run only; anything older is a job for a real backup.

A working scheduled taskA long upgrade is continued by cron. Without it the run only advances while a browser tab is open.

Requirements for the new versionA newer release can raise the minimum PHP version or add an extension. Check before starting, not after.

A list of your own changesFiles you edited yourself are overwritten by the package. Know which they are before they disappear.

Tasks

Run an Upgrade

Take a full backup and confirm it restores.
Open Updates and read what the release changes.
Start the upgrade and leave it to run. Progress is kept on the server, so you can close the tab.
When it finishes, check the panel opens, log in, and look at a few screens you use daily.

Go Back to the Previous Version

A Go Back control appears after a completed upgrade. It restores the files the run overwrote, deleted or added.

Open Updates and use Go Back.
Read the report it produces: it names what was restored and what was left forward.

Things to Watch

Going back does not undo the database

Two things stay on the new version even after a rollback, and the report names both: the database migration that moved your schema, and the release's own configuration script. Restoring files does not reverse either. Only a full backup takes the database back.

You can go back once, and only to the last run

The control covers the most recent completed upgrade, disappears after you use it, and does not stack. If you upgraded across several versions, going back returns you to where that chain started, not to some point in the middle. Anything older is a restore from backup.

Your own edits to core files are lost

The package overwrites what it ships. Customisations belong in a module or a theme, which the upgrade leaves alone. Editing core files means redoing the work after every release.

"Skipped" is not "failed"

The health check reports a control it could not run as skipped rather than as an error. Some checks need to start a separate process, which shared hosting often blocks for web requests while allowing it for scheduled tasks. A skipped check means no verdict was reached, not that something is broken.

War das hilfreich?

Vielen Dank für Ihre Rückmeldung!

Brauchen Sie weitere Hilfe?

Unser Support-Team ist rund um die Uhr für Sie da, wenn Sie oben nicht fündig werden.

Kontakt aufnehmen Ticket eröffnen