Current Install, Update & Rollback

Release step8-final-rc2. Use an isolated authorised staging copy first. No live deployment is included.

Fresh installation

• Choose a maintained provider-supported PHP>=8.3 and MySQL/MariaDB InnoDB/utf8mb4 branch; verify the complete host checklist and final application tests. PHP source/vendor-build numbers here are compatibility evidence only.
• Put only php_application/public_html contents in the public document root. Keep private code, configuration and storage outside it. Configure the existing private bootstrap path for the selected layout. Never expose this whole package.
• Create a temporary migration-capable DB account and a separate runtime SELECT/INSERT/UPDATE/DELETE account; no runtime CREATE/ALTER/DROP/GRANT. Privately create app_key/backup_key and independent key custody. Copy config.example.php privately; keep preview/setup disabled/release flagsfalse/notificationsfalse.
• Use private console install with privately prepared owner input, or the existing one-time panel setup workflow under independently secured staging. No Composer/serverNode/SSH is required by the application; vendored PHPMailer is bundled. Follow existing no-terminal setup/recovery instructions.
• Apply ordered migrations001,002,003; seed once only. Verify17 pages/710 blocks/59 shared/13 media/5 gallery and22 tables/198 columns. Close installer, remove temporary setup key and drop migration credentials from runtime configuration.

Existing database — never reseed

• Preserve old release files, private config/settings, current DB/media and latest deletion/note-suppression checkpoint. Create independent encrypted backup and rehearse restore. Suspend receiving/keep preview during changes; do not clear safety flags to force a release.
• Review Current_Source_Comparison.json and migration003.001/002 checksums must match the existing migration ledger. Apply only missing003 using a temporary migration credential. DDL is not transactionally rollbackable in MySQL; a partial or mismatched table requires private inspection and repair before proceeding.
• Terminal option: AS_CONFIG must point to the PRIVATE migration configuration, then run private/bin/console.php migrate. Remove the migration credential afterward.
• No-terminal option: in private host-panel phpMyAdmin, inspect schema_migrations and table absence/shape first. Use tools/manual_migration_003.sql on isolated staging, compare all14 columns/indexes/FK with the dictionary, then record its exact checksum. Never overwrite an existing mismatched checksum or run initial001 on populated content.
• Deploy reviewed application files to staging with configuration preserved. Sign in as the actual owner; choose Approved content update. It requires current authentication and CSRF. Review the plan, then Create protected update drafts. It refuses stale plans, an existing private draft or changed affected public content.
• CLI alternative: release-plan prints a nonsecret plan; release-apply receives private actor_id and plan_hash JSON on stdin. Only an active owner is accepted; it creates drafts only. No account/enquiry seed operation is used.
• Ten affected page drafts use stable keys/anchors. Shared draft patches only five approved social destinations and adds an empty Telegram field if absent; it preserves unrelated settings. If the old baseline differs, merge the supplied page-wise current copy through normal CMS fields rather than forcing the update.
• Compare/preview drafts and publish through normal owner controls. Publish the shared contacts draft separately. Publishing shared content changes the consent notice revision; re-review the linked operational privacy policy before receiving. Verify Home/About share the supplied portrait record and exact image-source hash. New media imports remain private until a published reference exists.

Routine management

Use Pages & services for ordinary blocks/cards/lists/FAQ pairs/CTAs/SEO and order controls. Use Contacts & navigation for explicit URLs, optional Telegram destination and navigation drafts. Use Images & placements for upload/metadata/crop/selected-use replacement; Gallery for categories/order/Illustrative labels. Owner previews/publishes and can compare/rollback retained revisions. No JSON-only editing is required.

Core routes/stable anchors/protected disclosures remain protected. New business logic, integrations or calculator changes require a developer. Replacing a portrait uses a real owner-approved image classified by the owner; generated context cannot become a portrait or genuine record.

Rollback and restoration

• Content-only rollback: select the appropriate retained revision, review and publish through owner controls. Added stable anchors cannot be removed through ordinary editing; preserve or hide them when adapting an older revision.
• Application rollback: retain old release and compatible003 table without destructive down-migration. Do not delete the notification table or erase enquiry evidence to roll back code. Disable notification processing while investigating; never auto-resend restored queues.
• Database restore: use the matching encrypted backup/key plus LATEST independent deletion/note-suppression ledger and current staff revocations. Restore in isolated preview, verify integrity and suppression, then re-establish all release gates. Restored unsent notifications become Held for owner review. Sent means SMTP acceptance only; do not resend blindly.
• Any failed restore keeps restore-incomplete/receiving-suspended intact. Repair and re-test the cause. No achieved production RPO/RTO is claimed; actual custody and measured recovery remain G04 inputs.