精简 WordPress 仪表盘，但不要关闭安全更新

早期版本建议通过过滤 transient、移除检查 action 和关闭自动更新来“保持稳定”，这会让站点错过安全修复，也让管理员看不到真实风险。现代做法是精简无关仪表盘组件，同时建立可回滚的更新流程，而不是让更新系统失明。

安全地移除仪表盘组件

<?php
add_action(
    'wp_dashboard_setup',
    function (): void {
        if (
            current_user_can( 'manage_options' )
        ) {
            return;
        }

        remove_meta_box(
            'dashboard_quick_press',
            'dashboard',
            'side'
        );
        remove_meta_box(
            'dashboard_primary',
            'dashboard',
            'side'
        );
        remove_meta_box(
            'dashboard_activity',
            'dashboard',
            'normal'
        );
        remove_action(
            'welcome_panel',
            'wp_welcome_panel'
        );
    }
);

应先在浏览器开发者工具或 $wp_meta_boxes 的调试输出中确认当前组件 ID。插件可能注册自己的仪表盘卡片，不能假设多年不变。

不要使用的旧做法

以下思路都不应作为普通生产站默认配置：

过滤 pre_site_transient_update_core/plugins/themes 返回空值。
移除 _maybe_update_core 等内部 action。
全局设置 automatic_updater_disabled。
只隐藏更新提示，却没有其他告警通道。
使用 create_function() 创建回调；该函数已从 PHP 8 移除。
为避免兼容问题长期冻结 WordPress Core、主题和插件。

“更新后出问题”说明缺少依赖管理、测试和回滚，不说明永不更新更安全。

一个可执行的更新流程

资产清单： 记录 WordPress、PHP、主题、插件、数据库和服务器版本。
维护状态： 移除废弃插件，减少来源不明或无法升级的定制代码。
自动备份： 数据库与上传目录都要备份，并定期验证恢复。
暂存验证： 在与生产接近的环境升级，运行登录、表单、支付、搜索、缓存和定时任务等关键流程。
小步发布： 区分核心、主题和插件变更，保留明确回滚点。
发布后监控： 检查 PHP 错误、前端异常、队列、邮件、404 和性能。
安全响应： 高危漏洞不能等待下一次大版本维护窗口。

托管平台或不可变部署可能禁止后台直接安装文件，这是部署策略，而不是隐藏更新事实。此时应由 CI、主机控制台或安全平台提供升级与告警，并明确负责人与响应时间。

版本信息能否隐藏

从后台页脚移除版本号几乎不构成安全防护；攻击者可以通过静态资源、接口行为和已知漏洞探测站点。真正有效的是及时修复、最小权限、WAF/速率限制、日志和备份。

可以为编辑优化后台品牌和信息密度，但管理员必须能看到版本、健康状态和待处理更新。可见性是维护能力的一部分。