插件启用时直接报 parse error: syntax error, unexpected $end，这基本是插件用了短标签（
插件启用时直接报 Parse error: syntax error, unexpected $end
这基本是插件用了 短标签，而你的 PHP 环境禁用了 short_open_tag（PHP 5.4+ 默认为 off）。错误路径里显示的文件，打开后搜 就能定位。
- 临时解法：改插件源码，把所有
换成<?php，注意别漏掉=（它等价于<?php echo，通常安全） - 长期规避：在
php.ini中设short_open_tag = On并重启 PHP，但不推荐——短标签已被 PHP 官方弃用，新项目应彻底避免 - 关键提醒：有些插件压缩包里含混淆代码或 base64 字符串，里面也可能藏
，需解码后检查
启用后进不了后台，报 Uncaught TypeError: Cannot access offset of type string on string
这个错误在 PHP 8+ 环境下高频出现，尤其和缓存类插件（如 Redis、OPcache 扩展）强相关。它不是插件本身语法错，而是运行时类型校验失败——比如某处写了 $data['key']，但 $data 实际是个字符串而非数组。
- 先停用所有插件：通过 FTP 把
wp-content/plugins/重命名为plugins.off，再访问后台；若能进，说明问题出在插件层 - 重点排查 Redis 类插件：即使你没手动启用它，只要插件文件存在且被 WordPress 自动加载（比如通过
wp-config.php配置了WP_REDIS_*常量），就可能触发此错 - 不要只切 PHP 版本：有人切到 PHP 7.4 暂时绕过，但本质是掩盖问题；真正要做的，是进后台停用 Redis 插件，再逐个启用其他插件验证兼容性
更新插件时卡住，报 Call to undefined function chmod()
PHP 8.x 默认把 chmod() 加进了 disable_functions 列表，而部分老插件（尤其是带自动部署逻辑的备份/部署类插件）仍直接调用它，导致更新失败或白屏。
- 查当前禁用函数：运行
phpinfo()或执行var_dump(ini_get('disable_functions'));确认chmod是否在其中 - 修改
php.ini：找到disable_functions行，删掉chmod（注意保留逗号分隔），保存后重启 PHP - 替代方案：如果无法改服务器配置，可临时在插件代码里加判断，比如
if (function_exists('chmod')) { chmod(...); }，但属权宜之计
错误页面空白，连错误信息都不显示
WordPress 默认关闭错误输出，尤其生产环境。没有报错≠没出错，只是被静默吞掉了。
- 强制开启调试：在
wp-config.php里确保有这两行（位置无所谓，但必须在/* That's all, stop editing! */之前）：define('WP_DEBUG', true);define('WP_DEBUG_DISPLAY', true); - 别依赖前台显示：某些致命错误（如解析错误）会阻止 WordPress 初始化，导致
WP_DEBUG不生效；此时必须看 PHP 错误日志——路径通常在/var/log/php/error.log或宝塔面板的「网站」→「错误日志」里 - 权限陷阱：如果
wp-content或其子目录权限是 777，某些主机安全模块会拦截执行，表现为无提示白屏；应统一设为目录755、文件644，wp-config.php单独设为600
实际排查时，最常被忽略的是「插件残留配置」：比如停用了 Redis 插件，但 wp-config.php 里还留着 define('WP_REDIS_HOST', '127.0.0.1'); 这类定义，它会让 WordPress 继续尝试连接并触发类型错误——删干净再试。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
