Silverstripe TinyMCE crashes behind load balancer. - php

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?

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.

Related

Suspected Caching Issue with CakePhp 4

I'm recently getting back into programming after taking a break for quite some time. I'm currently trying to rebuild my CakePhp 2.X apps for CakePhp 4.X. I'm developing in a local environment using Bitnami WAMP stack.
The issue is that development is very slow because changes do not seem to be taking effect immediately. I have tried disabling all caching by using
Cache::disable();
I've tried placing this line in various places
config/boostrap.php
config/app.php
config/app_local.php
src/application.php
How this is impacting me: I'll make an update, for instance, to a model table file or controller file. I'll go refresh my site to preview the change and either there is no update or there might be an error. To fix the error, I try to undo the changes I made. I go back to my browser and hard refresh the page. I continue to see the same error for 10+ minutes. This often leads me to wanting to undo previous steps but I know that those previous steps didn't cause the issue and it was only the most recent change that caused it. It's making it difficult to keep track of what changes are causing issues and what solutions are working. Even something as simple as updating my navigation element (templates/elements/nav.php) to add a new link does not show on the page when I refresh. I've also tried clearing my browser cache (I use Chrome).
Did you try to clear all keys? You can do it with:
// Will clear all keys.
Cache::clear();
Cache::disable() should work also.
You can also delete the contents of /tmp/cache/ if the caching is set on File.
Maybe the problem is Bitnami WAMP itself. Try to disable the server cache:
https://docs.bitnami.com/installer/infrastructure/wamp/administration/disable-cache/
If you are developing on top of an AMP Stack or customizing any
Bitnami Stack, your files (like JavaScript files) may be cached by the
server and even you modify them your changes will not appear to be
applied.
In order to disable the cache in the server and let the files be
served each time, disable PageSpeed for Apache and OPCache for PHP,
enabled by default

Too many cache file in system/cache folder codeigniter

I have a music site developed on CodeIgniter with youtube API without database. Recently I have noticed that too many files are getting generated in system/cache folder.
How can I stop generating this cache files? Note that I am not using any cache method.
system/cache is NOT default codeigniter cache directory at first. I would not store cache in there, as its framework main folder. Default is application/cache.
By default, CI does NOT cache anything. So your application is build with caching.
You told you don't use database, so it's not DB cache I assume.
Check in your app for somethign like "$this->load->driver('cache'".
Caching can be loaded WITHOUT additional parameters like
$this->load->driver('cache'); OR with parameters like
$this->load->driver('cache',array('adapther'=>'xxx'));
https://www.codeigniter.com/userguide3/libraries/caching.html
Now, in your app search for $this->cache->save OR $this->cache->file->save
if you found this, it means you are using CI caching.
Problem is, you cannot just remove cache loading, as app initiates cache object, and your app will fail, unless you rewrite all places where caching is used.
Now, you have few choices:
1.just clean cache dir with some script periodically via cron.
you can change cache folder permissions to NON writable, which will generate warnings in your logs, so logging should be disabled. This is not the right way IMHO, as can cause fatal errors/blank pages but just one of possible solutions. If file caching is used, this should not cause issues, while in other cases it could.
you can extend caching library, and simply create empty cache SAVE function. In this case your files will not be saved.
you can cache to memcached, if you have it on your server. Well, if your caching is written like $this->cache->file->{operation}, then you will need update all those to $this->cache->memcached->{operation}. If caching is written like $this->cache->{operation}, you can just adjust configuration something like
$this->load->driver('cache',array('adapther'=>'memcached'));
and set memcached server info in config file. (config/memcached.php)
You told you are not using any caching method. So you should not find any of code I put above.
The last thing I can think about is
$this->output->cache(xxx);
where xxx is cache time in minutes.
it forces entire generated page to be cached;
if you find such lines, you can try comment them out and see what happens
https://www.codeigniter.com/user_guide/general/caching.html
there is a good note: If you change configuration options that might affect your output, you have to manually delete your cache files.
If absolutely none from the examples above is not found, you might use some custom make caching.
Good luck!
Put this in your common controller
$this->output->delete_cache();

Mystery: Drupal loading old version of file

I am working on changing a Drupal 7 site and have run into strange behavior where an old version of a file I've changed keeps re-appearing. I've flushed caches via the admin interface as well as truncating the cache_ tables.
On my staging server (which I have access to), things work fine. On our production server (which I do not have SSH access to and cannot easily get access to), they do not and I have limited ability to debug, so I have to guess. I suspect there is some Drupal or Apache setting that is causing these old files to be shown because the filesystem has identical contents. The behavior is almost as if Drupal will look for any file named the same (even if it is in the wrong directory) and show that.
In my case, I have all my files under /var/www/html (standard LAMP setup). At one point, I tar cfz the entire thing and kept that at /var/www/html/archive.tgz (not removing it by mistake). So now I'm wondering if somehow Drupal is reading the contents of that archive and using the old file. Sounds crazy, but has anyone run into something like that?
The other possibility is that my cache cleaning is still limited in some way. Outside of truncating cache_ tables in the database, is there any way to forcibly remove all cached entries? Any insight into this mystery would be appreciated.
Obviously, your production server runs some additional caching proxy like Varnish. You need to clear cache there as well.

Handling Symfony's cache in production

I have a Symfony2 website that I'm testing in production. I went ahead and cleared its cache because I've made and will probably make more modifications, however there is a small problem:
While the cache is being cleared and say, afterwards I want to warm it up, someone that accesses the website rebuilds the cache. That creates a small problem as the cache is being built, but not completely, while half of it gets deleted because the deletion is still in progress.
What happens afterwards is, the cache is built, but only a part of it. Symfony thinks that the cache is built entirely, and runs without trying to build it anymore, but it runs on a half-built cache. The deletion process is a bit long (~15 sec), so in this timeframe nobody must try and create the cache by accessing the website.
Either that, or the cache is completely built, it overwrites the old cache, and the system treats these new files as old ones, deletes part of them and some others remain. Not entirely sure, I'm not sure how to check this.
For instance, one of the errors that I'd get is
The directory "D:\xampp\htdocs\med-app\app\app\cache\dev/jms_diextra/metadata" does not exist.
If I wouldn't use that bundle I'd get another cache problem from Doctrine. This appears at every website access until I delete the cache again WITHOUT anyone accessing the website. it completely blocks access to the website and makes it non-functional.
Also, what about the warmup? That takes a while, too. What if someone accesses the website while the cache is being warmed up? Doesn't that create a conflict, too?
How to handle this problem? Do I need to close the apache service, clear and warm cache and then restart apache? How is this handled with a website in production?
EDIT
Something interesting that I have discovered. The bug occurs when I delete the cache/prod folder. If I delete the contents of the folder without deleting the folder itself, it seems the bug does not occur. I wonder why.
Usually it is good practice to lock the website into maintenance mode if you're performing updates, or clearing the cache for any other reason in the production. Sometimes web hosting services have this option to handle this for you, or there is a nice bundle for handling maintenance easily from the command line.
This way you can safely delete the cache and be sure no-one visits the page and rebuilds the cache incorrectly.
Usually if you have to clear the Symfony cache it means you're updating to a new version - so not only are you having to clear the cache, but you're probably having to dump assets and perform other tasks. In this case what I've done in the past that has worked very well is to treat each production release as its own version n its own folder - so when you install a new version you do it unconnected from the webserver, and then just change your webserver to point to the new version when you are done. The added benefit is if you mess something up and have to perform a rollback, you just immediately link back to the previous version.
For example, say your Apache config has DocumentRoot always points to a specific location:
DocumentRoot /var/www/mysite/web
You would make that root a symlink to your latest version:
/var/www/mysite/web -> /var/www/versions/1.0/web
Now say you have version 1.1 of your site to install. You simply install it to /var/www/versions/1.1 - put the code there, install your assets, update the cache, etc. Then simply change the symlink:
/var/www/mysite/web -> /var/www/versions/1.1/web
Now if the site crashes horribly you can simply point the symlink back. The benefit here is that there is no downtime to your site and it's easy to rollback if you made a mistake. To automate this I use a bash script that installs a new version and updates the symlinks with a series of commands connected via && so if one step of the install fails, the whole install fails and you're not stuck between version limbo.
Granted there are probably better ways to do all of the above or ways to automate it further, but the point is if you're changing production you'll want to perform the Symfony installation/setup without letting users interfere with that.

wordpress was updated to 3.8.1 version and now iam unable to edit any of the posts in visual area and text area

-i updated my WordPress today morning to 3.8.1 version , after the update of my WordPress i unable to update any of them and unable to view them in visual field and text field when i press edit my post.
Does the same thing happen if you try using a different browser that you do not normally use? For example, if you use Chrome, try and see if it works in Firefox.
If one browser works but the other does not, then you are experiencing a fairly common caching issue, where your browser is caching javascript files from the old version instead of retrieving the newly updated files.
This happens especially if you have certain types of "speed optimization" plugins or similar code running on the site, because these often create settings to have longer cache intervals for common static files such as images and css and javascript files, to make browsers not have to retrieve as much data. WordPress uses cache-busting version numbers to try to reduce this problem, but these methods are not always effective.
The only solution is to clear the browser cache, but a surprising number of people have difficulties doing that. Browsers are persistent buggers. I recommend clearing the cache, restarting the browser completely (note that some browsers, like Chrome, remain running in the background.. you have to actually kill them manually from the taskbar or similar), and then clearing the cache again after restarting it. Even then, it may take a few attempts.
Alternatively, you may have not have gotten a complete upgrade and some of the files may not be installed. There is a "Reinstall" button on the Upgrade screen that will do a complete file installation over your existing installation. This will not erase any data, it simply gets the core files from WordPress.org and reinstalls them in-place. You can try this to see if it helps. As always, before performing anything like this, make sure you have an up-to-date backup of the site.

Categories