Sitecore:如何避免破坏通过 Control-Datasource 引用的项目的依赖关系

发布于 2024-11-16 16:07:17 字数 372 浏览 2 评论 0原文

使用 Sitecore.NET 6.3.0。

我们的 Sitecore 内容有大量项目通过控件渲染集合引用其他项目。这是通过将项目的路径设置为控件的数据源来完成的。

由于此链接是通过链接项的路径(而不是 ID)指定的,因此当前如果您更改链接项的位置或将其完全删除,则可能会中断该链接。

为了防止损坏的链接,或者至少在发布之前检测到它们,避免此问题的最佳方法是什么?

我知道可以以标准方式链接(通过 id 引用),但这将排除我们必须通过相对路径链接的任何链接。

有没有什么方法可以检测,甚至更好地防止此类损坏的链接?

编辑:这更类似于将数据源分配给演示布局详细信息中的子布局,而不是在代码中执行任何操作。 (这是内容编辑器会做的事情)。

Using Sitecore.NET 6.3.0.

Our Sitecore content has a great deal of items that refer to other items via the control renderings collection. This is done by setting a path to the item as the controls' datasource.

Since this link is specified via a path - not an id - to the linked item, it is currently possible to break the link if you change the linked item's location, or delete it completely.

With the goal of either preventing broken links, or at least detecting them before a publish, what is the best approach to avoiding this problem?

I'm aware that it is possible to link in a standard way (reference by id), but this would rule out any links where we must link via relative paths.

Is there any way to go about detecting, or even better preventing broken links of this kind?

EDIT: This is more akin to assigning a DataSource to a sublayout in presentation layout details, rather than doing anything in code. (Its something a content editor would do).

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

天涯离梦残月幽梦 2024-11-23 16:07:17

我不确定最好的方法是什么,但我确实同意这里可能会出现很多问题。

在阅读您的文章时,我在想......虽然这是一个顽皮的举动,但您可以更改“数据源”字段的字段类型。当然,在系统模板中进行修改是值得警惕的 - 但在这种情况下,替代方案似乎稍微更糟糕。

如果这样做,您还需要挂钩 getRenderingDatasource 管道,并覆盖 GetDatasourceLocation 步骤。

我自己没有这样做过,所以不能保证它会起作用。然而看起来相当简单:-)

I'm not sure what the best approach is, but I do agree there's potential for a lot of problems here.

While reading your post, I was thinking... albeit a naughty move, but you COULD change the field type of the "DataSource" field. Of course, mucking about in system templates is something to be cautionable about - but in this case, the alternative seems slightly worse.

If doing so, you would need to hook into the getRenderingDatasource pipeline as well, and override the GetDatasourceLocation step.

I've not done this myself, so cannot guarantee it will work. Seems fairly straight forward however :-)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文