在 TYPO3 >= v12 中实现通用页脚预览渲染器

Question

我们一直在使用钩子

tt_content_drawFooter

在后端的页面布局视图中为某些内容元素添加附加信息。

某些信息将始终显示，例如它显示有关 18n_parent 内容元素的信息。有些信息特定于内容元素，例如文本媒体。

现在，升级到 v12 时，钩子就被删除了。有一些替换事件（但不适用于页脚），并且可以覆盖预览渲染器，例如适用于所有类型或特定内容类型。

实现看起来很简单，但我遇到了一个问题：

• 我可以使用

  PageContentPreviewRenderingEvent->setPreviewContent()

  覆盖内容（但不能覆盖页脚）
• 我看到设置页脚的唯一方法是在TCA中设置previewRenderer，然后继承之前设置的类。但对于不同的CE，这些将是不同的类

例如，这是默认值：

一般：

$GLOBALS['TCA']['tt_content']['ctrl']['previewRenderer'] = \TYPO3\CMS\Backend\Preview\StandardContentPreviewRenderer::class;

文字媒体：

$GLOBALS['TCA']['tt_content']['types'][$ctype]['previewRenderer'] = \TYPO3\CMS\Frontend\Preview\TextmediaPreviewRenderer;

容器内容类型：

$GLOBALS['TCA']['tt_content']['types'][$ctype]['previewRenderer'] = B13\Container\Backend\Preview\ContainerPreviewRenderer;

news_pi1：

$GLOBALS['TCA']['tt_content']['types']['news_pi1']['previewRenderer'] = GeorgRinger\News\Hooks\PluginPreviewRenderer;

因此，如果我设置 PreviewRenderer，对于我想要覆盖的每个预览渲染器，它必须是从不同 PreviewRender 继承的不同类。

此外，如果安装了扩展，这可能会覆盖预览渲染器，它会覆盖我的实现，或者我会覆盖它的预览渲染器。

它让原本简单的事情变得相当乏味、不灵活且不稳定。

我错过了什么？这是不可能的还是有什么好的解决方案？

（如果覆盖内容（而不是页脚），问题就不会出现：扩展可以为其本机 CE 设置预览渲染器，其他人可以使用该事件。但将这些附加信息放在页脚中似乎是个好主意，而内容实际上是为了显示预览）。

示例：

文档

• 页面内容预览渲染事件
• 变更日志 v10：功能：#78450 - 引入 PreviewRenderer 模式
• 变更日志 v12：中断：#98375 - 删除了页面模块中的挂钩

Answer 1

我想说你有一些选择：

选项1：
您可以对 StandardContentPreviewRenderer 进行 XClass 化。但这仅适用于直接使用 StandardContentPreviewRenderer 的 ctype。然后，您还必须对所有特定的 PreviewRenderer 进行 XClass。所以这可能不是一个好的解决方案。
https://docs.typo3.org/m/typo3/reference-coreapi/12.4/en-us/ApiOverview/Xclasses/Index.html

选项2：
为您想要操作的所有 ctype 实现自定义 PreviewRenderer。然后，您可以使用特征来实现您的修改。那么您仍然需要多个 PreviewRenderer，但您可以在特征中实现一次自定义代码。
https://www.php.net/manual/de/language.oop5.traits.php\ https://docs.typo3.org/m/typo3/reference-coreapi/12.4/en-us/CodingGuidelines/PhpArchitecture/Traits.html

选项3：
您可以修补您的 TYPO3 版本 StandardContentPreviewRenderer，并直接在修补程序中实现您的代码或调度您自己的 PSR-14 事件。
https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/Events/EventDispatcher/Index.html\ https://typo3worx.eu/2017/08/patch-typo3-using-composer/

我认为这三种解决方案都有一些（缺点）优点。 我倾向于选项 2，因为我认为这是最稳定的解决方案。