我有很多应用程序,我想用MediaWiki编写产品手册材料。
我可以在myorganization.com中为每个应用程序安装一个wiki作为子域,例如myorganization.com和/或创建一个WikiFarm,每个站点都有自己的LocalSettings.php,但这似乎变得非常混乱,需要为每个产品手册维护多个配置和数据库。
名称空间似乎是一条道路,似乎在细粒度的安全性方面带来了好处,例如,为App1贡献内容的用户很可能无法为App2贡献内容。
这意味着在wiki.myorganization.com/wiki/中只安装一个以应用程序名称和页面标题为前缀的手动页面,例如wiki.myorganization.com/wiki/SomeApp:Some_Title和wiki.myorganization.com/wiki/OtherApp:Some_Title。
这将确保主题/标题,如User_Management,这将需要存在于两个应用程序产品手册可以共存。这也意味着一个单一的中央储存库所有的组织产品知识。
此外,我选择MediaWiki作为它的API。最终的目标是能够在应用程序本身中显示来自MediaWiki的在线产品手册内容。我不确定是否将每个应用程序的手册页面分离到它们自己的名称空间中,会给查询/检索这些内容带来任何挑战吗?
我想听听更有经验的MediaWiki用户的想法和/或他们的建议。
非常感谢。
发布于 2020-12-18 02:36:23
考虑一个事实,即自定义命名空间的数量为有限的到9900。
还请注意,在MediaWiki中有特定的每个名称空间设置,包括名称空间声明本身。有扩展https://www.mediawiki.org/wiki/Extension:SpecialNamespaces,但自2009年以来一直没有更新。
我建议另一种解决方案:将所有页面存储在主命名空间中。将与描述产品的主页面的子页相关的页面分组(用于主命名空间的启用)。
保护页面可以通过web而不是LocalSettings.php来限制对每个产品编辑的访问,尽管您需要为每个产品定义一个保护水平和一个用户组;但是后者也必须用于名称空间保护。虽然我怀疑每个产品都有一个单独的产品经理,所以您可能真的只需要几个用户组。
https://stackoverflow.com/questions/65350450
复制相似问题