建站/WIKI功能/站点维护

来自Wired
跳转到导航 跳转到搜索

用户访问权限

参考：Manual:Preventing_access#Restrict_viewing_of_all_pages

只有三种方案：有无账户都可以访问；仅有账户的可访问；仅有账户的可访问，但能设置指定页面可被游客访问。

如果想禁止游客访问（也应该禁止游客的编辑权限）添加如下代码：

# 禁止游客访问。
$wgGroupPermissions['*']['read'] = false;

# 禁止游客编辑。
$wgGroupPermissions['*']['edit'] = false;

# 禁止注册，如果是打造私人wiki，而不是单纯的防止垃圾邮件与爬虫。
$wgGroupPermissions['*']['createaccount'] = false;

添加例外（可以被游客访问的页面）：

$wgWhitelistRead = [

'圣王H的秘密基地导航页',
'游戏推荐',
'影视推荐',
'动漫推荐',
'MediaWiki:Common.css',
'MediaWiki:Common.js'

];

示例一个是我首页的标题，最后两个是css和js文件，都要有（如果依赖它们实现某些功能），不然样式和功能会损坏，其他页面根据自己需求加。

　

性能调优

※ 更多性能上的优化见：Manual:Performance_tuning

文件缓存

※ 参考信息：Manual:File_cache

配置文件添加：

$wgUseFileCache = true; // default: false
$wgFileCacheDirectory = "$IP/images/cache"; // default: "{$wgUploadDirectory}/cache" which equals to "$IP/images/cache"
$wgUseGzip = true; # 启用http压缩以更进一步减少资源占用（也可以单独启用它），测试是否有效：https://www.whatsmyip.org/http-compression-test/

当非注册用户访问页面时，服务器会输出创建的.html缓存文件，而无需让数据库/PHP组织数据，以减少资源占用（类似于生成静态网页生成器，4chan那种讨论版大都是这样）。

注意事项：

  • 未创建缓存的页面只有在非注册用户访问后才会建立缓存，后续访问才是调用的缓存文件；
  • 请根据 #可能的问题 第一条设定文件夹权限，以免无法建立缓存页面、用户编辑后无法删掉旧缓存文件，导致白启用文件缓存或非注册用户看不到更新。

已知问题：

  • 由于会将中文字符转为url编码，所以如果页面标题过长可能会导致无法创建/访问缓存文件：
    • 1个中文字符经过urlencode是9个英文字符，若文件名限制在255个字符内：
      • 具体取决于文件系统（终端查询命令：df -T），这里以linux较为常用的ext4为例。
    • 缓存页面的格式是：ns0%3A页面标题的urlencode.html（命名空间|英文冒号:|页面标题|文件后缀），如果启用了压缩还会有一个在此基础上的.gz文件后缀；
    • 因此，需要标题在(255-3-3-5-3)/9≈26个中文字符内。
  • 用户编辑页面后，该页面的缓存文件就会被删除(因为已过时)，但不会重建缓存文件：
    • 看有人提问过，但没啥结果；
    • 影响就是第一个访问此页面的非注册用户会多加载一会儿、多传输十几/几十KiB的资源，他之后的用户就正常访问缓存页面；
    • 所以可以不管，也可以设置定时任务每隔一天或多久就执行一次：#创建文件缓存。

　

懒加载

※ 参考：Manual:$wgNativeImageLazyLoading

配置文件添加：

  • $wgNativeImageLazyLoading = true;

使图像(内部图像)设定为懒加载，即在页面访问到的时候再请求数据，适用于大量使用图片的场景，既能避免只看某一块却下载所有资源的浪费情况，又能减少图片资源过多导致的加载堵塞的情况。

已知问题：该设定不会影响嵌入的外部图片，比如我都是用html代码嵌入图片；

  • 解决方案，给嵌入的外部图像的img标签设定属性：loading="lazy"，如：
  • <html><img loading="lazy" loading="lazy" style="width: 600px;" src='https://scio.eu.org/WIKI/图片/起居注/2023/Screenshot_20230908-050356.avif' /></html>

　

维护脚本

※ 参考：Manual:Maintenance_scripts/List_of_scripts（官方文档有详细的介绍，以下内容也都是摘自官方文档）

需要通过通过命令行(在网站根目录下)运行，1.40版本以后维护脚本必须用以下规范执行（也可以直接指向.php文件）：

php maintenance/run.php 需要执行的脚本/命令

删除无用内容

※ Mediawiki前端不存在真正的删除，用户/管理员将页面删除后，只是进入了普通用户不可见的“存档表”中，管理员仍旧可以恢复页面——即数据库仍旧被占用，而我们作个人博客用途时删除页面的目的基本就是它们只是垃圾数据。 

⚠ 警告：清楚所有修订记录会导致失去所有文章的变动记录，其中包括了页面创建的记录/时间 ⚠

常用的删除脚本：

# 删除已删除页面(进入存档表的)的所有修订记录（含修订内容）。默认是查询，添加 --delete 参数以执行脚本。
php maintenance/run.php deleteArchivedRevisions
php maintenance/run.php deleteArchivedRevisions --delete

# 删除页面的所有现有页面（不含已删除/进入存档表的页面）的旧修订记录（含修订内容），只保留最新版本。不添加参数只查询有多少旧修订记录，添加 --delete 参数，将所有页面的历史修订尽数删除。
php maintenance/run.php deleteOldRevisions
php maintenance/run.php deleteOldRevisions --delete
# 添加页面ID用于删除指定页面的历史记录，适用于个别文章有隐私需求或造成太多数据冗余的情况。不添加 --delete 参数亦是只查询，添加则删除指定页面ID的历史修订记录。# 查询页面ID方式：在目标页面点击左侧边栏的“页面信息”
php maintenance/run.php deleteOldRevisions 28 32
php maintenance/run.php deleteOldRevisions 28 32 --delete

非常用的删除脚本：

# 删除孤立的修订，处理从数据库中手动删除页面记录后留下的任何孤立修订。--report 参数是显示有多少符合条件的内容，删除此参数以执行脚本。
php maintenance/run.php deleteOrphanedRevisions --report
php maintenance/run.php deleteOrphanedRevisions

# 删除位于虚空（存在但不以任何形式链接到包括现有文章、被删除文章的任何修订历史中）中的文本，正常是不存在这种条目的，默认是查询，添加 --purge 参数以执行脚本。
php maintenance/run.php purgeOldText
php maintenance/run.php purgeOldText --purge

# 删除被删除的文件，被删除文件也是进入了“已删除”文件夹而非真正删除，默认是查询，添加 --delete 参数以执行脚本。
# 说是 --delete 选填，但我不加此参数不提示有多少待删除文件(不知道是否是0个的原因)，而直接提示让添加此参数以运行脚本，添加后并运行倒是会提示数量(也是0个)
php maintenance/run.php deleteArchivedFiles --delete

还有一个缺点，那就是无法删除日志（特殊:日志），比如文件的上传和删除日志、页面的创建日志等等，是不会删除的，主要是删的文件和编辑的历史记录(修订)。

建立站点地图

# 参数作用分别为：限制体积在50M内，.xml文件保存路径，标识符，xml文件中记录的xml文件路径(忽略网站根目)，完整域名，是否压缩文件，跳过重定向。
php maintenance/run.php generateSitemap --memory-limit=50M --fspath=/var/www/html/mediawiki/sitemap/ --identifier=wiki --urlpath=/sitemap/ --server=https://wiki.scio.icu --compress=no --skip-redirects

# 软链接到网站根目录以便于爬虫获取资源（在网站根目录下运行）。
ln -s ./sitemap/sitemap-index-标识符.xml sitemap.xml

创建文件缓存

※ 此缓存为创建.html缓存页面以减少服务器资源占用，需要配合#文件缓存使用。

# 给所有页面创建.html缓存文件，如果已经被缓存会跳过
php maintenance/run.php rebuildFileCache

# 重新创建缓存文件
php maintenance/run.php rebuildFileCache --overwrite

清除缓存

清除缓存能解决一小部分的问题，主要是页面本身的变化，重新渲染wikitext语法使其他地方的变动作用到当前页面，比如引用的内容发生了变化、插入的内链失效或生效、wikitext语法或拓展的特殊指令的样式变化等等。#刷新页面缓存中说明了对单个页面的操作，但如果要批量操作，还是需要利用维护工具。

php maintenance/run.php purgePage

已知的问题：

  • 需要使用www-data用户组内的账户运行命令：https://askubuntu.com/a/948488
    • 使用www-data用户：sudo su -l www-data -s /bin/bash
    • 默认在/var/www/目录下，除了权限问题(例如无法创建文件)跟正常账户一样使用。
  • 运行命令无响应：
    • 使用：php maintenance/run.php purgePage.php < list.txt
      • www-data用户组如果没权限创建文件(list.txt)，请在普通/root用户下创建好，支持中文字符(无法输入中文就外面编辑好粘贴进去)，每行一个页面的标题即可。

空编辑

清除缓存作用不到页面之外，而空编辑(A null edit)则是由mediawiki的特色处理方式衍生而来的操作，因为在末尾插入换行符、在现有空格边再插入空格(多个空格会被渲染为一个空格，除非是行首的空格在wikitext中会被解析为预排格式这种有特殊用途的)，便可以提交编辑，但不会被记录（最近更改、页面历史记录均无）。

但编辑页面会刷新与之相关的所有内容，例如直接通过xml导入页面，原页面拥有分类归属或引用了内链，导入后尽管会完整渲染样式，但系统里没有相关从属记录，例如分类页找不到该页面、被引用页面的链入页面也无该页面；例如给cargo表添加了列也无法被记录。清除缓存无法作用到页面以外的部分，因此空编辑成了最好的解决方案，但手动空编辑也太慢了。

利用了外部js脚本：MassNullEdit实现：

  • 建立页面：MediaWiki:MassNullEdit.js，粘贴此页代码：MediaWiki:MassNullEdit/code.js
  • 建立页面：MediaWiki:MassNullEdit.css，粘贴此页代码：MediaWiki:MassNullEdit.css
  • 编辑：MediaWiki:Common.js，添加内容：importScript('MediaWiki:MassNullEdit.js');
  • 编辑：MediaWiki:Common.css，添加内容：@import url('MediaWiki:MassNullEdit.css');
  • 刷新浏览器缓存(ctrl+f5)，在左侧边栏会出现“批量空编辑”的选项，点击后会弹出窗口供输入页面标题，每行一个，从“特殊:所有页面”中复制即可，无需删除多余的前缀空格。

※ 但毕竟是编辑，相较于清除缓存更消耗时间及服务器性能。

重建

不过官方提供了更专业的脚本Rebuildall.php来重建所有内容，以应对包括导入页面后无从属关系的异常情况，效力大于空编辑。

php maintenance/rebuildall.php

清除缓存作用于页面内容，空编辑作用于与页面及页面内容相关的，而重建脚本则作用于整个站点，是从数据库层面刷新页面，速度也比空编辑快，但其作用范围太广泛了，遇到疑难杂症(例如“需要的分类”中出现了幽灵分类，没有任何页面指向它却也无法将之去除)可以尝试，一般页面链接之类的小问题我还是交给空编辑吧。

　

备份/恢复/升级

对于只涉及页面的备份与恢复（.xml）

※ 弊端就是所涉内容不会列入特殊:统计信息，亦不进入监视列表。

特殊:所有页面：因为默认的从分类获取页面的功能只能查询一级，可以直接从此复制粘贴列表。你可能需要注意的几个命名空间：

  • （主）：默认的普通文章创作；
  • 用户：给用户创建的页面；
  • 文件：上传的文件（数据库中有文件页面与本地资源路径的索引，因此如果绕过数据库，就需要重新上传文件）；
  • 模板：创建的模板，如果您还启用了模块、微件等，记得也要备份；
  • mediawiki：主要是MediaWiki:Common.css（css文件）、MediaWiki:Sidebar（侧边栏）、MediaWiki:Mainpage（首页）

特殊:导出页面：导出页面数据为.xml文件：

  • 默认不包含修订，只有最新版本，这样会减少很多数据冗余，但就不含创建时间了；
  • 默认不包含模板，如果勾选，那么会一并备份页面中使用的模板:xxx页面。

特殊:导入页面：在新站点上传文件：

  • 请按照 #可能的问题 第四条设定体积限制；
  • 跨WIKI前缀随便写就行，没有发现实际起到了什么作用；
  • 建议勾选“将编辑分配到本地存在的同名用户名下”；
  • 注释随便写，默认的导入原命名空间即可。

其他可能需要调整的：

  • 在MediaWiki:Mainpage修改了首页后，将“首页”页面其移动到设定的首页页面（不必保存重定向）；如果已经将目标页面填充了内容，那直接删除“首页”页面就行。

对于相同web环境的备份与恢复

  • 备份数据库：LAMP#备份/恢复数据库；
  • 备份网站资源：建议直接在网站根目录下用zip命令打包所有文件；
  • web环境：您在 部署Web环境 时修改了哪些东西？如果没有什么好在乎的修改，可以重新配置环境，如果有，记录相关修改或导出相关文件即可。
  • 在新服务器原样导入即可。

对于相同web环境的升级框架版本

先备份：

  • 数据库：参考LAMP#备份/恢复数据库。
  • 网站资源：
    • 拓展：./extensions/
      • 只记录扩展名再从官网下载非预装扩展的最新版本；
      • 可以参考配置文件中启用的拓展，亦可用：tree -L 1 -d > tree.txt 获取当前目录下的文件夹列表并输出到tree.txt文件中，识别其中的非预装扩展并下载下来；
    • 图片：./images/
    • 配置文件：./LocalSettings.php
    • 网站图标：
      • /网站根目录/resources/assets/ 下的log文件
      • 如果您修改了皮肤样式或其他内容，请也对所涉及资源进行备份
    • 其他网站内配置，如：
    • 以及框架资源外的文件，如 ：
      • robots.txt
      • 网站根目录下的图标文件：favicon.ico

再升级：

  • 按照 安装指南 重新下载并解压；
    • 如果跨版本过大请注意注意php与数据库的兼容性；
    • 请不要直接删除旧文件夹，可以重命名为 文件夹_旧 备用。
  • 测试站点是否可访问；
  • 将旧配置(LocalSettings.php)文件移动到框架根目录；
    • 建议重新配置，配置数据库时，填写曾用数据库名，系统会检测并自动更新数据库表以使其适用于当前版本。
  • 将最新版本的扩展移动至扩展文件夹(./extensions/)，图片及其他站内外数据也尽数移动回来；
    • 如果通过ftp传输而访问报错，别忘了设置访问权限；
      • 如果对扩展文件全都赋予了644权限，记得对#代码块、#模块(假若有启用)单独改下权限以免有些功能无法使用。
  • 更新数据库及其他东西（网站框架根目录下运行）：
    • php maintenance/run.php update.php
    • 这是最主要的步骤，将对数据库的更新(内容和表的结构)，这个更新是不可逆(或很难/一旦出毛病无法处理)的，所以在更新前务必确保自己备份了数据库，不论是回滚版本还是防止数据库损害都有利而无害。

至此框架的升级完成了。

检索自“https://wired.scio.icu/index.php?title=建站/WIKI功能/站点维护&oldid=91”