ווי אזוי צו פאררעכטן די ווארדפרעס בעק-אפ פלאגין'ס `is_readable(): open_basedir באגרעניצונג אין קראפט. AWS path warning`?

当我像往常那样打开וואָרדפּרעסס באַקענד，准备看一下备份日志。

然后，就看到了一堆黄色的。

警告，警告，还是警告。

警告: is_readable(): open_basedir restriction in effect. 
File(/home/admin/.aws/config) is not within the allowed path(s): (...)

备份倒是跑完了，没中断，但状态栏一片黄澄澄的，看着就膈应。

你懂那种感觉吗，就像你提交了一个PR，CI全绿了但有个lint warning，你明知道不影响运行，但就是浑身不舒服。

我当时就寻思了一下。

这个问题，到底能不能彻底解决。

BackWPup警告的真正原因：AWS SDK触发了open_basedir限制

说真的，一开始我以为是备份插件BackWPup的问题，毕竟警告是在它的日志里蹦出来的。

但仔细一看，不对。

警告里提到了一个路径，/home/admin/.aws/config。这是AWS SDK在初始化的时候，自动去找系统当前用户的默认AWS配置目录。

听着有点绕对吧。

其实就是说，你在WordPress里装了某个跟AWS有关的插件，比如S3存储、CloudFront之类的，这些插件底层都在用AWS SDK。AWS SDK一启动，就会习惯性地去翻一下你家目录下有没有.aws这个文件夹，里面有配置文件和凭证嘛。

但是呢，PHP服务器为了安全，开了一个叫open_basedir的东西。这个东西，其实就是在服务器上圈了一块地，告诉PHP，你只能在这块地里活动，别到处乱跑。

/tmp目录在白名单里，网站目录在白名单里，但你家目录，对不起，不在。

AWS SDK想去你家目录找东西，直接被拦了。

于是警告就蹦出来了。

解决open_basedir警告的正确思路：重定向AWS配置路径

说实话，我当时的第一反应是去改open_basedir配置，把/home/admin加进去。

但转念一想，不对。

这玩意儿你改错了，格式写错了，少了个斜杠多了一个空格，直接500错误，整个站就没了。

而且open_basedir本身就是为了安全才开的，你把它放开了，等于给服务器留了个口子，不值当。

那有没有更安全的办法？

我想了一下，既然AWS SDK是去找/home/admin/.aws/config这个文件，那我能不能骗它一下，让它去别的地方找？

去一个，本来就在白名单里的地方找。

修复WordPress BackWPup警告：在wp-config.php中添加两行代码

其实解决方案简单到有点离谱。

在WordPress的wp-config.php文件里，加两行代码就行了。

// 修复 BackWPup / AWS SDK open_basedir 警告
putenv('AWS_CONFIG_FILE=/tmp/aws_config');
putenv('AWS_SHARED_CREDENTIALS_FILE=/tmp/aws_credentials');

加在/* That's all, stop editing! Happy publishing. */这行的上面就行。

就这么两行。

没了.

putenv重定向AWS配置路径的原理详解

你想想看，这两行代码做的事情，其实就是告诉AWS SDK，别去翻我家目录了，去/tmp目录找配置文件。

/tmp目录，几乎所有服务器都在open_basedir的白名单里，因为它本来就是系统的临时目录嘛。

AWS SDK一看，哦，配置文件在/tmp，那就去/tmp找。完美绕开了安全限制，啥也不影响。

而且你其实也不需要真的去/tmp目录下创建什么aws_config文件。因为你大概率根本没用过AWS的配置文件，那些配置都是空的默认值。AWS SDK去/tmp找了一圈，发现啥也没有，那就用默认配置呗，完全不影响。

这就好比你骗你家猫，说猫粮在隔壁房间，猫跑过去一看没有，又跑回来了，啥事没有。

验证修复效果：BackWPup备份日志恢复正常

改完之后，回到WordPress后台，打开BackWPup，点一下「立即运行」。

跑完之后再看日志。

黄澄澄的警告没了，全是绿色的「顺利完成」。

就这么丝滑。

两行代码，零风险，改了不到10秒钟，问题彻底解决。

这种「不致命但恶心」的问题，反而最消耗精力。因为你不知道它会不会在某次更新之后突然变严重，你也不知道它会不会影响其他插件。

能用两行代码彻底掐灭的东西，就别留着它碍眼了。

好了，这篇文章就这么短。

因为这个事儿本身就不复杂，我不需要给你整什么背景知识、行业分析、未来趋势。

就是一个WordPress后台的小警告，一个两行代码的修复方案。

希望下次你看到那个黄色警告的时候，能想起这篇文章。