2018年9月30日更新

MediaWiki新版本又出来了，这次是1.31版，于是按照之前的方法进行升级，结果新状况又出来了。
mediawiki-1.31-error.png
原来1.31不再支持PHP5.6，而改为7.0以上版本，无奈只能先升级PHP再说。另外，系统还需要fileinfo扩展，一并安装。
之后运行升级脚本

# php update.php

查看版本信息如下，升级成功。
mediawiki-1.31-version.png
注意：运行升级脚本前一定要确保所有启用的插件都已下载并保存在extensions目录下，否则将会报错。

2018年1月17日更新

MediaWiki用了有一段时间，也算是逐渐摸清了一些门道，不过这花费的时间也够长的，它都从1.29版升级到了1.30正式版了。
趁着站点上内容不多，赶紧尝试着升级下系统，否则真到运行良好时估计压力更大，因为就这都花了我整整一天的时间摸索。

一、升级前遇到的问题

如果你认认真真地阅读了官方的升级手册并且已经理解了其意思的话，走的弯路会很少，整个升级过程也无需花费太多精力。而我就属于那种喜欢折腾却又对说明文档一扫而过的人，加之英语水平本身又糟糕，后果就可想而知了。
所以先从问题检讨起来。

1、自动升级

我真的是想多了，或者说用Wordpress用惯了，连思路都带偏了。
因为我知道MediaWiki目录下有个Maintenance的文件夹是用来做系统维护的，而其中又有那么一个文件叫做update.php，于是乎我天真地以为只要在终端中输入

# php update.php

然后就会哗哗哗地一堆字符闪现，若干时间之后，提示个“successfully”或者是“completed”之类的字眼，升级工作就完成了。
事实上终端反馈给我的是几个错误提示，固执的我仍然以为是错误导致的升级不成功。
那咱就先攻克错误。

2、画蛇添足的命名空间

先看看我的错误
MediaWiki-Update-error.png
就算是我的英文再烂，大致也能猜出来是之前我在LocalSettings.php文件中重新定义了一下模块命名空间。
那就赶紧删除吧！提示依旧！

3、装逼的Semantic扩展

当时安装这个插件还费了不少周折，结果也没整明白它到底是干啥的，或者说具体怎么用，只是抱着“人有我有，人无我也得有”的心态装了回逼。
错误代码上明显跟它也有关，对吧？（这真的是我当时的想法，现在回头再来分析，觉得自己傻到无可救药了）
Run那句我看懂了，所以赶紧运行起来。总之没有成功，又获得了一堆提示信息！

4、数据库莫名变大

这个问题是无意间发现的，由于升级前备份过数据库，sql文件大概有34M左右，因为升级不成功，顺带就试验一下其他几个维护脚本。
使用了rebuildall.php，而后重新备份数据库，发现竟然变成了39M左右了。

5、常见错误中没有

我把升级文档直接拉到最后面，想从常见错误中找寻一下跟我类似的问题，结果一无所获！（要是有的话，我只能说MediaWiki的预见性太高，都能预见到我这样的白痴操作）

二、升级MediaWiki

痛定思痛，这次要逐字逐句地仔细阅读升级手册了。前面乱七八糟地摆弄了好久，为防止期间有任何愚蠢的操作影响到“正式”升级，决定将服务器回滚到之前的点（还好机灵，知道在升级前创建个磁盘快照）。

1、清空等待中的工作

我之所以没有做这一步，一则是懒，二则这个站点目前就我一个人在玩，不太可能有待处理的工作。

强烈建议在升级Wiki前运行这些待处理的作业，以避免这些参数在新版本中发生变化而失败。 在执行升级前，可使用runJobs.php运行所有挂起的作业并清除队列。

一旦后面出现问题，你可能就会后悔没有做这一步。我是回过头来写这文档才意识到自己又差点给自己挖了个坑。

2、备份

不管你是第几次更新升级MediaWiki，都强烈建议你做一个完整的备份，包括数据库及文件：

  • 如果你的服务器上安装有phpmyadmin，那么通过浏览器就可以实现数据库的备份，否则通过终端命令：

    mysqldump --user=wikidb_user --password=wikidb_userpassword wikidb > file.sql

  • 简单粗暴的方法就是将整个站点的目录全部下载到本地，否则你至少要备份images目录以及配置文件LocalSettings.php、.htaccess（若存在的话），然后皮肤所在的文件夹（至于扩展目录可视情况而定，这个在后面的扩展升级中会提到），当然还有你的logo文件。

    3、下载升级包

    不管你采用什么方法将需要升级的安装包弄到服务器上，总之它都是用来替换之前老版本文件的。
    终端用不惯，就在本地解压缩之后直接上传好了。由于备份过整个安装目录，加之可以回滚操作，就放心大胆地删除了站点上的所有文件，然后将新版本整个上传至服务器。
    紧接着就是将images目录、skins目录以及配置文件LocalSettings.php、.htaccess（若存在的话）上传并覆盖安装包中的文件。

    4、升级扩展

    除了内置的扩展，其他常用扩展都会紧随着MediaWiki的版本一起升级。所以即便你刚刚备份过扩展目录，我还是建议下载新版本的扩展上传。
    1.25版以后，启用扩展所用的代码不再是

    require_once "$IP/extensions/Cite/Cite.php";

    而被替换成了

    wfLoadExtension( 'Cite' );

    虽然我从1.29版升级到1.30，之前大部分的扩展都采用的是新方式，却还是有个别特列，如Scribunto（它是用来支持运行lua脚本的扩展），它在1.29版中仍然沿用老的调用方式，在这次1.30版终于跟上节奏了。

    5、运行升级脚本

    升级脚本可以通过终端或者是浏览器运行，选简单的方法就是采用终端命令，又一次运行（为什么要说又？）

    # php update.php

    MediaWiki-Update.png
    滚滚代码飞流直下，这次终于成功了！打开浏览器，输入站点地址，进入特殊页面:版本
    MediaWiki-Version.png

    三、升级后遇到的问题

    1、该死的lua错误

    升级前所有模板和模块都好好的，这次更新之后又出状况了。
    具体看另一篇文章《MediaWiki内部错误——类型“MWException”的致命错误》中更新的内容。

    2、共享的图片

    目前站点上的内容基本都源自于维基百科（包括图片），因为开启了$wgUseInstantCommons，总以为图片会从维基下载到本地服务器上，这次升级时将整个文件夹都下载了之后，发现根本就没有站上图片的踪影，重新翻资料才明白，人家说得清清楚楚

    InstantCommons是MediaWiki的一个特性，允许在全世界任何一个MediaWiki实体能够使用Wikimedia Commons的任何已上传的媒体文件。 启用InstantCommons特性的wiki站点，可以在第一次请求该文件后自动缓存在本地，并且之后会使用该本地复本来显示。

缓存啦，不是下载啦！

四、总结

其实要总结无非就是认真读文档、认真读文档、认真读文档，理解、理解再理解！千万别蛮干！

最后修改：2023 年 12 月 26 日
© 允许规范转载
如果觉得我的文章对你有用，请随意赞赏