laoyang/FamilyBook
1
0
Fork 0
Code Issues 29 Pull Requests Actions Packages Projects Releases Wiki Activity
145 Commits 1 Branch 0 Tags
2c44318a51317ff037eb20e337b78a4a15d1dfe9
Commit Graph
4 Commits
Author SHA1 Message Date
laoyang d6af211a8e 图片走 OSS 实时压缩：取图带 x-oss-process，本地存储不受影响 (#56) 
用户 2026-11-05：「如果图片是放在本地服务器的…就不管它。
如果是传到 OSS 里面的…就用 OSS 的压缩就行了。」

查证：OSS 图片处理确实存在，取图 URL 加 x-oss-process 即可实时压缩，
原图不动、不占额外存储。

三处改动（缺一个都会出错）：

1. OssDriver
   - get() 新增 $process 参数
   - authorization() 新增 $subresource：x-oss-process 属于子资源，
     必须计入 CanonicalizedResource，否则 403 SignatureDoesNotMatch
   - URL 拼接带上 ?x-oss-process=...

2. Storage::read()
   - 新增 $process，仅当驱动是 oss 时透传
   - 本地驱动忽略（用户明确要求「本地不管它」）
   - 带 process 时跳过"本地优先"缓存（那个缓存里是原图，
     拿原图当压缩版返回等于压缩没生效）

3. media.php
   - 新增 ?w= 参数，白名单三档 400/800/1600
   - 按尺寸分档缓存到 _proc/<w>/<key>，避免互相覆盖
   - 无 w 时行为完全不变（300+ 处既有 img 不受影响）

白名单而非透传的理由：OSS 图片处理按次计费，
放任 ?w= 任意值会让 ?w=1、?w=9999 这类请求把处理次数打上去。

实测（一张 6602 KB 的图）：
  原图  6602 KB
  w=400    26 KB   省 99.6%
  w=800   108 KB   省 98%
  w=1600  468 KB   省 93%

应用位置（保守，先动最确定的）：
  _attachments.php 照片墙缩略图 → w=400
  trips/show.php   行程题图     → w=1600
  下载链接一律不加 w（用户要原文件，不能偷偷降质）
 2026-11-05 13:06:29 +08:00
laoyang ff353b1eee v8：观影落地（MovieLog 整体迁入统一事件原语）+ 三处 UI 撤除 
- Schema v8：events / movie_details / event_attendees / event_photos 四张表，
  uk_event_source(family_id, source_ref) 作迁移幂等锚
- Movie 模型：时间线/详情/增删改、同行人整组替换、照片逐张管理、感受英→中映射
- ImageSlot 新增 poster(2:3) / ticket(free) / photo(free) 三槽位；
  free 槽位不裁剪、整图等比缩进框（只缩不放大）
- OssDriver::copyObject：同桶 CopyObject（手写 V1 签名，x-oss-* 头按字典序进签名串）
- 路由：movies 时间线/详情/新增/编辑/删除/补照片/删照片；同行人按家庭过滤；
  访客只读（requireWrite）
- UI 撤除：首页「我的一句话」、家谱页「补充我的亲属关系 / 看整个名册」两个按钮；
  顶栏加「观影」入口
- 修潜伏 bug：ImageSlot::parseRatio 的正则用 / 作分隔符，字符类里的 / 把模式
  提前截断（Unknown modifier ']'）—— ratio() 只在上传 POST 里被调到，一直没被观察到
- 线上数据迁移（临时 token 门禁页，用完即删）：MovieLog 219 条观影 → events，
  14 位观影人新增进名册（带 MovieLog 头像），431 个 OSS 对象同桶拷贝
  （movielog/uploads/<dir>/x → family/<dir>/x），review/feelings/影院三段/照片全量搬
 2026-09-30 20:22:46 +08:00
laoyang 7e9b4520c0 登录居中 · 个人 slogan · 三种生日 · 称呼视角化 · 附件统一走代理 
按九点反馈一次性改造：

1. 登录页「图标 + 用手机号登录你的家书」包进 .auth-head 并真正居中
   （以前只加了个 class 名，没有样式，看着像做了其实没做）。

2. slogan 改成两段式：系统级 slogan 作兜底，每个人可在自己的资料里写一个，
   填了就显示自己的、留空就回落到系统那句。settings 里「家庭名称」字段去掉
   （只在安装时归档，不参与展示）。

3. 三个生日：身份证生日（从证件号截取，永不改动）／真实阳历／农历。
   同一人填了其一即自动推出另一个（靠 birthday_source 指明填的是哪一侧，
   不依赖 JS）。三者落在同一天时合并成一条提醒，否则分别提醒。
   农历表不是照抄流传的那份 lunarInfo（它在 5 个年份上是错的）——
   用五个独立实现按 7.3 万天多数表决重新推导，再要求 100% 重现。

4. 称呼改成「视角属性」：nicknames(family_id, viewer_id, target_id, nickname)。
   「小明」不是某个人的属性——同一个人被不同人叫法不同，所以是「谁看」的属性。
   旧的 persons.nickname 由 Nickname::migrateLegacy() 搬到新表，只搬一次。

5. 点自己的头像/名字直接进「我的资料」，不必再绕
   「名册 → 找到自己 → 编辑资料」三步。

6. 附件（头像与其它上传）一律走 media.php 代理，不再直连 uploads/ 或云端地址：
   可读性由登录态决定而不是「知道文件名」，Content-Type/缓存/下载头由服务端统一给。
   uploads/ 整个目录 deny（含历史遗留备份文件），并有真实探针验证。

7. OSS 设置页加「连通性测试」（本地 / 云端两个按钮），逐步给出结论与耗时。

8. 生日输入改用「原生日期框 + 24 小时制时:分:秒 三个下拉」：
   datetime-local 的格式由浏览器 UI 语言决定（中文环境渲染成「下午 03:30」，
   没有秒、还容易把上下午填反）。点输入框任意一处都能弹出选择器（showPicker）。

9. 结构版本号收敛成 Schema::VERSION 一处，安装时即盖章，避免首次请求白跑升级。

验证（全部为「先注入 bug 证伪、再跑通过」）：
  php -l 42 个文件；e2e 149 条；老库升级专测 37 条；反向验证 23 个注入全被抓；
  桌面几何 108 条（768/1280/1920/2560）；移动端真机几何 212 条（360/375/390/414）；
  交互检查 49 条（生日整框可点、登录居中）。
 2026-09-30 09:44:55 +08:00
laoyang 1669ab48d0 五项家庭化改造：以个人为中心 · 家谱 · 三种角色 · 附件存储可配置 · 独立页样式 
1. 独立页（登录/安装/错误）套上 HTML 骨架 —— 修「首页为什么没有样式」：
   新增 templates/layout-bare.php，View::render 对独立页也走完整 <head> + CSS。
2. 以个人为中心：Kinship::label() 现算称呼、Auth::homeTitle() 出「X的家书」；
   同一批人在不同登录者眼里自动变成公公婆婆 / 岳父岳母（不存一次性称谓）。
3. 附件存储可配置：Storage 门面（local / 阿里云 OSS），库里只存相对键，
   云端失败自动回退本地；设置页可选驱动并填 OSS 参数（照 MovieLog 的方案）。
4. 三种角色：admin / member / guest，访客只读、写操作一律 403；
   accounts.role 枚举扩容，老库靠 Schema::ensure() 自动升级。
5. 家谱：只存相邻两代的边（parent / spouse），其余称呼全部推导 ——
   兄弟姐妹不存边（共同父母 + birth_rank 排行推长子/次女、哥哥/妹妹），
   认不清的人用虚拟人物 is_placeholder 占位，关系天然双向。

顺带修掉本地 e2e 挖出的 8 个线上级 bug（性别写死、长幼方向反、关系方向静默写反、
birth_rank 不从表单取回、隐式可空参数致响应头失效、无文件字段被误判为上传失败、
layout 变量撞车覆盖 $me、世代 0 显示成「下 0 代」）。

验证：kinship 单测 37/0 · HTTP e2e 81/0 · 老库升级专测 14/0 ·
反向验证 11/11（把每个修复改回旧写法，对应断言都会变红）。
 2026-09-30 08:13:07 +08:00