Patches and interrupted updates

File-level patches (1.1.0)#

When one file changes, installations take just that file instead of a forty-megabyte archive. The panel lists every file a patch would replace, with its SHA-256, before it is applied (AACP → Updates → File patches). The cp:patch command prints the pending patch and writes nothing; applying requires --apply and asks for confirmation in an interactive session. Patches apply as a chain: only the patch that upgrades from the running version is offered. Safety rules: The security layer.

A half-finished update (1.1.1)#

What went wrong. Updating to 1.1.0 from the panel was interrupted on a live installation: CoreUpdater did not lift PHP's time limit, so writing several thousand files hit max_execution_time. A time-limit fatal cannot be caught, so the rollback and the cache clear never ran, leaving some new files, some old files and a compiled container describing neither. The visible symptom was a 500 about a constructor signature.

Fixes

• set_time_limit(0) and ignore_user_abort(true), so the job finishes even when a gateway times out at 60 seconds.
• A marker file is written before the first file is overwritten: which version, where the staged files and the backup are, how many files are in scope.
• A shutdown hook that runs even on a time-limit fatal and clears the compiled container so the site can show the recovery screen.
• Resume / Roll back in a red card at the top of the panel. Resume copies the staged files again; Roll back restores the backup and removes files the release added.
• An interrupted update blocks starting another one, which would overwrite the backup, the only way back.

If an installation is half-updated: upload the 1.1.1 package over FTP, empty the contents of cp-core/var/cache/prod/ (keep the folder), and when the panel opens choose Resume if a recovery card shows.

The patch installer's own bug (1.1.3)#

What broke. Applying 1.1.2 took the site down with ArgumentCountError ... ForumReputationService::__construct(), 6 passed ... and exactly 7 expected: new class file on disk, old compiled factory in the cache.

Why. The kernel cache purge is deferred to shutdown on purpose. From the moment apply() returns until the response is flushed, all code that still runs is new class files going through the old container, and the patch screen ran the whole update planner and rendered the full page in that window.

Fixes

• Success is now a redirect and nothing else; the next GET is served by a container rebuilt from the new code, and the patch log survives the redirect.
• A failed purge is no longer silent. The purge counts leftover compiled factory files and, when it did not work, writes cp-core/var/update/cache-purge-failed.json; the updates screen reads it and says so in red. This matters most on shared hosting, where the cache directory may belong to another user.

Stuck on 1.1.2? Delete everything inside cp-core/var/cache/prod/ over FTP (keep the folder), then open the site. If OPcache runs with opcache.validate_timestamps=0, restart PHP from the hosting panel too.