Grav-plugin-admin: UX：添加模块化内容

我们肯定有一些关于如何改进模块化页面管理的计划。 现在的方式只是代码方面的简单性和一致性问题。 这还不是理想的设置，但它可以工作，并且一些文档也将有助于改善这种情况。

感谢安迪的回复。 我仍然非常关心当前演示文稿的用户体验，尽管只是在页面创建方面，您是否会考虑在这一点上进行任何更改？

只是一个快速的后续想法 - 如果没有别的我认为将“添加模块化内容”对话框的文本从“添加模块化内容”更改为“将模块化内容添加到页面”可能会有所帮助。 从长远来看，我知道您已经有计划，我仍然认为拥有一个能够创建父、子或模块化内容页面的“添加页面”对话框可能是一种可行的探索方法。

我还想知道将“父页面”下拉菜单作为“添加页面”和“添加模块”中的第一项是否也会对用户更有帮助，因为该决定确实是在命名页面之前做出的，等等。你怎么看？

+1 用于改进管理插件中模块化页面的处理

从非技术用户的角度来看，我认为将模块化子页面放在父页面的联合中会更合乎逻辑。 因此，也许内部（=模块化子页面）对用户隐藏，他只能在父页面内查看和添加单独的内容块。

我同意@Jugibur

一个普通的客户只会想“我想编辑这个页面”。 他们可能会单击页面的名称，然后看到：

无论他们是想添加一些内容还是编辑那里的内容，他们都不知道从这里做什么。 设计好它是一个挑战，但我正在想象一个页面，我可以在每个页面模块的可编辑框中按照它们出现的顺序滚动，以及一个添加新模块的按钮。

就像我之前说的，这是我们想要重新审视的东西。 我们知道这并不理想，但它很实用。 即它有效。

我们现在正在对管理员进行整个 JS 重写。 这将允许我们开发我们从一开始就打算的模块化页面 UI，但只是没有时间在初始版本中正确实现。

我认为现在最大的问题不是 UI，而是无法手动订购模块化页面。 我认为这应该是默认设置，因为模块化页面最常见的用例是内容行。 对于那些有日期或姓名顺序的人来说毫无意义。

还有什么有助于连接到这个https://github.com/getgrav/grav-plugin-admin/issues/735 。 此外，我们应该能够定义客户端不可编辑的页面。 有了这些东西，您可以让客户端编辑页面变得非常安全。

像这样的事情会很棒：
https://craftcms.com/docs/matrix-fields
https://github.com/benjamminf/craft-neo

关于最近的 #1174 合并，有一些关于 Admin 的 UI 如何处理这种歧义的讨论。 引用该问题末尾的 Paul Massendari 的话：

我们应该将“添加模块”重命名为“添加模块”吗？ https://github.com/getgrav/grav-plugin-admin/blob/develop/languages/en.yaml#L36

添加内容的典型按钮如下所示：

考虑到 Grav 具有的三种主要结构类型，这正如预期的那样：常规页面、文件夹和模块化页面。 但是，在其他上下文中也会出现相同的下拉菜单 - 这会导致页面和模块化页面的模糊性。 引用 Slack 的话：

从概念上讲，模块化页面不是带有集合的常规页面，它是一个包含组件的结构 - 模块 - 并且不应该有任何其他类型的页面从属于它。 因此，虽然模块化页面可以有常规的子页面 /sample/page ，但其内容完全由仅在模块中绘制的集合定义，并且这些模块在其他地方不可见或无法路由。 当然，作为一个结构，它实际上只是 Page 的一个子集，允许更轻松地管理组件 - 使用 Twig 和 YAML 可以实现相同的效果 - 但在概念层面上，它_不应该_混入常规页面。 这就是为什么从 Grav 如何定义 Pages 的角度来看，在“添加”下拉列表中分离关注点会更可取。

从这个角度来看，Modular _不应该_有常规的子页面或除 Modules 之外的其他子项，但在当前的 UI 中，这些可以非常自由地混合。 Paul Massendari 的一个例子：

- home
- blog
  -_introtext
  -_latestarticles
  - _subscribe  
  - article1
  - article2

这本身在语义上非常有意义，但是保留了常规 Page 和 Modular 之间的歧义。 因此，为了将两者分开——尽管 Modular 是 Page 的一个子集——UI 应该将选择限制在适合上下文的范围内。 /admin/pages 中的下拉菜单应该提供添加页面、文件夹或模块化，在模块化页面上它应该提供给添加模块，并且在页面和文件夹中它还应该提供添加所有三个。

上下文分离摘要（8 月 28 日更新）：
与@paulhibbitts和@paulmassen进一步讨论，并在某种程度上得出了这种区别——尽管为了清楚起见，“Child”应该是“Child Page”。

+在页面列表视图上添加菜单项
添加页面
添加列表页面
添加模块化页面
（新增文件夹）

+在标准页面视图上添加菜单项
添加孩子
（新增文件夹）

+在列表（父）页面视图中添加菜单项
添加孩子
（新增文件夹）

+在模块化（父）页面视图上添加菜单项
添加模块
添加孩子
（新增文件夹）

其中文件夹在括号中，因为它应该始终位于底部，并通过视觉指示器（例如细顶边框）与上述页面类型分开，以表明它_不是_页面类型，而上述所有内容都适合上下文类型。 他们三个; Page、Listing、Modular 是默认的标准类型，并且https://learn.getgrav.org/content/content-pages可能应该更新以反映这一点。

最清晰的逻辑似乎是：页面是 Grav 渲染的任何 Markdown 文件，而列表页面是用于枚举其独立子页面的页面的子集，而模块化页面是位于其子页面的页面的子集作为自身的一部分。 因此，Listing 链接到单独的子项，Modular 在其内部显示它们。 Page 和 Listing 有常规的子页面，Listing 主要以某种有序的方式列出它们。 只有模块化有模块。

但是，主题还需要通过它们支持特定页面类型的蓝图进行通信。 并非所有主题都有默认模板，或者有一个用于列表或模块化的模板。 因此，对话、模式、按钮或其他添加页面的方法应该反映主题通过其模板固有地支持的内容。