CMS选型一时爽,维护起来火葬场，SilverStripe这货，在澳洲和新西兰用得挺多，国内玩的人少，文档全靠英文，社区也不像WordPress那么热闹，我接手的项目里，十个有八个是前任开发者跑路留下的“烂尾楼”，今天不聊虚的，就说说我这几年在SilverStripe上真金白银换来的教训，还有那些能让你省下几个周末的干货。
第一个坑：别迷信“自动生成数据库”
SilverStripe最吸引人的就是它那套ORM,改个$db字段，刷新页面就自动改表结构，爽得一批，但注意，这只是“开发模式”下的福利，有一次我图省事，直接在服务器上开了SS_ENVIRONMENT_TYPE=live，然后升级一个模块，结果前端直接白屏——因为数据表结构没更新，而live模式下不允许自动建表，你查日志才发现，报错全是“Column not found”。
SilverStripe建站五年，我踩过的那些坑，希望你一个都别踩
解决办法？在部署脚本里加上silverstripe/vendor/bin/sake dev/build flush=all，而且一定要用--quiet参数，防止交互式确认卡住CI，更保险的做法是：先跑dev/build在本地或staging环境，确认无误后，再到生产环境手动执行一次，最后再切live模式，别嫌麻烦，这步省了，维护成本翻倍。
第二个坑：模板缓存把老子害惨了
SilverStripe的模板编译后缓存在var/cache或者public/resources里（版本不同位置不同），有一次我改了个.ss模板，刷新页面纹丝不动，以为是浏览器缓存，清了缓存还是没变化，最后发现是旧版本的SilverStripe把编译后的PHP文件存在var/cache，而服务端OpCache又把那些PHP文件缓存了，双重缓存，直接让你怀疑人生。
解决方案：开发环境直接禁用OpCache，或者在php.ini里设opcache.validate_timestamps=1和opcache.revalidate_freq=0，生产环境部署完，记得执行flush=1，并且重启PHP-FPM（systemctl restart php-fpm）——这招虽然简单粗暴，但比你在后台点“清缓存”按钮靠谱一万倍，SilverStripe 5.x开始，模板缓存已经挪到public/_resources，记得把该目录权限设为www-data:www-data，否则部署时都没法写。
第三个坑：模块冲突，尤其是那些“推荐”模块
官方市场上一堆模块,看着都挺好，一装上就翻车，我印象最深的是装一个silverstripe/spamprotection，它默认引入silverstripe/akismet，结果跟表单验证的silverstripe/recaptcha冲突，前端JS直接报错，表单提交后数据全丢了，后来我索性自己写了个简单的蜜罐字段，才彻底解决。
推荐配置：别贪多，能用核心功能就不用模块，我现在的标准配置就这几个：
silverstripe/framework+silverstripe/cms（核心，必装）silverstripe/asset-admin（虽然4.x后自带，但确保版本匹配）silverstripe/versioned（管理草稿和发布，一定要开）bringyouridea/silverstripe-sitemap（生成XML sitemap，比手写Robots强多了）lekoala/silverstripe-spam-protection（轻量，不依赖外部服务）
第四个坑：部署权限混乱，导致图片上传失败
SilverStripe的public/assets目录默认要可写，但很多新手直接chmod -R 777，结果被黑客挂马，我见过一个客户站点，整个assets目录被塞满了恶意PHP文件，就是因为权限设太宽，正确做法：目录属主设为www-data，权限755，文件644，对于上传目录，可以用chmod 755加上ACL控制，如果使用Git部署，千万别把assets目录纳入版本控制，用.gitignore排除。
还有一个隐蔽坑：SilverStripe的public根目录下如果有个index.php，它内部会用BASE_PATH常量，如果你把站点放在子目录（比如/blog），一定要在public/.htaccess里正确设置RewriteBase，否则后端链接全部404，我当年给客户做一个多站点，就是卡在这，最后在_config.php里手动定义BASE_PATH才解决。
第五个坑：长期维护，数据库备份恢复全是泪
SilverStripe的数据库结构随着版本升级变化很大,从3.x升到4.x，SiteTree表一堆字段被重命名，外键约束也变了，我接过一个项目，原开发者用3.5，用了N多自定义字段，升级时直接跑dev/build，结果一堆数据丢失，因为字段类型从Varchar改成了Text，数据没丢，但索引全没了，查询慢成狗。
长期维护建议：
- 每次升级前,先用
phpunit跑一遍现有测试，没有测试的话，至少手动把核心流程走一遍。 - 数据库迁移别直接在生产库上跑,先备份，然后本地模拟升级，用
silverstripe/vendor/bin/sake dev/build跑完，检查_caret和_obsolete表的变化。 - 定期用
silverstripe/maintenance模块检查文件完整性，特别是composer依赖是否健康。 - 备份策略：除了服务器快照，每天用
mysqldump导出SQL，保留最近7天，恢复的时候用mysql命令导入，然后跑dev/build——如果不跑，那些自定义表的关联会乱掉。
最后一句话
SilverStripe不是不行,但它的学习曲线比WordPress陡得多，坑也多得多，如果你不是长期用它，那就别碰；如果你决定用了，一定要把这哥们当回事，把部署流程文档化、脚本化，千万别用“手动改服务器”这种原始方式，所有自动的方便，在维护时都会加倍还回来。
，都是踩坑踩出来的，希望你看了之后，能少走几步弯路，省下时间和预算，多陪陪家人。
发表评论