3

I've been struggling to put SilverStripe behind a load balancer and I've been fixing multiple problems with rsyncing the instances and using shared storage and have almost got it stable, however I've found another issue which breaks the CMS.

Specifically when you try to add a link in the CMS in the TinyMCE editor, when the pop-up screen shows to select the page/file the JavaScript throws an exception that tinyMCE.activeEditor returns null.

I've rsynced the cache directory silverstripe-cache between the two servers and still there is a discrepancy between the m=timestamp of only a few seconds, but I'm guessing this is enough to cause tiny_mce_gzip.php to be forced to load again.

I have a shared redis cache for session storage, shared db, have rsynced the cache directory and use CodeDeploy to deploy the app so it should all be in sync. What other storage areas could cause the different m timestamp? Has anyone had success with SilverStripe CMS being used behind a load balancer without sticky sessions?

Community
  • 1
  • 1
Rudiger
  • 6,749
  • 13
  • 51
  • 102
  • AWS at least offers a "sticky sessions" configuration (I'm assuming other load balancers do too) which is a botch to fix some issues if all else fails. It would put the same user on the same server on every request. Not a solution to the problem but may be worth looking into if all else fails. – apokryfos Jan 27 '17 at 06:46
  • @apokryfos yeah I've had load issues in the past with load balancing, typically putting more load on one server which is why I want to avoid it. – Rudiger Jan 27 '17 at 07:29

1 Answers1

3

You can disable the gzip version of the HTMLEditor. I've seen this happen before. Try adding the following to your config/config.yml: HTMLEditorField: use_gzip: false

After that, do a full flush and try again?

Another option, is the javascript not syncing correctly. For that, you'll need to change the way the ?m=12345 is built. By default, it's built based on the timestamp.

I'll see if I can dig up the md5-based one, which might otherwise solve your problem.

*edit

Here ya go, try creating this somewhere in your project, and add the following to _config.php Requirements::set_backend(new MysiteRequirementsBackend()); https://gist.github.com/Firesphere/794dc0b5a8508cd4c192a1fc88271bbf

Actual work is by one of my colleagues, when we ran into the same issue.

Simon Erkelens
  • 762
  • 4
  • 8
  • So the md5 is created off entire file, so if it changes the md5 updates? Possible performance impact? – Rudiger Jan 27 '17 at 07:53
  • Yes, it's a minor performance impact. I'm not entirely sure, but would you prefer a working CMS that's a few milliseconds slower over a broken HTMLEditorField? The point of making an MD5 of the whole file, is to make it unique enough to work behind a load-balancer. And it only applies to the CMS. Haven't had any complaints about the CMS speed personally (SilverStripe Platform) – Simon Erkelens Jan 27 '17 at 07:56
  • Yeah, know what you mean, was just keen to know if you had noticed any. Working on implementing it now. – Rudiger Jan 27 '17 at 08:13
  • Sorry for the slightly sarcastic response. :) The difference is only visible in profiling tools. You won't get any customer complaints about it. At least, even with a lot of custom CMS javascript, never heard anyone complain. – Simon Erkelens Jan 27 '17 at 08:17
  • No worries, That use_gzip pretty much broke the cms however your code (I had already created my own requirements however it just synced the assets) did the trick. I did notice it was a little bit slower the first time I ran it but it wasn't really noticeable after the cache had been created. And as you said, either a slight bit slower or a non-functioning cms. – Rudiger Jan 27 '17 at 11:46