WordPress | 搭建过程笔记，和一万个问题报错

2022-01-03

3614字

甘普基本变形定律 , VPS

WordPress

本文作者没有任何代码基础，所有说明性文字主要靠连蒙带猜兼灵光一现，参考时请务必注意，欢迎提出意见和给出建议~

故事的开头总是相似的：有一天我偶然逛到Temple的Ashsilent Planet站，惊为天人，这个瀑布流布局和动态博客的组合，不就是我一直想要的书摘站吗！

当天我在长毛象夸夸并开始琢磨搭建，意外收到博客博主回复，得知布局设置并不复杂，立刻动心起念，当晚打完本就开始搜索搭建方案，很好，搭建看起来也很简单，此时不动手，更待何时！

——然后就连带着炸掉了Miniflux域名访问。

论如何删库跑路

比学会走路更重要的当然是研究明白怎么清理杀人现场。

docker ps #列出正在运行的容器
docker-compose down #容器下线
docker rm 容器ID #删除容器

docker images #列出镜像
docker rmi 镜像ID #删除镜像

docker volume ls -q 列出资料库容器
docker volume rm WordPress_db_data #删除wp的数据

论反派重生之后

用Docker搭建WordPress很简单，我五分钟Google教程，十分钟看完流程，半个小时后就成功用IP跑通了Wordpress后台。现在想想，实在顺利得很像一个阴谋。

果然两个小时后我瘫痪长毛象三次，炸飞配置文件五次，弹出报错不计其数，这些我们一会再谈。

mkdir WordPress #创建一个名为WordPress的文件夹
cd WordPress #进入WordPress文件夹

nano docker-compose.yml #编辑配置文件，并写入以下内容

version: '3.3'

services:
   db:
     image: mysql:latest
     volumes:
       - db_data:/var/lib/mysql
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: 设置一个密码A
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD:  设置数据库密码B

   wordpress:
     depends_on:
       - db
     image: wordpress:latest
     ports:
       - "8000:80" #8000可以修改为任意未被占用的端口
     restart: always
     environment:
       WORDPRESS_DB_HOST: db:3306
       WORDPRESS_DB_USER: wordpress
       WORDPRESS_DB_PASSWORD:  与数据库密码B相同

volumes:
    db_data:

docker-compose up -d #容器上线，开始加载镜像

这时候用ip:端口号的形式就可以访问WordPress后台，确认服务没问题，下一步就配置域名。

论报错的成长史

显然事情没有这么简单，不过还是先在域名商/cloudfare那边设置一个指向服务器IP的A记录。

nano /etc/nginx/conf.d/wordpress.conf #编辑wordpress的nginx配置文件

server {
    listen 80;
    server_name 配置域名;

    location / {
        proxy_pass http://127.0.0.1:8080;    #8080改为之前设置好的端口
        proxy_redirect off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

nginx -t #测试配置文件是否有语法错误
nginx -s reload #重新加载配置文件
systemctl start nginx #启动Nginx
systemctl enable nginx #设置nginx在系统启动时自动启动

大功告——没有，访问设置好的子域名，发现毫无动静，我莫名其妙，来来回回折腾无果，干脆删掉了WordPress.conf试试重来，一阵混乱后，我收获了一大堆报错，并报销了之前搭建好的Miniflux——它没法用域名访问了。

Nginx报错

先展示一下Nginx都报了些什么错：

systemctl start nginx #启动Nginx
Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xe" for details. #返回结果

nginx -s reload #重新加载配置文件
nginx: [error] invalid PID number "" in "/run/nginx.pid" #返回结果

nginx -t #测试配置文件是否有语法错误，并查询配置文件路径
nginx -c /etc/nginx/nginx.conf #设置配置文件
nginx:[emerg] bind() to [: :]:443 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
#返回一长串类似输出结果

systemctl status nginx #查看nginx状态
#节选返回结果：
Active: failed (Result: exit-code)
nginx.service: Control process exited,code=exited,status=1/FAILURE
nginx.service: Failed with result 'exit-code' .
Failed to start A high performance web server and a reverse proxy server.

……总之就是这样了。

现在来看应该是80/443端口被占用，同时pid（进程）文件出问题（但不知道为什么出问题），reload命令需要通过nginx.pid文件来获取主进程号启动nginx，文件丢失后nginx自然就无法启动。

参考：谁掳走了 nginx.pid 文件？和Nginx重启时丢失nginx.pid文件

文章中提供了好几个解决方案，我用的是象友西风帮忙提供的：

pkill nginx #杀掉nginx进程
cd /run #进入/run文件夹
ls #检查是否还有nginx.pid文件
systemctl start nginx #启动Nginx
systemctl enable nginx #设置为系统启动时自启动
nginx -s reload #重新加载配置文件

再用systemctl status nginx检查nginx状态，返回

#以下节选
nginx.service - A high performance web server and a reverse proxy server
Active: active (running)
Starting A high performance web server and a reverse proxy server...

这样nginx就正常启动了，但这样还是没办法用域名访问Miniflux，这个问题解决得非常无厘头：我把Miniflux.conf的proxy_pass从127.0.0.1:端口号换成了服务器ip:端口号（但实际上用127.0.0.1，即本地主机IP应该是更好的），接着重启了容器

它就好了。

就好了………

视角来到反代一边

检查过nginx没有问题后，到底是什么导致了WordPress的反代一直没有成功呢。

我百思不得其解，直到我在怎样把WordPress 部署在反向代理的后面？这篇文章里看到了：WordPress的核心开发者说：让WordPress支持反向代理不是他们的责任

哦原来是这样……等等？？？？？？？？

最终解决办法参考了博主小麓的两篇文章，一篇汇总wp反向代理与配置SSL证书问题，另一篇则讲了利用Docker部署Nginx配置反向代理实现二级域名访问WordPress的流程

总体思路就是，进入容器，往wp-config.php里加点东西……

（以及，南狐提醒我说其实WordPress官方说明页里有提过反向代理，一看还真的是，我一看到英文就跑了，这是个坏习惯，下次一定……

If WordPress is hosted behind a reverse proxy that provides SSL, but is hosted itself without SSL, these options will initially send any requests into an infinite redirect loop. To avoid this, you may configure WordPress to recognize the HTTP_X_FORWARDED_PROTO header (assuming you have properly configured the reverse proxy to set that header).

docker ps #查询wordpress的容器id
docker exec -it 容器id /bin/bash #进入容器
之后输入命令的前缀变为：root@41154c6ce0f1:/var/www/html# 
root@41154c6ce0f1:/var/www/html# ps
index.php    wp-activate.php     wp-comments-post.php  wp-config.php  wp-includes        wp-login.php     wp-signup.php
license.txt  wp-admin            wp-config-docker.php  wp-content     wp-links-opml.php  wp-mail.php      wp-trackback.php
readme.html  wp-blog-header.php  wp-config-sample.php  wp-cron.php    wp-load.php        wp-settings.php  xmlrpc.php
apt update #更新一下apt
apt install nano #安装nano编辑器
nano --version #检查版本，确认是否安装成功
nano wp-config.php #编辑wp-config.php

#在wp-config最末尾加入以下内容
if((!empty( $_SERVER['HTTP_X_FORWARDED_HOST'])) || (!empty( $_SERVER['HTTP_X_FORWARDED_FOR'])) ) {
    $_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];
    $_SERVER['HTTPS'] = 'on';
}

之后重启容器和nignx，再重装一下证书（这一步不清楚是不是必要的，但我做了）

#重新开一下服务器
cd wordpress
docker-compose down
docker-compose up -d
nginx -s reload
systemctl start nginx
systemctl enable nginx
certbot --nginx

之后，通过ip访问WordPress，在后台修改站点地址（URL）和为WordPress地址（URL）为域名地址

注意，修改站点地址（但没有改WordPress地址址）后再通过ip:端口访问会自动跳到80端口，解决办法是在ip:端口后加入/wp-admin。即后台访问地址为ip:端口/wp-admin，修改WordPress地址后IP:端口号将无法访问。

……不成功就成仁！！！

论一波一二三四折

……反正它就是很娇弱嘛

安装主题报错413

报错全名叫做”413 Request Entity Too Large“，场面非常吓人——长得和页面404差不多。

参考这篇文章解决：

nginx -t #查找nginx配置文件路径
nano /etc/nginx/nginx.conf #打开配置文件

找到 http{} 段，修改或者添加

client_max_body_size 5M;

nginx -s reload

安装主题与php.ini

报错：上传的文件尺寸超过php.ini中定义的upload_max_filesize值

参考这篇文章

cd wordpress
nano uploads.ini

# 写入以下内容
file_uploads = On
memory_limit = 500M
upload_max_filesize = 30M
post_max_size = 30M
max_execution_time = 600

之后再修改docker-compose.yml，在WordPress:下新增以下内容并重启容器：

    volumes:
      - ./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini

这里出了个不大不小的问题：我学会了进容器，所以看到教程的第一反应是：让我们进容器改吧！

看起来很合理是不是！！但是进容器后nano一下就会发现nano用鲜红的字体提醒你"uploads.ini" is a directory，好，那也可以，我们rm -rf一下重新编辑，但！但！但它删不掉！！

rm -rf uploads.ini
rm: cannot remove 'uploads.ini': Device or resource busy

这时候教程又会告诉你可以查一下什么占用了uploads.ini的进程，但真的lsof +D uploads.ini的话，lsof什么也不会返回——

（开始抓狂）

实际上我猜测容器里的uploads.ini目录就是我在docker-compose.yml里挂载的volumes文件夹，因此无法删除，而为什么它是空的呢，那毕竟我也没有创建什么东西在里面嘛……

文件大小限制有没有修改好可以通过媒体文件上传限制来检查，点开wordpress后台，媒体-添加新文件，可以看到文件上传限制的提示。

论一些其他有的没的

学会了一些新命令

ps aux|grep nginx 查看nginx的主进程号
nginx -s stop 快速停止nginx
nginx -s quit 完整有序地停止nginx
nginx -s reopen  #重启Nginx

以及鞠躬致谢

555555感谢长毛象上的各位象友，西风、南狐、alteredEnvoy、shiranai、糖喵和時間線上一條魚，还有Revi、卡悠蒂、Roelxy和纯之都在这三天给出了建议思路和手把手讲解，不但在我头秃的时候指明了方向，还在时间轴和私聊里倾听了我的各种抓狂和惨叫，我又开心又感动，谢谢大家的帮助！

最后，成果

我的书摘和随想站：小球飞槎

名字典自我很喜欢的一则故事：

旧说天河与海通。近世有人居海渚者，每年八月有浮槎去来，不失期，人有奇志，立飞阁于槎上，多赍粮，乘槎而去。十馀日中犹观星月日辰，自后茫茫忽忽，亦不觉尽夜。去十馀月，奄至一处，有城郭状，屋舍甚严。遥望宫中有织妇，见一丈夫牵牛渚次饮之。牵牛人乃惊问曰：“何由至此？”此人为说来意，并问此是何处，答云：“君还至蜀都，访严君平，则知之。”竟不上岸，因还如期。后至蜀，问君平，君平曰：“某年某月，有客星犯牵牛宿。”计年月，正此人到天河时也。（晋·张华《博物志》卷十）