昨晚升级“微知”，从mediawiki下载、解压、上传，却出现了500号运行错误。打开PHP 错误报告，说是某些类找不到。到它提示的缺失目录下去看，发现一些奇怪的文件名，例如.ph、.p、甚至像是从中间截断的（题图所示红叉部分）。拿这个信息一搜，说是“别用7-Zip解压tar（尤其从GitHub打包的），会丢东西”。换Windows自带的解压，果然正确文件出来了（题图所示绿勾部分）。

Mediawiki升级支持不了太大版本跨度，只能先升到 1. 35，再升到1.43。今天基本上把1.35搞定了，只是出了个意外：许多页面变成空白，试着重写，则报编辑冲突，不允许覆盖，有些图片也不显示了。

调查一番，发现是丢了99个版本的更新记录。手动运行SQL修复 ：

INSERT INTO revision_actor_temp (revactor_rev, revactor_actor, revactor_timestamp, revactor_page)
SELECT rev_id, 1, rev_timestamp, rev_page FROM revision
WHERE rev_id > 1 AND rev_id < 101

给所有revactor_actor硬赋的1，等于是把所有丢失的版本更新揽到1号用户（也就是我自己）身上。在多用户的wiki上是未必正确的无奈之举，而在我这里则是唯一正解。

修好先跑两三天再升1.43，我自己也喘口气压压惊。

---

6月13日后记：升级1.43的时候（及之后）发现数据库经常报“数据库已锁定”（The primary database server is running in read-only mode）警告，怀疑是新版数据库的replica闹出的幺蛾子。不是自己的服务器，权限不够，查不了太多，只能通过打开$wgDebugToolbar和$wgDebugDumpSql，跟踪到这么一句：

SELECT @@GLOBAL.read_only AS Value	6.297ms
Wikimedia\Rdbms\DatabaseMySQL::serverIsReadOnly

用phpMyAdmin查看@@GLOBAL.read_only，果然一会儿是0，一会儿是1，十分飘忽。目前无法做更深入的研究，先去includes\libs\rdbms\database\DatabaseMySQL.php里面，强行让serverIsReadOnly返回false就是了。

这篇博文里涉及两个问题。一是Mediawiki显示空白，二是在托管共享服务器上关掉自己PHP环境里的magic quotes。

对于第一个问题，我找到了原因但是没在上面费时间；解决了第二个问题，第一个问题也就N/A了。

 

先说事情的缘起。最近发现我那个自用小Wiki出状况了，所有页面都显示空白正文，只剩标题和Wiki标准界面菜单。

如果点“编辑”，就能在编辑框里看到正文。做一些改动再打开，可以看到词条内容确实被改动过。这是个很好的信号，说明数据库里的内容都还在，而且存取都没问题，只是后续的处理和显示出错了。

大致搜了一下网上内容，有遇到完全相同症状的，说是PHP的PCRE版本升级了，而低版本的Mediawiki代码会出错。方案是降级PCRE或者升级Mediawiki。

降级PCRE是不可能的了，Mediawiki早该升级了。

那就升吧。

 

1. 下载Mediawiki。
2. 解压。
3. 上传到服务器上的一个新路径下。
4. 把旧Wiki里的images目录拷过去。
5. 把旧wiki里的LocalSettings.php改一下$wgScriptPath，拷过去。
6. 浏览器上打开新路径的Wiki链接/mw-config，按指示操作。
7. 确认新版本运行正常。
8. 删除旧Wiki目录。
9. 把新Wiki目录改为旧Wiki曾用名。
10. 把LocalSettings.php的$wgScriptPath改回来。

 

做到第六步时报错了，说新版Mediawiki不能在magic_quotes_gpc打开的情况下运行，让我关掉。

magic_quotes_gpc是PHP_INI_PERDIR级别的，不能够被程序软关，就是说在LocalSettings.php里调用ini_set没用，必须在类似php.ini这类系统级设置里硬关。

可系统不是我一个人的，我只能局部定制。

 

直接在.htaccess里写

php_flag magic_quotes_gpc Off

刷，产生“500 Internal Server Error”错误。据说如果PHP在Apache上不是以Module运行，则会看到这个错误号。这条路走不通了，再来。

 

写个PHP脚本，只有一句话：phpinfo(); 上传运行。阅读phpinfo()的输出，找到PHP初始设置都用了哪些.ini文件。

再写个PHP脚本，只有一句话readfile($_GET[file]); 上传运行，把.ini文件一个个读出内容来，拼接成一个php.ini，在文件末尾附上

    magic_quotes_gpc = Off

在.htaccess里放一句

    SetEnv PHPRC 新php.ini全路径名

上传，再刷，没关掉……

 

几乎山穷水尽时留意到了phpinfo输出的这一栏：

    user_ini.filename     .user.ini

对啊，PHP_INI_PERDIR的说明里也提到了.user.ini，我早该用这个最省力的方法。

创建一个.user.ini文件，把“magic_quotes_gpc = Off”写到里面，上传到Wiki主目录下。再刷，呼，终于行了。

新到刀片服务器一台，郑重地装到了机房里，总算在公司有点产业了。

周六就放大长假，所以周四忙到半夜，周五早晨接着来，先把组里的文档管理系统从一个破破的笔记本转移到刀片上去。转移完毕，一刷浏览器，每个页面都要延迟两秒才能打开，而过去在笔记本上，文档系统的反应都是迅如疾风啊！专业大刀片和专业机房，怎么比放在邋里邋遢的办公桌上的笔记本还慢啊！！！ 😕

文档管理系统是MediaWiki家的，在Apache平台上，使用PHP存取MySQL数据库。

是Apache慢么？由这个Apache管理的其它独立网页都是打开得飞快。
是PHP慢么？把那个独立网页从HTML改成PHP程序输出，还是刷屏快到连闪烁都看不出。
是MySQL慢么？从一个MySQL客户端单独访问，依然是迅雷不及掩耳盗铃。
合在一起之后的MediaWiki，却又是龟速了。

用这台机器的浏览器访问自己，也是同样的现象，这说明网络和防火墙设置不是原因。再说，如果真是网络问题，那么独立网页和MediaWiki就只是“慢”和“更慢”的区别。

后来不知怎的，就留意到MediaWiki本地配置文件LocalSettings.php里的

$wgDBServer = "localhost";

心想，如果把localhost改成绝对的IP地址——127.0.0.1——呢？这么改了一下，MediaWiki就立马变身神行太保了。

难道系统认出localhost就是127.0.0.1，还需要等两秒种？检查一下\windows\system32\drivers\etc\hosts，居然

# 127.0.0.1  localhost

真的被注释掉了！注释的前头还加了一行注释：“兹事体大，着DNS同学办理。”难怪，时间都被DNS耗费掉了！ 😯

速度问题解决之后，忽然又想起一个推论：如果MySQL和Apache分装在这台刀片的两个VM上，那么，MySQL服务器的IP地址就会生写在Apache那边（俺们的系统还没复杂到要用DNS来处理），然后，当Apache来访问MySQL时，就会出现“两台机器互动”比“一台机器自己动”还快的诡异现象。 😉