帮助对话：子页面

上一页历史记录已存档以用于备份帮助谈话：子页面/LQT存档12015年7月10日。

我们阅读

面包屑链接将自动显示在子页面的顶部，链接到存在的每个父页面。

太棒了。去找父母很容易。

但如果你是父母，那么即使有孩子也很难弄清楚！

等待。我找到了答案。。。好的，我来编辑页面。

等待。我可能会把页面弄乱。请其他人编辑它说：

我们看到，用面包屑很容易找到父母。

但找到孩子也不难。

1. 在侧面板中，单击“页面信息”。
2. 然后您将看到“此页面的子页面数”。单击它。

是否可能影响面包屑行（指向父页面的链接）的外观？

也就是说，是否可以定义将显示在面包屑中而不是默认页面标题中的文本？

我注意到使用{{DISPLAYTITLE}}不影响面包屑中使用的文本。

谢谢。

我也想知道

我有一个模板模板：示例包含

{{/subpage}}

和相应的模板：示例/子页面.何时模板：示例被隐藏到文档中，但它似乎试图隐藏有问题的文档/子页面（不存在）而不是模板：示例/子页面。该行为记录在哪里？我在这个页面的任何链接或任何谷歌搜索结果中都找不到任何内容。

我遇到了同样的问题，就好像主题：Uuen4em4k7ji6q01展开子页面路径时在内部使用。

有没有一种方法可以显示主名称空间中的所有页面，这样带子页面的页面就会呈现为一个展开三角形，这样我就可以在单击时显示它们的子页面？

使用1.35.0 Bitnami图像进行开发，并添加到LocalSettings.php

$wgNamespacesWithSubpages[NS_MAIN]=true；

似乎不起作用-没有面包屑，只是用斜线将页面解释为页面。我不知道如何诊断这个问题。之前在其他安装中完成了此操作，没有任何问题。

欢迎提出意见。

目前，当我浏览一个大颗粒子页面时，标题变得过长，例如“a large archive/Big-data/data of the wasted ones/data block#1”。我想隐藏父页面，只留下名称“数据块#1”，因为面包屑扩展已经显示了页面的位置。这是已经在某个地方实现了吗？还是我必须破解？

我正在寻找同样的东西，你是否偶然找到了解决方案？

我不得不修改MediaWiki的源代码来创建这种行为。

你能概述一下你采取的步骤吗？提前谢谢你

在页面加载时，更改标题文本以仅包含最后一个斜杠后面的内容。困难的部分是找到插入代码的位置。

大家好，课文说到

“大索利多金币”（U+29F8），其结果是福⧸巴。。。。

但由于该字符在当前显示字体中不可见，我只看到了内部带有29F8的默认方形图像。这里最好包含这个字符所代表内容的图像，而不是使用其unicode值。谢谢。

克里斯蒂安·维娅(谈话)2019年6月29日19:39（UTC）

目前还没有涉及重命名语义。如果根页面被重命名，那么子页面是否会随之而来，或者用户是否为自己创建了一个大型工作项目？如果是第二种情况，该软件是否会警告用户即将发生不好的事情~~~~

是的，那是缺失的。我补充了一点简短的说明。我认为关于这一点，可能还有更多可说的。

你好，

我有一个带有很长名称和一些子页面的模板，类似模板：带有very_very_very_long_title的模板,模板：模板_with_very_very_ very_long_title/sub1和模板：Template_with_very_very_long_title/sub2.

因为标题很长，所以转写模板及其子页面有点麻烦（很难记住长标题的确切措辞等），所以我想使用重定向。我创建了新缩写模板：长只需：

#纠正[[模板：模板_with_very_very_0ry_long_title]]

因此，只需键入即可轻松地隐藏模板｛｛Long｝｝.

然而，问题是模板子页面并没有从缩写中受益，所以{{长/sub1}}和{{长/sub2}}除非我显式创建这些页面并手动将其重定向到原始模板的子页面，否则无法工作。

这对我来说有点奇怪，特别是因为可以创建一个模板：Long/sub1内容不同于模板：模板_with_very_very_ very_long_title/sub1.

这是子页面的预期行为吗？

任何想法都将不胜感激。。。

我想是这样的。页面名不是层次化的文件系统对象，而是独立的数据库记录。

斜杠/字符仅模拟分层文件系统。我们可以在创建a/b之前创建子页面a/b/c，也可以在创建a/b/c之后返回并创建a/b。

页面上的选项卡或子页面上的面包屑只模拟一个软件对象，该软件对象是一个内部实体，具有指向其所有页面的指针。例如，移动页面名称时，对话页面不会移动，但必须独立移动。

重定向只是模仿一个别名，并且看起来是一个内部指针。事实上，重定向是一个独立的页面，就像子页面一样，就像所有页面一样。

在“Where it works”一节中有很多关于使用斜杠的信息。我认为这是不必要的信息，因为我从未见过人们使用这些策略来解决斜杠问题。

我是添加该信息的编辑，虽然我记得心里有一个特定的用例，但我忘记了它是什么，无法从那天（2011年5月12日）对mediawiki.org的编辑中找出它。我知道我和Brion谈过这件事，可能是在IRC上，也许值得挖掘IRC日志来找出我的主要动机，因为这可能证明我应该为其他有相同需求的人保留信息。无论如何，它似乎并不十分重要，所以请随意删除有关替代斜杠的信息；如果有必要再次挖掘信息，这个线程和页面的历史记录应该足以启动。干杯！