Silverstripe TinyMCE 在负载均衡器后面崩溃。答案

【问题标题】：Silverstripe TinyMCE crashes behind load balancer.Silverstripe TinyMCE 在负载均衡器后面崩溃。
【发布时间】：2017-06-12 19:03:27
【问题描述】：

I've been struggling to put SilverStripe behind a load balancer 并且我一直在解决多个与 rsync 实例和使用共享存储有关的问题，并且几乎已经稳定下来，但是我发现了另一个破坏 CMS 的问题。

特别是当您尝试在 TinyMCE 编辑器中的 CMS 中添加链接时，当弹出屏幕显示选择页面/文件时，JavaScript 会引发 tinyMCE.activeEditor 返回 null 的异常。

我已经在两台服务器之间同步了缓存目录silverstripe-cache，但m=timestamp 之间仍然存在差异只有几秒钟，但我猜这足以导致tiny_mce_gzip.php 被强制重新加载。

我有一个用于会话存储的共享 redis 缓存、共享数据库、已同步缓存目录并使用 CodeDeploy 部署应用程序，因此它应该全部同步。还有哪些其他存储区域可能导致不同的m 时间戳？有没有人成功地将 SilverStripe CMS 用于负载均衡器后面而没有粘性会话？

【问题讨论】：

AWS 至少提供了一个“粘性会话”配置（我假设其他负载均衡器也这样做），如果其他所有方法都失败了，这对于修复一些问题来说是个问题。它会在每个请求上将相同的用户放在同一台服务器上。不是解决问题的方法，但如果所有其他方法都失败了，可能值得研究。
@apokryfos 是的，我过去在负载平衡方面遇到过负载问题，通常会在一台服务器上增加更多负载，这就是我想避免它的原因。

【解决方案1】：

您可以禁用 HTMLEditor 的 gzip 版本。我以前见过这种情况。尝试将以下内容添加到您的 config/config.yml： HTMLEditorField: use_gzip: false

之后，进行一次完全冲洗并重试吗？

另一种选择是 javascript 未正确同步。为此，您需要更改?m=12345 的构建方式。默认情况下，它是基于时间戳构建的。

我会看看我是否可以挖掘基于 md5 的，否则可能会解决您的问题。

*编辑

来吧，尝试在项目中的某个地方创建它，并将以下内容添加到_config.php Requirements::set_backend(new MysiteRequirementsBackend()); https://gist.github.com/Firesphere/794dc0b5a8508cd4c192a1fc88271bbf

当我们遇到同样的问题时，实际工作是由我的一位同事完成的。

【讨论】：

所以 md5 是从整个文件中创建的，所以如果它改变了 md5 更新？可能的性能影响？
是的，它对性能的影响很小。我不完全确定，但您是否更喜欢一个比损坏的 HTMLEditorField 慢几毫秒的工作 CMS？制作整个文件的 MD5 的目的是使其足够独特，可以在负载均衡器后面工作。它仅适用于 CMS。个人对 CMS 速度没有任何抱怨（SilverStripe 平台）
是的，知道你的意思，只是很想知道你是否注意到了。现在正在努力实施。
抱歉有点讽刺。 :) 差异仅在分析工具中可见。您不会收到任何客户投诉。至少，即使有很多自定义的 CMS javascript，也没有听到任何人抱怨。
不用担心，use_gzip 几乎破坏了 cms，但是您的代码（我已经创建了自己的要求，但它只是同步了资产）成功了。我确实注意到第一次运行它时它有点慢，但在创建缓存后它并不明显。正如你所说，要么稍微慢一点，要么 cms 不起作用。