Extension:BetaFeatures/zh

测试功能扩展允许其他MediaWiki扩展向wiki用户提供测试反馈. 它通过用户设置界面和一些特殊页面记载测试中的一些数据.

对您的扩展使用新钩子
使用此扩展程序支持您的Beta功能非常简单. 在您的文件中注册一个类型为“”的钩子——语法几乎与钩子相同，只需稍作更改即可支持本例中需要的首选项类型.

在 中：

在 中：

Then, you can use the convenience function provided by BetaFeatures to check whether the feature is enabled.

You can also use a normal preference check, but don't check against truthy or falsy values - use the values from the HTMLFeatureField class.

Because the BetaFeatures class should be present everywhere, you could use the convenience function in any hook, special page, or anything else you wanted. Just be aware of potential performance or caching issues you may introduce with those changes.

If you want to also use your extension without BetaFeatures, you should also check for its existence, e.g.:

-{zh-hans:配置; zh-hant:組態;}-
The  config variable can be used to limit which beta features are shown in preferences. 默认情况下，它为空，并显示所有测试功能.

如果使用它，那么为了在参数设置中显示测试版功能，需要在白名单中列出. 此配置变量接受字符串数组. Each string should be the name of a beta feature as specified in the preference definition passed to. 例如，在上面给出的代码中，beta功能的名称是 ，因此您需要将该字符串添加到您的维基配置的 数组中：

高级用法
想尝试更酷的玩法？！

自动参与组
在此示例中，我们定义了一个“自动启用所有新测试功能”的选项 - 如果用户选中此选项，并且特定组中出现新功能，则用户将自动开启这些功能.

附属管理
Next up, we can actually define dependency management per-feature. To do this we first register the name of a hook that we want to use for this with the hook "", then we register a hook of that type that checks some dependency, and returns true if it's met or false if not.

You can abuse use this feature to do per-wiki disabling of features, if they're marked as dependent. But that sounds really hacky. You probably shouldn't. I can hear you thinking about it right now, just stop it.

数据库填充
There's a database table defined, and used, by BetaFeatures. But you might get confused by it if you try to use it locally.

We use the job queue to run updates for this table, when the cache expires (30 minutes TTL). If your wiki is configured to run jobs on each request, this will make about one request every 30 minutes reeeeeeally slow, but the rest will be relatively fast. If you configure your wiki to run jobs via cron, things will work much better.