Php Silverstripe TinyMCE在负载平衡器后面崩溃。

我一直在修复实例同步和使用共享存储的多个问题，并且几乎使其稳定，但我发现另一个问题破坏了CMS

特别是当您尝试在TinyMCE编辑器的CMS中添加链接时，当弹出屏幕显示以选择页面/文件时，JavaScript抛出一个异常，

TinyMCE.activeEditor

返回

null

我已经在两台服务器之间重新同步了缓存目录

silverstripe cache

，但是

m=timestamp

之间的差异只有几秒钟，但我猜这足以导致

tiny_mce_gzip.php

再次被强制加载

---

我有一个用于会话存储的共享redis缓存，shared db，已重新同步缓存目录，并使用

CodeDeploy

部署应用程序，以便所有应用程序都应同步。哪些其他存储区域可能导致时间戳不同？是否有人成功地将SilverStripe CMS用于没有粘性会话的负载平衡器后面？

您可以禁用HTMLEditor的gzip版本。我以前见过这种情况。尝试将以下内容添加到

config/config.yml

：

HTMLeditor字段：
使用_gzip:false

之后，进行完全刷新并重试

另一个选项是javascript没有正确同步。为此，您需要更改

？m=12345

的构建方式。默认情况下，它是基于时间戳构建的

我会看看是否能找到基于md5的，否则可能会解决你的问题

*编辑

现在，试着在项目中的某个地方创建它，并将以下内容添加到

\u config.php

需求：：设置_后端（新MysiteRequirementsBackend（））；

---

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

AWS至少提供了一种“粘性会话”配置（我假设其他负载平衡器也提供了这种配置），这是一种在其他所有配置都失败的情况下修复某些问题的拙劣方法。它会在每次请求时将同一用户放在同一服务器上。这不是问题的解决方案，但如果所有其他方法都失败，则可能值得研究。@apokryfos是的，我过去在负载平衡方面遇到过负载问题，通常会在一台服务器上增加负载，这就是我希望避免的原因。因此，md5是在整个文件中创建的，所以如果它更改了md5更新，又如何？可能的性能影响？是的，这对性能影响很小。我不完全确定，但您是否更喜欢比损坏的HTMLeditor字段慢几毫秒的工作CMS？制作整个文件的MD5的目的是使其具有足够的唯一性，以便在负载平衡器后面工作。它只适用于CMS。我个人对CMS速度（SilverStripe平台）没有任何抱怨是的，知道你的意思，只是想知道你是否注意到了。现在正在实施它。抱歉有点讽刺的回应。：）这种差异仅在分析工具中可见。你不会收到任何客户对此的投诉。至少，即使有很多定制的CMS javascript，也从未听过任何人抱怨。不用担心，使用_gzip几乎破坏了CMS，但是你的代码（我已经创建了自己的需求，但它只是同步了资产）起了作用。我确实注意到第一次运行时速度稍微慢了一点，但在创建缓存之后就不太明显了。正如你所说，要么稍微慢一点，要么就是cms不起作用。