浅念
601451f22b
Overlay ~150 upstream items onto our V8.12 base, preserving trade-pro
theme, registry tests, and design docs. Re-applied our patch set
(discovery/env_for/blocks.css/type-mapping/theme_color/frontend entries,
test_theme_pro_v3 mods) — all anchors survived upstream evolution.
New platform enhancement (fixes upgrade-introduced regression):
multilingual.site_locale now honors settings_json.locale, plus
PUT /api/i18n/sites/{id}/locale — standalone English sites get
<html lang='en'> under the V8.15 locale-rewrite pipeline.
compose: adopt V8.21.3 (image 8.21.3-dev.1, /api/ready probes, MySQL/S3
env) with project name pinned to siteforge-v8-10 (data volumes).
Tests: 356 passed / 11 failed — all 11 confirmed pre-existing in
pristine V8.21.3 on this host (10 upstream Windows env + our build test
now green after locale fix). Patch registry updated in plan doc.
Co-Authored-By: Claude Code <noreply@anthropic.com>
6.0 KiB
SiteForge Enterprise V8.18 — 企业底座实现与验收说明
2026-10-23 · 版本
8.18.0-dev.1· 开发集成版（不是生产上线批准）
本轮已实施代码
- PostgreSQL 灾备误操作保护：当
SITEFORGE_DATABASE_URL指向 PostgreSQL，原 SQLitepython -m app.backup立即拒绝执行，不会错误创建一份空 SQLite 备份。 - PostgreSQL 专属离线灾备：
app.pg_disaster_recovery+scripts/pg_disaster_recovery.py使用客户端pg_dumpcustom 格式、pg_restore --list、媒体/构建文件清单和 SHA-256 校验，最后原子更名 ZIP；离线校验无需数据库。恢复仅允许空 PostgreSQL 数据库 + 不存在的数据目录，使用单事务pg_restore，不覆盖线上站点。机密信息不会放在子进程命令行参数中。 - SQLite→PostgreSQL 内容迁移：
app.sqlite_pg_transfer+scripts/migrate_sqlite_to_postgres.py：SQLite 在线备份 API 制作快照（前提仍要求业务停写），按外键顺序处理当前 51 张表，检查列覆盖和目标表为空（迁移登记表例外、必须 checksum 匹配），单 PostgreSQL 事务写入，逐表行数与 SHA-256 对账。目标库必须在停机维护期间运行全套初始化。 - 发布状态不确定时防重复执行：
remote_deploy/remote_rollback在 Worker 租约过期、网络失败、超时或运行中取消后标记失败并要求管理员核对远端指针，禁止自动重试外部副作用。普通构建仍保留原有重试能力。 - CI 验收扩充：新增隔离 PostgreSQL 数据迁移端到端验证脚本；本地测试使用模拟 PG 协议和工具进程，并且严格区分模拟与真实 PG 证据。
一、禁止直接更新生产卷
新建独立测试环境，备份 V8.17 的数据库和共享存储。切换 SQLite→PG 是运维迁移而非自动覆盖 .env：不能仅把 SQLite 环境变量指向 PostgreSQL 后直接运行现有容器。系统代码、数据库、媒体目录和 published 卷是不同组件，必须统一维护窗口。
二、PostgreSQL 备份（维护窗口）
以下命令在有 pg_dump、pg_restore、psql 的管理主机执行；客户端版本应不低于数据库服务器主版本（示例 PG 16）。须先停 Web 和所有 Worker，阻止数据库写入与媒体上传。
export SITEFORGE_DATABASE_URL='postgresql://backup_user:***@db-host:5432/siteforge?sslmode=verify-full&sslrootcert=/secure/ca.pem'
python scripts/pg_disaster_recovery.py backup --data /path/to/siteforge-data --output /external/backup-20261023.zip --confirmed-offline
python scripts/pg_disaster_recovery.py verify /external/backup-20261023.zip
不要把真实密码写到共享日志或 shell 历史；上例为占位符。建议使用安全的环境注入或管理员端凭据文件。manifest.json 的 SHA-256 证明读取后的完整性，不证明备份来自可信发布者，也不代表进行了加密。备份需转移到其他设备，配置保留策略和访问限制；published 独立卷还需要独立备份。
恢复必须事先创建空 PostgreSQL 目标库和不存在的共享数据目录，并使用新测试实例恢复验证：
python scripts/pg_disaster_recovery.py restore-new /external/backup-20261023.zip --data /path/to/new-storage --confirmed-offline
不会自动切换服务或覆盖目标数据库。恢复后需再跑 /api/ready、内容/媒体、构建和发布链路的 E2E。数据库恢复和文件重命名跨系统不属于一个原子事务，失败时目标必须保持隔离，直到人工对账完成。
三、SQLite 数据升级到 PostgreSQL（数据库部分）
- 停站：关闭 Web、所有 Worker、文件上传与计划任务，确保 SQLite 和媒体不再变动。
- 双重备份：运行既有 SQLite 备份与源文件目录副本；将外部备份单独存储。
- 全新 PostgreSQL 库：使用独立新库运行完整 SiteForge schema 初始化；允许 ledger 的既定行，其他业务表必须为空。
- 迁移数据：
export SITEFORGE_DATABASE_URL='postgresql://migration_user:***@db-host:5432/siteforge_stage?sslmode=require'
python scripts/migrate_sqlite_to_postgres.py --source /path/to/old/siteforge.sqlite3 --confirmed-offline --report /external/migration-evidence.json
- 同步外部文件：
/data/media、legacy、builds、archives与published卷独立同步/校验（迁移工具不会代替 rsync/对象存储迁移）；不要把两个新旧服务同时指向可写目录。 - 验证：逐表行数/哈希、媒体 URL、静态质量报告和线上正式域名一致性；如有失败保持旧站继续服务。
- 切换：预生产全部通过后再人工批准业务切换，保留源库与可回滚路径。
工具对旧 SQLite 数据库进行只读备份快照；向新 PostgreSQL 写入是显式 --confirmed-offline 才能执行的操作。导入使用单事务；建表（初始化）先于该事务，不等于整个目标库已经过生产级迁移验收。
四、多 Worker / Redis
PostgreSQL 是权威任务队列，Redis 只负责唤醒通知；Redis 不可用时 Worker 回退数据库轮询，不能把 Redis 看作持久化任务存储。V8.18 对发布任务加上“结果不确定则不重试”防护，但未获得真实 Docker 2+ Worker 并发、断电、丢包和故障切换证明，不能宣布多实例高可用。
五、本轮验收证据限制
本地环境未安装 Docker Engine、PostgreSQL 客户端或 psycopg，无法声称完成真实 PG/Redis Docker 验收。新增脚本和自动化测试提供代码及 CI 入口；应在 GitHub Actions 隔离 postgres 服务上实际运行 scripts/verify_pg_bootstrap.py 和 scripts/verify_sqlite_pg_transfer.py，保存日志，然后在运维侧完成正式恢复演练。
六、尚未关闭的 V9.0 要求
Art Design Pro 官方前端完整工程编译集成、复杂 WordPress 插件迁移、企业 SSO/MFA、长期容灾、同域路径多语言、真实服务器发布验收，以及完整移动端体验均仍在后续工作范围内。