Manual:File cache/zh

MediaWiki有一个缓存条目的HTML代码的可选缓存方案.



操作和使用
文件缓存只为匿名用户服务，他们看到的是相同的HTML渲染. 已登录用户不能用这个缓存，因为他们的页面包含了用户名、选择的皮肤等.

文件缓存是通过在LocalSettings.php中设置和参数启用的：

这将导致wiki的每个页面的渲染HTML网页存储在硬盘上的单个文件中. 匿名用户的任何后续请求都不会通过再次呈现页面来满足，而是通过发送存储在磁盘上的HTML版本来满足. 这节省了时间.

生成的HTML web文本存储在 下的目录中的磁盘中，看起来有点像：

 -rw-r--r-- 1 apache apache 57421 Jan 7 01:58 cache/0/04/P%C3%A1gina_principal.html -rw-r--r-- 1 apache apache 29608 Jan 4 16:37 cache/1/17/P%C3%A1gina_Riscada.html -rw-r--r-- 1 apache apache 21592 Jan 3 07:27 cache/1/1c/P%C3%A1gina_Duplicada.html -rw-r--r-- 1 apache apache 36088 Jan 7 02:03 cache/2/24/P%C3%A1gina_principal_alternativa.html -rw-r--r-- 1 apache apache 44205 Jan 7 06:10 cache/a/a4/P%C3%A1gina_linkada.html -rw-r--r-- 1 apache apache 24686 Jan 3 07:27 cache/d/db/P%C3%A1gina_Invertida.html -rw-r--r-- 1 apache apache 17222 Jan 3 06:28 cache/f/f0/P%C3%A1gina_n%C3%A3o_encontrada.html

在此示例中，文件缓存目录为“cache/”，存储的wiki页面命名为“Página …”，生成一个对应的“Página_…”. html文件. 这些文件将在用户访问wiki上的文章时创建；您可以使用维护脚本一次性创建它们.

文件缓存倾向于积极缓存；缓存的页面没有设置到期日期，即使页面包含变量、扩展名和其他可变输出，也会无条件缓存. 某些扩展禁用具有动态内容的页面的文件缓存.

考虑使用代替或组合使用，以获得更有效的结果.

对于较大的站点，使用外部缓存（如squid或varnish）比启用文件缓存更好.

如果文件缓存似乎不工作，请确保Web服务器具有写入所选目录的权限.

限制
缓存文件的文件名由相应的页面标题决定. 根据页面标题中使用的语言，必须对文件名中的某些字符进行编码，以构成相应文件系统的有效文件名. For languages like Arabic, Chinese and so on this may result in the following PHP warning:

PHP Warning: file_put_contents(cache/......html.gz): failed to open stream: File name too long in includes/cache/FileCacheBase.php on line 171

這是一個已知限制. 参见.

分类和图像描述页不会从文件缓存中清除. 例如，从分类中添加或删除页面不会更新分类页面，导致未登录的用户无法看到分类页面中的更改. 这是一个已知的限制. 参见



域和范围
缓存仅适用于以下用户：
 * 未登录.
 * 他们的user_newtalk标志未激活.

仅对以下页面进行缓存：
 * 不是特殊页面.
 * 不是重定向.
 * 正在当前版本中查看，纯访问，无url参数

这涵盖了对wiki的大多数请求，但设置字节码和应用程序缓存来处理其余的请求仍然很重要.

驗證
缓存文件的修改时间与每次访问上设置为的全局 时间戳进行比较.

如果文件至少与这两个文件一样新，则认为它是有效的，并直接发送给客户端. 如果它较旧或不存在，将继续分析和渲染，并保存结果以供将来使用.

验证
通过将 设置为当前时间或删除缓存中的所有文件，可以使整个缓存无效.

通过更新其page.page_touched字段，单个页面将失效，调用可以方便地完成. 这应该在文章创建、编辑保存、重命名以及链接文章的创建和删除（以便更新编辑链接）时完成. 编辑模板时发生的无效操作，例如，检查使用模板将缓存日期与page_touched进行比较的页面.

一些情况尚未得到妥善处理，可能包括：


 * 浏览器“重新加载”或“刷新”（只重新加载相同的缓存页面而不更新）
 * 来自扩展（如）的输出变量禁用这些页面的文件缓存，以避免过时数据. 即使在浏览器刷新时，那些不返回的数据也会返回过时的数据.
 * 某些长错误消息可以无限期缓存，就像它们是有效的页面内容一样；只有?action=purge将在存储后从文件缓存中删除这些文件. 最小输出大小阈值用于避免缓存大多数错误，如致命的PHP错误.

另请参阅：.

過期
可能会有一些缓存页面过期的方法，特别是对于包含变量的页面（它是X日期，我们有X篇文章等）.

如果为 ，则页面输出将禁用文件缓存. 没有设置到期时间的规定，因此所有页面的所有HTML都将永久缓存. 一个显式的 命令（或对页面的编辑）将重新生成该页面，但MediaWiki内部无缓存标志和浏览器刷新都不会删除过期的扩展输出，一旦它作为文件缓存页面的一部分存储.



刷新选项卡
可以添加一个选项卡来强制一个单独的页面无效并使用?action=purge使用清理页面缓存扩展进行清除.

壓縮
可选地，可以压缩缓存以节省空间和带宽. （这需要在PHP配置中启用zlib. ）

如果启用压缩，缓存文件将保存为.html.gz. 在Accept-Encoding字段中宣传支持gzip的浏览器将直接获得gzip版本；对于那些没有这样做的浏览器，我们会立即解压缩数据，并将明文发送给它们.

将发送一个"Vary: User-agent"标头，告诉代理缓存要更加小心地向谁重新发送数据. （“Vary: Accept-encoding”更合适，但Internet Explorer拒绝缓存如此标记的页面. ）



紧急回退
如果wiki无法与数据库服务器联系，它将尝试显示请求的任何页面的缓存版本，无论该页面是否为当前页面，并在其中添加“database is down”消息.

這有一些限制：


 * 特殊页面没有任何覆盖，只有一条警告信息
 * 重定向页面未缓存，因此单击指向重定向的链接不会到达最终目标
 * pages with colons in the title (other than for a valid namespace) may still fail due to MediaWiki checking the DB to see if the title has a valid interwiki prefix. This occurs only if there is no interwiki cache entry for the page's prefix (see ) or   is falling back (or set to).
 * attempts to use non-view actions result in a plain page view, which may be confusing
 * there may be issues with the MySQL connection timeout which make it take prohibitively long before giving up, particularly if using persistent connections and the db dies later. Adjust mysql.connect_timeout (set to 3 or more) in php.ini to deal with this. Edit the webserver's php.ini not the cli php.ini.
 * fallback may fail if  is not   due to attempting a DB query
 * fallback may fail if  is set to   and   is falling back (or set to) DB_CACHE

Serving cached pages directly
By default, MediaWiki passes cache page with php. Here is how we use webserver configuration tricks to serve cached files directly without invoking MediaWiki or PHP at all.

First, setting. Then we add rewrite rules. See below.

Apache
The following mod_rewrite rule has been found to work in an  file on a shared webhost running Apache 2.2:

 RewriteBase / RewriteCond %{HTTP_COOKIE} !UserID= RewriteCond %{QUERY_STRING} !. RewriteCond %{DOCUMENT_ROOT}/w/html_cache/$1.html -s RewriteRule ^wiki/(.+)$ /w/html_cache/$1.html [B,L,NS]
 * 1) If a cached page exists under /w/html_cache, do an internal redirect to it:

However, this rewrite rule won't work properly for pages whose titles contain punctuation or non-ASCII characters. A tidy solution would be to use a RewriteMap, but this is not supported in .htaccess context. Instead, the following trick can be used to handle non-ASCII titles by pulling the URL-escaped title directly from the raw request line:

 RewriteBase / RewriteCond %{HTTP_COOKIE} !UserID= RewriteCond %{QUERY_STRING} !. ReWriteCond %{THE_REQUEST} ^GET\x20/wiki/([^\x20/]+)\x20HTTP RewriteCond %{DOCUMENT_ROOT}/w/html_cache/%1.html -s RewriteRule ^wiki/(.+)$ /w/html_cache/%1.html [B,L,NS]
 * 1) If a cached page exists under /w/html_cache, do an internal redirect to it:

The previous rewrite rules will handle requests of the form

https://site/wiki/Page_Name

To handle requests where the Page_Name is in the QUERY_STRING like

https://site/w/index.php?title=Page_Name

the following works:

 RewriteCond %{HTTP_COOKIE} !UserID= RewriteCond %{QUERY_STRING} ^title=([^&]+)$ RewriteCond %{DOCUMENT_ROOT}/images/cache/ns0\%3A%1.html -s RewriteRule ^ /images/cache/ns0\%253A%1.html? [B,L,NS]

This will still not match titles containing periods, slashes or other punctuation which the file cache escapes but browsers don't (or vice versa). One should also ensure that the appropriate Vary header gets sent:

Header append Vary Cookie

Also note that, since this redirect trick bypasses MediaWiki entirely, it won't respect. You may need to clear or rebuild the cache manually as needed instead.

Nginx
Since the nginx configuration language is pretty limited (it doesn't allow nested if statements, for example), it requires the ngx_lua module.

The following conf should be integrated inside your server block, and it assumes that:


 * you're using fancy urls like example.com/Page;
 * your cache folder is inside your MediaWiki folder (default);
 * you're already proxying *.php files to php-fpm (or whatever) in the last location block.

并且這有一些限制：


 * as with the Apache solution, you have to run a cron job or manually rebuild the cache files when they change;
 * pages whose title include non-ASCII characters are served through PHP (which should be transparent to the user anyway).

Change paths as needed.

Code stewardship
