WordPress Sitemap 文章修改时间变为 1969-12-31

今天给博客 WordPress SEO 的时候,重新生成了一下 sitemap 站点地图,发现有些文章的修改时间不对劲。大概有不到100条的记录修改日期全都变成了 1969-12-31 18:00:00 ,可能是以前做数据库迁移或者 WP 导入导出的时候把修改时间给整乱了。解决方法也很简单,去数据库中把表中的数据更新回来就好了。

在 Windows 中 WAMP Mysql Console 控制台导入SQL文件

因为之前一直都是在 Linux 上弄 Mysql 导入 SQL 数据库文件的,用的 mysql 命令,但是今天小佛想要在 Windows 上测试一下新的 WordPress 模板,想把服务器上的网站搬到 Windows 主机上来。然后就卡在数据库导入这里,虽然可以用 phpmyadmin 导入,但是,你们知道,不折腾就不会碰到错误。所以,错误来了。

WAMP Mysql 命令行导入超大数据库报错 Error 2005 解决方案

之前 Forece 曾经写过如何利用 mysqldump 和 mysql 导入和导出数据库。其实大家一般导入小型数据库的时候基本上用的都是图形界面的 phpmyadmin,但是在导入和导出超大数据库的时候就显得力不从心了。经常出现超时的问题,所以如何非要用 phpmyadmin 导入超大数据库的时候,就必须得将数据库分割后依次上传。不过利用mysql命令导入则没有这个问题。上次讲的是在 Linux 下导入,今天讲讲在 WAMP 中进行导入。

记又一次通过查看日志解决服务器500内部错误(xmlrpc.php)

自从上次调整了php的参数后,Forece 的 WordPress 博客几乎就再也没出现过500错误了,不过这两天自己疯狂收到服务器宕机的错误,于是又一次大排查开始了。经过重重排查,最终发现了原来是 xmlrpc.php 这个文件搞的鬼。这里写一下排查记录。

Nginx 内存优化最终解决服务器500错误

还是之前 MySQL 宕机的问题续篇,因为一直用虚拟主机,所以习惯了 LAMP 的环境,不过 LAMP 的设置太吃内存了。一直给我整 500 错误,把 MySQL 的内存吃完就报错。设置了 SWAP 分区好了几天,然后又开始吃内存。怎么设置也弄不好。干脆直接换 Nginx 了。但是看了下后台,内存还是吃到了 70% 。然后网上找了下文章。只需要改几个 PHP-fpm 的参数即可。

利用 Crontab 自动检测 MySQL 状态并重启的脚本

很多朋友从虚拟机转到 VPS 或独立主机基本上都会碰到内存不足,然后系统自动将 MySQL 进程关闭的情况。上次已经说过,一个是做系统优化,调整 php、MySQL 的配置文件。另外一个是加载 swap 分区文件。那么如果这些都做了,那么 MySQL 被 Kill 的情况就大大减少了,不过如果你还是不放心的话,可以再加一个无人值守的自动检测 MySQL 的脚本。MySQL 异常关闭,网页中一般会显示 500 Internal Service Error ,或者是 连接数据库错误。 一般手动重启 MySQL 即可。不过这是一个人工操作,最近学习了 Linux 的定时任务 crontab,正好做一个自动化的操作。主要功能就是定时检查 MySQL,如果 MySQL 关闭了,就重启该服务。