Manual:Upgrading/zh



檔案轉送
選擇一種傳送檔案的方法


 * wget
 * 使用SCP或WinSCP備份文件
 * SSH文件傳輸協定 (SFTP)
 * 使用FTP客户端.
 * 主機提供商可能有提供一個在線的文件管理網頁；可以詢問一下廠家.
 * 其他方法. 那些傳輸方式的列表：文件傳輸協定列表

初步措施
閱讀.


 * 1) 檢查需求
 * 2) 閱讀發行說明
 * 3) 備份現有檔案和資料庫
 * 4) 解壓新文件
 * 5) 升級外掛
 * 6) 運行更新程式以檢查資料庫
 * 7) 測試更新

檢查需求
MediaWiki 需求：


 * PHP +
 * 以下之一：
 * MySQL + （或者相同的MariaDB）
 * PostgreSQL +
 * SQLite +
 * Oracle +

如果你在使用PostgreSQL，請同時閱讀.

更多資訊請閱讀和.

閱讀發行版本說明
藉由解壓縮壓縮檔,或是由Git的檔案檢查/匯出, 裡面有一些檔案的檔名為大寫字母, 其中之個包含了 (wiki). 現在打開它，並看看這個版本改變了些什麼.

清空等待中的工作
出于性能原因，数据库中的某些操作被延迟，并由作业队列管理. 这些作业存储在数据库中，并包含有关应执行的操作的信息参数. 强烈建议在升级Wiki前运行这些待处理的作业，以避免这些参数在新版本中发生变化而失败. 在执行升级前，可使用运行所有挂起的作业并清除队列.

備份現有檔案和資料庫

 * 完整說明: 

虽然升级脚本维护良好且功能强大，但仍可能出错. 在更新数据库之前，请对Wiki进行一个完整备份，包括数据库和文件：


 * wiki的内容，来自数据库，（确保正确指定了字符集，首先检查LocalSettings.php）. 除了SQL数据库转储之外，创建XML转储可能是个好主意.
 * MySQL，SQL转储和XML转储都与 命令一起使用：

mysqldump --user=wikidb_user --password=wikidb_userpassword wikidb > file.sql mysqldump --user=wikidb_user --password=wikidb_userpassword wikidb --xml > file.xml
 * PostgreSQL，用于 命令的数据库转储：

pg_dump --create -Fc wikidb > file.db.dump
 * SQLite，您使用MediaWiki脚本进行备份：

php wikifolder/maintenance/sqlite.php --backup-to file
 * 图片和其他媒体文件（ 目录下的内容，自定义logo /skins/common/images/wiki.png）
 * 配置文件，例如: 和   （若存在）
 * MediaWiki的程序文件，包括所有的皮肤和扩展，特别是如果您修改了它们.

使用tarball打包
您可以通过FTP或者是命令行来放置新文件. 若您可以使用命令行，请使用命令行. 使用命令行要比使用FTP将数千个文件的每个文件上传要快得多.

FTP或图形界面
如果您不能够在服务器上访问命令行，下载MediaWiki tarball 到您的本地计算机并使用7zip解压该文件到本地计算机上.

在本地解压该文件后，使用您喜爱的FTP客户端软件上传目录和文件到服务器上.

命令行
若您当前用户下对Wiki安装目录没有完全的写入权限，则可能需要以 身份运行该命令. 在解压缩tar包时，通常会为新的Wiki版本创建一个新的目录，您需要从旧安装目录中复制之前配置文件和媒体文件目录：

$ cd /path/to/your/new/installation/ $ wget https://releases.wikimedia.org/mediawiki//mediawiki-.tar.gz $ tar -xvzf mediawiki-.tar.gz $ rm mediawiki-.tar.gz

(Open)Solaris用户应使用 gtar ，或：

$ gzip -dc mediawiki-.tar.gz | tar xf -

其他文件
在解压压缩包后，您应该从旧安装目录中复制或者移动一些文件和文件到新安装目录下：


 * 文件包含了您旧的配置设置.
 * （或在旧版本中 ）目录，包含所有上传至wiki的文件，除非您已选择不同的上传目录，并更改所有权和权限. 和 （例如如果您的web用户是“apache”）.
 * 在 目录下的扩展. 您应该经常更新扩展，旧扩展不能够保证在新版本的MediaWiki下工作.
 * 如果您使用了自定义logo，则还需要从备份中恢复该文件. 在1.24版本之前通常在 目录下. 在1.24版本之后在  或  目录下，取决于您选择使用的目录. 之后在LocalSettings.php文件中添加例如如下内容.
 * 在 目录下的自定义皮肤.
 * 对旧安装文件或扩展所做的任何修改.
 * 任何 .htaccess 文件（若您使用Apache并定义了规则）.

一旦完成，将这个新文件夹设为Web服务器上的发布文件夹. 或者将旧安装目录重命名，然后将新文件夹重命名为先前的旧安装目录的名字.

使用Git
如果使用，请将文件导出到干净的位置，然后将旧的自定义文件复制到新位置，如上一节中所述.

如果要升级到MediaWiki 1.25或更高版本，则还需要使用Composer或为维基媒体wiki场维护的提供的集合安装一些外部PHP库. 有关安装和更新外部库的更多详细信息，请参见Git下载文档.

使用补丁
通常可以使用小补丁文件进行次要版本升级. 从转存文件手动下载并解压缩补丁文件，或按照下面wget的说明进行操作. 补丁是增量的，你不能跳过版本.


 * 1) cd 定位到您MediaWiki的主目录下（存有LocalSettings.php文件的目录）
 * 2) 下载补丁文件，并用 gunzip 命令解压它.
 * 3) 使用 检查什么被修改了（例如： ）
 * 4) 如果一切顺利，再次运行 patch 而不用.
 * 5) 检查您的Special:Version，您应该看到新的版本号.

可能导致错误的剩余文件
如果在旧安装目录上解压缩，则某些旧文件可能会导致新版本出现问题.

如果您没有使用profiling，但在MediaWiki根文件夹中有 文件，则可能会收到引用 的错误. 删除或重命名 文件将解决此错误. 如果您将来启用分析，则 文件（也在MediaWiki根文件夹中）可以用作模板.

MediaWiki 1.23不推荐核心皮肤文件的皮肤自动发现机制. 升级到此版本后，您应该确保 目录中的旧文件 、 、 和 以及 目录中的相应子文件夹已被删除. MediaWiki将记录警告，如果仍然发现它们中的任何一个可以帮助您记住（您还需要调整任何自定义外观以遵循类似的约定）. 有关详细信息，请参阅.

MediaWiki 1.24更改了核心皮肤文件的路径. 升级到此版本后，应确保 目录中的旧文件 、 、 和 不再存在. 有关详情，请参阅.

升级扩展
某些扩展已更新，以便使用新版本的MediaWiki. 请务必升级到此类扩展的最新版本. 您可能需要对自定义扩展程序执行手动更新.

不同的tarballs包含一些扩展子集，并具有版本控制功能，可帮助您升级为MediaWiki核心版本选择正确的版本.

Extension Distributor适用于大多数想要使用支持的MediaWiki版本的扩展快照的人.

如果你想要很多扩展，那么从Git下载可能是最好的. 如果您没有Git但想要升级大量扩展，可以考虑使用mwExtUpgrader.

修改 LocalSettings.php 文件
如果你使用来自旧版本的LocalSettings.php文件，你可能需要修改这个文件使其能够在新版本上使用.

皮肤注册
从MediaWiki 1.24版本开始Vector，Monobook，Modern和CologneBlue等捆绑的皮肤不再是MediaWiki核心的一部分，使用这些皮肤需要在 中注册，否则MediaWiki会向你提示没有安装这些皮肤.

若您希望这些皮肤可用，这是您升级到1.24版本后需要添加到 的内容：

此代码用于MediaWiki 1.25和更新版本. 对于MediaWiki 1.24您需要使用以下代码：

其他皮肤可能并不适应新的皮肤注册系统，所以请参阅有关每个皮肤的文档页面，了解如何在遇到问题时正确地注册它.

扩展注册
从MediaWiki 1.25版开始，扩展使用新的扩展注册系统.

您之前的 会包含这些内容：

这些可以转换为：

扩展正在适应使用新的扩展注册系统. 未经调整的扩展应使用旧的安装方式. 有关详细信息，请参阅扩展页面上的安装说明.

其他变量
一些变量可能已过时，或甚至被移除. 将它们放在 中通常不会有任何影响. 可以在较新版本中添加新变量，或者某些现有变量更改其类型. 我们通常会尝试为它们使用合理的默认值，并且在类型更改的情况下，向后兼容. 无论如何，请查看发行说明以查看这些更改.

运行更新脚本
您可以通过两种方式升级MediaWiki数据库：从命令行或从Web浏览器升级. 如果您具有对服务器的shell访问权限，则建议从命令行进行升级，因为这样可以降低升级过程因超时或连接重置而中断的风险.

该脚本还将尝试下载MediaWiki需要的任何缺少的依赖项.

命令行
访问服务器的命令行或SSH shell或类似命令行. 您可以通过SSH连接到服务器来访问命令行. 如果您正在使用的本地PC运行Microsoft Windows，则需要使用PuTTY之类的工具来使用SSH. 从命令行或命令行管理程序，切换到 目录并执行升级脚本：

$ php update.php 在Linux服务器上，如果出现错误，请尝试以root身份执行相同的命令（ sudo php maintenance/update.php ）. 注意在Windows上进行简单安装（例如使用）： 首先确保您的Web服务器（例如Apache）和您的数据库（例如MySQL）正在运行. 然后运行update.php：右键单击它，选择Open With，然后浏览到PHP.exe. 模式升级完成后，生成的命令提示符窗口可能会自动关闭.

您可能会看到一条消息，指出您的PHP版本太旧，而且MediaWiki需要更新的版本. 在该消息之后，更新中止. 此错误的原因是命令行可以使用另一个PHP版本，而不是从Web服务器执行MediaWiki时使用的PHP版本. 当您收到此消息时，您应该检查如果您可以使用其他命令在shell上执行较新的PHP版本： 是php5或php56. 如果有其他版本可用，如果可用——在哪个名称下，取决于服务器的设置. 如果它不起作用，请询问您的主机提供商，他一定会知道的.

MediaWiki将检查现有架构并更新它以使用新代码，根据需要添加表和列.

当发生“ALTER命令对用户拒绝”错误（或类似错误）时应做什么
如果脚本中止了类似于以下的消息：

Error: 1142 ALTER command denied to user 'wiki'@'localhost' for table 'mytable' (localhost) ERROR: must be the owner of the mytable relation

这意味着您应该检查是否在文件中（在主目录中）定义了和. 这些是此脚本访问数据库所需的用户和密码.

In some cases, an old $wgDBmwschema variable (for Postgres) seems to be read for the table name to update instead of $wgDBname, even when mysql is used. If this is the case, just get rid of the $wgDBmwschema definition in LocalSettings.php.

当发生“意外的T_STRING”错误时应做什么
从命令行运行update.php的个人可能会遇到以下错误：

 syntax error, unexpected T_STRING, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or '}' \ in ~/maintenance/commandLine.inc on line 13

从php4运行update.php时会发生此错误.

由提供php4和php5的提供商托管其网站的个人应采取以下步骤：


 * 1) 从命令行输入命令whereis php5
 * 2) 一旦你看清了php5路径的位置，列出php5/bin目录的内容
 * 3) 一旦确定了php可执行文件的名称（php或php5），输入执行update.php的完整路径

以下是个例子：

 $ whereis php5 $ ls -la /usr/local/php5/bin $ /usr/local/php5/bin/php update.php

当发生“register_argc_argv被设定为假”错误时应做什么
您可能遭遇这样的错误：  Cannot get command line arguments, register_argc_argv is set to false


 * 1) 转到〜/维护. 编辑现有的'php.ini'文件，或创建一个.
 * 2) 添加下面一行：

 register_argc_argv=true


 * 1) 重新运行php update.php

Web浏览器

 * 参见

如果您的数据库已经很大并且生产率很高，那么您不应该使用Web更新程序，例如因为当达到maximum_execution_time时，更新过程将超时. 在这种情况下，您应该使用命令行界面中的update.php（而不是来自Web）. 究竟什么“太大”取决于您的服务器（例如，它的性能，负载以及PHP的最大执行时间允许脚本运行多长时间）. 如果您的wiki对于Web更新程序来说太大而您的托管服务提供商不允许命令行访问，那么您需要将您的wiki迁移到另一个托管帐户，最好是具有shell访问权限的托管帐户.

如果要求提供升级密钥，请打开文件并查找分配给的密钥.
 * 1) 在执行数据库维护之前始终备份.
 * 2) 将您的浏览器导航到 . 例如，如果你的wiki位于 ，那么导航到.
 * 3) 选择您的语言并点击继续.
 * 4) 应检测现有安装. 按照屏幕上的说明进行升级.

可能会发生Web更新程序似乎不起作用：您可能会看到一个空的Wiki页面，而不是看到初始语言选择屏幕，可能会显示一些错误消息. 在这种情况下，您的网络服务器很可能使用重写规则（最有可能是短网址），它们不会在mw-config/显示更新程序，而是一个维基页面 Mw-config/，大写“M”. 在这种情况下，请在更新时重命名“.htaccess”文件. 然后，您应该能够访问Web更新程序.

测试更新
升级完成后，浏览到Wiki并检查以下操作是否按预期工作：
 * 查看页面
 * 编辑页面
 * 上传文件
 * 访问Special:Version并检查显示的版本是否正确以及扩展名是否存在.

常见问题


更新有多难？
如果您修改的唯一文件是，并且您要从1.5或更高版本升级，则该过程非常简单. 涉及的人力工作量只有几分钟. 数据库架构更改将花费与数据库大小成比例的时间，对于具有数百万页的wiki而言可能需要数小时，但对于几千页的更典型大小，通常在几秒钟内完成.

在1.13.0到1.13.1之间的同一主要版本中的次要升级，根本不需要任何架构更改. 您只需更新文件即可. 数据库不需要更新，因此无需运行安装程序脚本.

从1.4或更早版本升级可能很复杂，因为删除了对UTF-8以外的字符集的支持，并且用于存储批量文本的架构已更改. 请阅读 文件中的相关部分.

如果您修改了源代码，并且不希望覆盖您的更改，则升级变得困难. diff、patch、Meld或WinMerge等工具可能很有用. 如果您使用的是非维护扩展，也可能会出现问题. 在升级MediaWiki的同时升级扩展程序.

如果您修改了皮肤或使用自定义皮肤，则很可能需要使用新版本的MediaWiki将其调整为再次使用.
 * 每次只需将代码添加到MediaWiki:Common.js和MediaWiki:Common.css页面，而不是修补“全局”css和js（Javascript）文件. 由于这些是升级时将重用的数据库的一部分，因此您不必再修补MediaWiki核心文件.

我如何从一个非常老的版本升级？只需一步还是需要很多步？
这取决于：如果您要从MediaWiki 1.4或更早版本升级，则应首先升级到MediaWiki 1.5. 如果您要从Latin-1 wiki升级，请使用upgrade1_5.php（在MediaWiki 1.5中找到）将数据库的相关部分转换为UTF-8（需要在中设置为true才能使其工作）. 接下来，运行update.php，然后将LocalSettings.php中的选项设置为wiki先前使用的编码（例如，windows-1252）. 这基本上是维基百科和其他维基媒体基金会网站从MediaWiki 1.4升级到1.5的方式，请参阅相关设置文件（警告：巨大页面！）和一些维基科技相关注释. 在运行upgrade1.5脚本之前，您可能需要升级到MediaWiki 1.4. 如果要创建Latin-1 wiki的数据库转储（例如MySQL），请确保表中 字段的类型为 ，而不是 ，以避免字符编码问题.

如果您要从MediaWiki 1.5或更新版本升级，则可以一步升级，从旧版本升级到最新稳定版本. 绝大多数报告以及自动化测试表明，一步完成这项工作就可以了. 如果您无法相信，请阅读此邮件列表帖子. 但请注意，从旧版本更新时，您遇到PHP错误的可能性比从新版本之前的版本升级时更大. 无论如何，如果您没有跳过版本，但是如果您每次都完成每次更新，那么您本来会收到这些错误. 只有你当你跳过版本时才能同时获得它们. 这将使升级更加困难，但不要忘记您没有更新到您跳过的中间版本的麻烦！

我是否应该首先备份？
一个字：是.

答案很长：这取决于①您对数据的重视程度②创建备份的难度以及③您对MySQL维护和管理的信心.

升级失败可能会使您的数据库处于两个版本之间的不一致状态. 升级期间可能会发生PHP或MySQL错误，导致数据库部分升级. 在这种情况下，有可能通过大量的手工工作以某种方式解决这个问题. 但是，在运行update.php之前放置数据库备份并继续使用它会“更容易”. 否则你可能需要数小时不必要的工作.

恢复通常很复杂. 如果您忽略了备份，然后需要帮助来从与升级相关的损坏中恢复，那么支持论坛上的志愿者不太可能留下深刻的印象. 更好的结果是，如果您可以恢复备份，然后在升级过程中报告相应的MediaWiki项目的错误导致损坏.

我可以保留我的LocalSettings.php么？
是的，但您可能需要做一些小改动. 的格式在很大程度上是向后兼容的. 破坏LocalSettings.php兼容性的更改将记录在发行说明的“配置更改”部分中.

我的wiki可以在更新时保持在线么？
一般来说是的，但Git可能暂时（几秒钟）打断它.

如果要在MediaWiki的次要版本之间进行升级，您只需更新源文件即可.

注意：以下假定您具有命令行访问权限. 如果要在MediaWiki的主要版本之间进行升级，则首选过程如下：
 * 1) 将新版MediaWiki解压缩到新目录中
 * 2) 准备新目录：从旧目录复制当前的LocalSettings.php，复制任何已安装的扩展和自定义外观（如果有）. 检查LocalSettings.php中的设置，并在必要时将徽标文件从旧目录复制到新目录.
 * 3) 在新版本的发行说明中，查看是否需要对LocalSettings.php进行任何更改.
 * 4) 通过将以下变量插入旧目录中的LocalSettings.php，将数据库置于只读模式，如果用户在升级过程中尝试编辑，则会看到此消息：
 * 5) *这不再适用于MediaWiki 1.27，这也阻止了运行更新脚本. 见.
 * 6) 在新目录中运行升级脚本或Web更新程序
 * 7) 将images子目录中的映像从旧目录复制到新目录.
 * 8) 交换旧目录和新目录.

为什么升级？

 * 订阅mediawiki-announce以获取新发行版本的通知. 

因为通常很容易，从你的版本到最新的一步以及经过网络.

最新版本接收安全修复程序，以保护您的wiki和您的主机免受破坏者的攻击，而旧版本则不会（请参阅）. 这几十个很好的理由升级！

新的主要版本附带了您可能想要使用的新功能：有关详细信息，请参阅发行说明. 如果您需要其他参数来说服您的老板让您从一个非常旧的版本升级，这里有一个摘要：


 * 由于1.5，编辑可以在保存之前预览也作为差异.
 * 自1.9以来，撤消按钮可用.
 * 自1.12起，Special:NewPages上的巡查更容易.
 * 从1.13开始，你可以重命名（移动）文件.
 * 自1.14起，您可以自动修复双重重定向.
 * 从1.16版本起可使用.
 * 如果你有适当的缓存，因为1.17的可以优化页面加载速度.
 * 自1.17以来，分类排序有意义！（特别是对于非英文字母），后扩展到68种语言.
 * 由于和，所有语言和性别的用户都通过接口和日志正确处理（在1.15之前，根本没有性别）.
 * 的皮肤系统经过了重新设计，可以更轻松地重复使用自己皮肤中的部分皮肤.
 * 从MediaWiki 1.20开始，m:Help:Diff差异更具可读性.
 * 在MediaWiki_1.21和1.23中，电子邮件通知变得更加清晰，更具可预测性，使您的wiki更有效.
 * 自1.22以来，破坏战斗（巡查）的时间较少.


 * 在1.24中，密码存储已得到改进，以提高安全性.


 * 自1.25以来，增强的最新更改可用


 * 在1.26中，ResourceLoader机制得到了改进


 * 在1.27中，会话管理进行了重新设计，用户身份验证管理完全现代化.


 * 自1.29以来，Action API得到了重新设计和改进. 此外，用户组分配现在可以在可选择的时间段内完成.

参见直到2014年，在上拥有最多投票的已修复问题列表.

另外，在MediaWiki 1.18中我们开始捆绑一些重要扩展，就像一个更好的编辑器和反破坏工具ConfirmEdit和Nuke，在以后的版本中添加了更多内容. 

参见

 * 格雷格·萨比努·穆雷恩的博客文章提供了一些有关指向发行版本升级的详情.
 * 如果您需要帮助，或发生了一些错误的话，可前往Project:Support desk询问
 * (如果您没有成功的备份)
 * (如果您没有成功的备份)
 * (如果您没有成功的备份)
 * (如果您没有成功的备份)
 * (如果您没有成功的备份)