tractorcow / silverstripe-dynamiccache

Simple on the fly caching of dynamic content for Silverstripe
39 stars 27 forks source link

Problem viewing pages in admin section when dynamiccache turned on #11

Closed colinburns closed 10 years ago

colinburns commented 10 years ago

Hi Guys,

I'm having some problems that I thought someone here might be able to shed some light on. When I enable dynamiccache via the config.yml file - which I have copied over from dynamiccache.yml file I am able to get into the CMS section but unable to do anything in there. For example if I click on a page in the site tree then I get the "loading" image come up but the page doesn't change at all. If I click into security or any other section the same thing happens.

I assume I just have something configured incorrectly in the cache. I can't see any error messages coming up or in my log file so I don't really know where to start looking...

Here is my config.yml file.

Sorry if I am posting this in the wrong place.

Cheers, Colin

DynamicCache:
# Global override. Turn to false to turn caching off.
  enabled: true
# If a header should be used to opt in to caching, set the regular expression
# here which will match the specified header.
  optInHeader: null
# If a header should be used to explicitly disable caching for a cache, set the
# regular expression here which will be used to match the specified header
  optOutHeader: '/^X\-DynamicCache\-OptOut/'
# Header to use by the module attempting to opt out
  optOutHeaderString: 'X-DynamicCache-OptOut: true'
# Header prefix to use for reporting cache results
  responseHeader: 'X-DynamicCache'
# If caching should be limited only to specified urls set the regular expression
# here which will be used to match those urls
  optInURL: null
# If caching should be disabled for specified urls set the regular expression here
# which will be used to match those urls
  optOutURL: '/(^\/admin)|(^\/dev($|\/))|(\/[A-Z])/'
# Determine if caching should be separated for different hostnames. Important if
# running off a system that serves different content for different hostname, but
# still uses the same backend, such as the subsites module
  segmentHostname: true
# Determine if caching should be enabled during ajax
  enableAjax: false
# Duration of the page cache, in seconds
  cacheDuration: 3600
# Determines which headers should also be cached. X-Include-CSS and other relevant
# headers can be essential in instructing the front end to include specific
# resource files
  cacheHeaders: '/^X\-/i'
# If you wish to override the cache configuration, then change this to another
# backend, and initialise a new SS_Cache backend in your _config file
  cacheBackend: 'DynamicCache'
tractorcow commented 10 years ago

Hi @colinburns,

Just a heads up, if you aren't changing anything, you don't need to even have a config file for DynamicCache; The defaults should work just fine for 99% of the cases.

Have you done a flush to ensure the site is initialised with the correct settings?

Which server software are you on? Which SS version are you using? Are you using composer? If so let me see your composer.json and I'll try to replicate.

colinburns commented 10 years ago

@tractorcow ummm - yeah I guess those would be useful this to provide - sorry about that

SS3.1 yes using composer (although very new to it) Server Dev Server = Macbook Pro running PHP 5.3.26 Live Server = Centos running PHP 5.3.23 I tried ?flush=1, ?flush=all and /dev/build just in case I was missing something.

{
    "name": "silverstripe/installer",
    "description": "The SilverStripe Framework Installer",
    "require": {
        "php": ">=5.3.2",
        "silverstripe/cms": "3.1.1",
        "silverstripe/framework": "3.1.1",
        "silverstripe-themes/simple": "*",
        "silverstripe/userforms": "dev-master",
        "tractorcow/silverstripe-dynamiccache": "3.1.*-dev"
    },
    "config": {
        "process-timeout": 600  
    },
    "minimum-stability": "dev"
}

If you are unable to replicate let me know and I can provide you access to the site so you can at least see what I am talking about. I have disabled dynamiccache at the moment I can turn it back on if needed.

Thanks for the assistance.

tractorcow commented 10 years ago

If you're using chrome, did you notice anything in networking in the request responses while browsing the CMS?

tractorcow commented 10 years ago

I replicated your project using your composer, and it seems to run fine to me. =( I'm running on Win / apache with PHP 5.3.25.

I'll let you get back to me on your server request / responses and maybe you can debug it that way?

colinburns commented 10 years ago

The URL Changes and if I do a "proper" refresh of that page it loads correctly... As you can see the request looks as though it is successful. But it info is just not updated when trying to change pages.

I looked and it seems as though there isn't any response data from those requests...

screen shot 2013-11-04 at 10 32 30 am

screen shot 2013-11-04 at 10 35 39 am

tractorcow commented 10 years ago

Here's a useful hint for using dynamiccache; If any cache action has occurred (even if it was bypassed) there should be an X-DynamicCache header response. Did you get anything in your headers?

image

If there's no header, that means dynamic cache is being bypassed.

Also, I would be careful not to browse the admin with ?flush in your querystring. This would cause your admin to flush every request. Just do a normal flush on your homepage and then browse your admin.

Make sure you have errors turned to on and site set to dev mode when testing locally.

tractorcow commented 10 years ago

On second thought, I don't think your admin COULD even work while flushing, because a successful flush usually results in a page redirect, which would wreck the AJAX behaviour of the CMS. :P Maybe that's the cause?

colinburns commented 10 years ago

It doesn't look like there is any dynamic cache headers going on in there... but as soon as I turn the cache off and /?flush=1 etc the CMS works fine again.

Not a big deal. I'll try it again on another site to see if I can replicate the issue.

Thanks for your help - I appreciate it.

Request URL:http://local.acrossculture.org/admin/pages/edit/show/2?flushtoken=b664d1c897fb1648c06ab79defeed1e2&flush=1
Request Method:GET
Status Code:200 OK
Request Headersview source
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Cookie:cms-panel-collapsed-cms-content-tools-AssetAdmin=true; PHPSESSID=v9dqfvhbhkpgt5fl0candelca7; cms-panel-collapsed-cms-content-tools-CMSMain=false; cms-panel-collapsed-cms-content-tools-CMSPagesController=true; cms-panel-collapsed-cms-menu=false; PastMember=1
Host:local.acrossculture.org
Referer:http://local.acrossculture.org/admin/pages/edit/show/2?flush=1&flushtoken=a17f2f219b64193c4d1a3f2750bc168b
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36
X-Pjax:Content
X-Requested-With:XMLHttpRequest
Query String Parametersview sourceview URL encoded
flushtoken:b664d1c897fb1648c06ab79defeed1e2
flush:1
Response Headersview source
Cache-Control:no-cache, max-age=0, must-revalidate, no-transform
Connection:Keep-Alive
Content-Type:text/json
Date:Sun, 03 Nov 2013 21:34:56 GMT
Expires:Thu, 19 Nov 1981 08:52:00 GMT
Keep-Alive:timeout=5, max=97
Pragma:no-cache
Server:Apache/2.2.24 (Unix) DAV/2 PHP/5.3.26 mod_ssl/2.2.24 OpenSSL/0.9.8y
Set-Cookie:PastMember=1; expires=Sat, 01-Feb-2014 21:34:59 GMT; path=/; httponly
Transfer-Encoding:chunked
X-Controller:CMSPageEditController
X-Frame-Options:SAMEORIGIN
X-Include-CSS:/framework/admin/thirdparty/jquery-notice/jquery.notice.css?m=1381150676,/framework/thirdparty/jquery-ui-themes/smoothness/jquery-ui.css?m=1381150676,/framework/admin/thirdparty/chosen/chosen/chosen.css?m=1381150676,/framework/thirdparty/jstree/themes/apple/style.css?m=1381150676,/framework/css/TreeDropdownField.css?m=1381150676,/framework/admin/css/screen.css?m=1381150676,/framework/css/GridField.css?m=1381150676,/userforms/css/FieldEditor.css?m=1383102217,/cms/css/screen.css?m=1381148892,/framework/css/UploadField.css?m=1381150676
X-Include-JS:/assets/_combinedfiles/lib.js?m=1383514510,/framework/thirdparty/tinymce/tiny_mce_gzip.php?m=1381150676&js=1&plugins=contextmenu%2Ctable%2Cemotions%2Cpaste%2Cspellchecker%2Cmedia%2Cfullscreen%2Cinlinepopups&themes=advanced&languages=en&diskcache=true&src=false,/assets/_combinedfiles/leftandmain.js?m=1383514511,/userforms/javascript/UserForm.js?m=1383102217,/assets/_combinedfiles/cmsmain.js?m=1383514511,/assets/_combinedfiles/uploadfield.js?m=1383514512,/framework/javascript/ToggleCompositeField.js?m=1381150676
X-Powered-By:PHP/5.3.26
X-Title:SilverStripe+-+Edit+Page
tractorcow commented 10 years ago

Can you please send me a headers list for /admin request without the flush parameter included? I'm certain this is what is preventing the issue being discoverable. Try not to flush directly in the admin if possible. :)

tractorcow commented 10 years ago

Hey @colinburns any update on the above? :P What I'm looking for is what you gave me, but without the ?flush parameter in the request. Cheers...

If you notice https://github.com/tractorcow/silverstripe-dynamiccache/blob/3.1/cache-main.php#L20 you'll see that if there is flush present, no caching code is even touched.

colinburns commented 10 years ago

Hi @tractorcow,

Sorry for the delay. I deleted the module but I have run a composer update

Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Updating composer/installers dev-master (4608524 => d792632)
    Checking out d792632d27e1980d921cbbba12eab7b888338d4c

  - Installing tractorcow/silverstripe-dynamiccache (3.1.x-dev b91e943)
    Cloning b91e943acfcd143dc7f3b3571d37aa3b907f1d13

  - Updating silverstripe/userforms dev-master (f66c3c3 => 831983e)
    Checking out 831983e0a861705110632051529dd5e2ea090371

Writing lock file
Generating autoload files

And it seems to have solved the problem. Perhaps it was a version of userforms or something that it didn't particularly like (or something I stupidly did...). But since I have run the composer update it all looks good on my dev machine. I am syncing with the live machine now so unless I report back I think we can assume that this is just one of those vagaries of the web business ;)

Cheers Colin

tractorcow commented 10 years ago

No, it's never a waste of time... if you ever come across a problem, and even if it's your own fault, it would be great if there was something I could update, whether in the code, or even just in the documentation, that can assist in preventing others from struggling.

I'm glad it is working finally. :)