【问题标题】:Sitecore multiple sites implementationSitecore 多站点实施
【发布时间】:2012-11-19 19:56:37
【问题描述】:

我的客户拥有 30 多个独立运营的组织单位。目前,所有 OU 都有由客户 IT 部门在不同 CMS 产品的单独实例中管理的网站。他们决定使用 Sitecore,因为它宣传的多站点功能。

很遗憾,当前 (6.5/6.6) 的默认实现无法正常工作,原因如下:

  1. 每次网站更改(添加/删除)时都需要更改 web.config。
  2. 所有内容项都必须位于“/sitecore/content”节点下。我们希望在/sitecore 下创建多个节点,例如/sitecore/OU1/sitecore/OU2等...
  3. 所有模板都必须在/sitecore/Templates 下。我们希望在每个组织单位下创建“模板”文件夹,例如/sitecore/OU1/Templates/sitecore/OU2/Templates等...
  4. 所有布局都必须在/sitecore/Layouts/ 下,并且在同一个文件系统目录中。随着网站数量的增加,这肯定会变得混乱。 /sitecore/OU1/Layouts//sitecore/OU2/Layouts 绝对是首选
  5. 我们需要隔离管理站点。每个站点管理员都需要登录并仅查看与其站点相关的内容/项目。因此,如果我们锁定/隐藏顶级 OU 节点,则更易于维护。
  6. 我们还需要隔离文件系统,以便开发人员在 web.config 中出现错误时不会关闭所有 30 多个站点。

在最近的 Sitecore 研讨会上,Tim Ward presented on the different ways to implement multiple sites in Sitecore。不幸的是,没有办法知道他指的是哪些产品。我不在,但我的老板出席了。我已尝试与 Sitecore 取得联系,但尚未收到回复。

我还联系了 Sitecore,询问有关 Sitecore Foundry 是否旨在满足这一需求的信息,但没有回应。

有谁知道实现这样多个站点 Sitecore 的方法吗?

【问题讨论】:

  • 您想跨站点使用什么?听起来您仍然想要完全独立的实例。

标签: sitecore sitecore6


【解决方案1】:

听起来 Tim 的多站点解决方案确实适合您。 它适用于需要隔离并且需要适合为其开发的独立供应商的大型多站点平台。

Sitecore Foundry 不适合您,它适用于更小类型的网站,并且不提供任何类型的隔离。

Tim 的解决方案可以在 here at github 找到(您可能已经从幻灯片中获得):

您可以通过 tiw@sitecore.net 给他发送电子邮件,他通常会很快回复。

他也在SDN forums 上很活跃,假设您可以访问它。

【讨论】:

  • 谢谢!我们确实看过 Github 项目。不幸的是(当时),由于缺少引用,我们无法编译它——或者我们只是不知道我们在做什么。也感谢关于 Foundry 的提示!
  • 缺少的引用是 Sitecore DLL。您可以在网站的 bin 文件夹中找到它们。我必须警告一下:这不是一件容易实现的事情,特别是因为没有文档。这不是开箱即用的 Sitecore 功能
  • Sitecore Foundry is not for you, it's meant for much smaller type of websites 你的意思是它不适合大型网站吗?我认为 Foundry 适用于可以在分布式环境中的任何规模的站点,您认为 MultipleSitesManager 是好还是类似于 Sitecore-Multisite-Manager
【解决方案2】:

我同意 Ruud 的观点,Tim 的多站点解决方案可能最能满足您的需求,这也是我很快会考虑的事情,我没有参加 Symposium,但它看起来非常有希望实现良好的分离。

  1. 是的,很遗憾,您需要为每个条目添加一个条目。
  2. 您可以将它们设置为 /sitecore/content/OU1、/sitecore/content/OU2 等
  3. 同样,您可以将它们设置为 /sitecore/templates/OUCommon、/sitecore/templates/OU1、/sitecore/templates/OU2
  4. 同样,您可以将它们放在子文件夹中,但正如您所说的那样会变得凌乱。
  5. 您实际上已经可以做到这一点。中断权限继承,因此您的角色(特别是 sitecore/Everyone)没有对 /sitecore/content 节点的读取访问权限,然后您的每个组将特别具有对每个单独站点/媒体库的继承的读取/写入/删除访问权限。将您的用户添加到特定角色中,他们将只能看到他们有权访问的树的部分。您还可以将此扩展到工作流,以便只有具有权限的用户才能批准相应的项目。虽然发布变得很棘手,但是您可以设置 Publishing.CheckSecurity=true,您只需要正确设置您的权限。安全访问查看器非常擅长查看为不同角色设置的权限。但与 Tim 的多站点解决方案相比,有这么多站点就成了管理员头疼的问题。
  6. 是的,重新启动将导致它们全部重新启动!我还希望看到日志文件的分离,以便更好地调试不同的站点。

【讨论】:

    【解决方案3】:

    很遗憾,Tim 的多站点解决方案不适用于我们的情况。我们最终做的是:

    1. /sitecore/content 下创建多个多个容器(如建议jammykam
    2. 创建多个 IIS 站点和与 [1] 中的每个容器对应的应用程序池
    3. 修改web.configwebsite 站点的rootPath 属性(针对每个站点)。
    4. 修改权限,让用户可以访问对应的容器。

    根据 sitecore 约定,我们仍然必须在 /sitecore/Templates 下创建模板和在 sitecore/layouts 下创建布局。通过分离 IIS 站点和应用程序池以及权限来实现隔离。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多