本人高三毕业生，寒假手搓了一台大型服务器，经过无数的波折，总算到了迁移博客网站的环节。万万没想到，这一次迁移折腾难度前所未有的大。
此前初高中期间，由于时间有限，一直偷懒用宝塔面板+Nginx+MySQL，直接装在系统里面。时间久了之后，宝塔面板自然而然地就会产生许多莫名其妙的Bug，系统环境也会乱的一塌糊涂（尤其是Python和N卡驱动），并且一旦有所失误，之前辛辛苦苦搭出来的东西也会集体罢工。
于是，这次趁着换上大家伙，准备参照企业生产环境部署。为了方便，最终选择直接将社区版Docker作为主要的环境，所有应用（甚至包括FRP和科学上网之类，但不包括驱动之类硬件级的东西）全部以容器形式管理。
下面进入正题：
原材料：
- 之前的Wordpress网站文件
- 之前的数据库SQL备份文件
这些在旧服务器上都是能够正常运行的，接下来我只要把它们恢复过来。是不是很简单？
一点都不简单。
这里面有很多预料不到的问题，主要是关于SSL与文件权限的，其中的很多大坑都是网上其他教程未曾提及的，在此做一个记录。
首先，用Docker官方Wordpress镜像建一个容器。它里面自带Apache和必须的PHP组件。
主机/app/wordpress挂载至容器/var/www/html
主机/data/blog/uploads挂载至容器/var/www/html/wp-content/uploads
其中主机/data是我的存储盘LVM挂载点
开机一次之后，把网站文件覆盖进去，uploads文件夹单独处理好，然后建一个MySQL数据库，再把wp-config.php里面关于数据库的连接方式也修改好。
至此都是常规操作，接下来的就不那么常规了。
由于同一台服务器搭建了多个网站且分散在不同容器里，我就用到了nginx-proxy-manager，配置好针对blog.fwerkor.com的反向代理和SSL证书，然后访问。
第一个问题：样式消失了
按F12检查（没截图），大概就是说网站访问使用了HTTPS，而Stylesheet使用了“不安全”的HTTP。
去**的安全，谁有功夫用css整病毒/监听？
简单分析一下，虽然你客户端浏览器通过HTTPS请求到了页面中绝大多数内容，但是由于nginx-proxy-manager（或者是你的其它加SSL的反代程序）向Wordpress的PHP应用池发起的请求还是HTTP，WP在提供css文件链接时，使用http协议+你的站点地址（去掉https：）组合出了一个鬼东西出来发给了你的浏览器，造成了前述问题。
网络上关于这类问题的解决方法很多，比较常见的一种大致如下：
第一步：修改 wp-config.php，加入以下代码（注意域名要改成自己的）：
$_SERVER['HTTPS'] = 'on';
define('FORCE_SSL_ADMIN', true);
define('FORCE_SSL_LOGIN', true);
define('WP_HOME', 'https://blog.fwerkor.com');
define('WP_SITEURL', 'https://blog.fwerkor.com');第二步：修改 wp-includes 目录下的 functions.php 文件。
找到以下代码：
require( ABSPATH . WPINC . '/option.php' );在其下方添加以下代码：
add_filter('script_loader_src', 'agnostic_script_loader_src', 20,2); function agnostic_script_loader_src($src, $handle) { return preg_replace('/^(http|https):/', '', $src); }
add_filter('style_loader_src', 'agnostic_style_loader_src', 20,2); function agnostic_style_loader_src($src, $handle) { return preg_replace('/^(http|https):/', '', $src); }第三步：重启 wordpress 容器。
第四步：修改数据库中关于站点url的记录（由于我的网站是迁移来的，本就使用HTTPS，无需此步）。
最后打开网页，在地址栏输入地址即可正常访问，后台也能登录了。
样式依然没加载出来！！！
点开完整的报错记录，才发现所有调用失败的样式文件都位于cache目录中一个叫autoptimize的文件夹内。
不就是个性能优化插件吗？删！
插件文件夹直接删掉，顺路到数据库里面已启用的插件表里把它也删了
于是样式出来了。
然而，进不了wp-admin了！
开始我以为是用户权限问题。之前我一直使用casdoor，这次为了迁移方便暂时把casdoor停用了。
于是，我开始在数据库的海洋中漫游~
什么都没发现，甚至连记录用户身份的表在哪都没找到（我没认真找）。
于是又上网搜了一下，发现了这个。
简而言之，在第一步修改wp-config.php文件时，一定要把那几行代码加在这个东西前面：
if ( ! defined( ‘ABSPATH’ ) )
修改之后，能够进入后台了。
你以为这就结束了吗？当然没有！
发现插件里所有插件居然都处于未启用状态，并且罪臣autoptimize还安安稳稳地躺在那里。
删除autoptimize，结果问我要FTP连接凭证，看来文件读写权限出了问题。
老规矩，通通777处理，反正我的SSH端口不对公网开放，更何况如果真有人进入了我的系统，那么估计离他提权root也不远了。
结果还是老样子~
再次查资料，发现可以在wp-config.php最后添加如下代码：
define("FS_METHOD", "direct");
define("FS_CHMOD_DIR", 0777);
define("FS_CHMOD_FILE", 0777);问题解决！
目前站点也算基本能用了，至于还会遇到什么问题，以后再说。
补充一些注意点：
第一，使用Nginx直接部署Wordpress时，别忘了考虑伪静态的问题，因为它不能像Apache一样直接从网站文件中读取配置
第二，以上折腾有替代方案，就是在源站也配置SSL。但这也不是很简单的事，除非在反代上设置不检查SSL证书是否过期。
第三，使用Docker部署大量容器时，不必每次都设置端口映射，可以直接用容器在虚拟网络中的IP访问，并且用nginx-proxy-manager进行转发（它也支持普通TCP/UDP的转发）。但是一定要注意自己创建一个Network，将容器分配到自建的网络中并手动指定IP。如果使用默认的bridge网络，每次启动都会重新分配IP！
第四，如果使用Linux软链接替代掉Uploads文件夹，就算读写权限设置没问题，打开网站时依然会产生一大堆Warnings，建议按照网上方法修改媒体库位置。
本文为FWERKOR Castronaut原创，未经许可谢绝转载！