I have a CakePHP site whose homepage is cached for 10 minutes at a time using Cake's default options. However I've been alerted that "every once in a while", once a day or so, it's losing the layout, just displaying the page content without the header, styling etc.
Removing the cached version and regenerating the page apparently fixes the problem. But why would/could this be happening in the first place? I can't say I've seen it happen myself (in any of my CakePHP projects) but does anyone else have any experience of this, or any ideas of ways to fix? Much appreciated!
EDIT: Looking at a broken cached home.php file compared to a working cache file, I've spotted this line:
$controller->layout = $this->layout = 'ajax'; //broken
$controller->layout = $this->layout = 'default'; //working
This seems like a bit of a breakthrough. I guess that sometimes the page is being called by an Ajax request, and then being cached in that format until the cache expires. Anyone know why this might be happening (I don't think we're trying to call the homepage via Ajax anywhere, and we don't even have an ajax layout!) and if there's anything we can do to stop it?
Are you sure no ajax requests are interfering with your code/request?
We had a nightmare issue recently where cake was not rendering the layout on back/forward browser clicks. See here: CakePHP no layout on back and forward button
It may also help to look into the cake request cycle (http://book.cakephp.org/2.0/en/getting-started/a-typical-cakephp-request.html) and narrow down when in the request (and where) the error is occurring, although I dunno how you would reproduce it :)
Hope you figure it out!
Also, if you have any errors in your view, sometimes it won't load the layout. It will just spit out the view until the point where it experienced the error. Perhaps the error is not in displaying your layout, but some odd circumstance where you are generating an error with a Helper.
Related
I have music application in which I have simple player in footer. User can choose songs from main page list and play it in footer. Now requirement is even if user moves fro home page to other pages(profile, bookmarks) in application the footer player should not get reloaded and should keep playing audio selected on home page initially.
How do I do that? DO I need to load pages through ajax?
Edit:
I forgot to mention that development is 80% completed and footer reloads on every page load. How much of rework is needed if I have to use Ajax now?
Use PJAX. Reload just the parts of the page that you want: https://github.com/rails/pjax_rails
It's already integrated with Rails and everything you put outside of this block will not be reloaded:
<div data-pjax-container>
<!-- PJAX updates will go here -->
</div>
Here's another solution similar to PJAX and Turbolinks
https://github.com/igor-alexandrov/wiselinks
Some very good answers already, but i just wanted to explain your problem better.
HTTP requests is "stateless", which means that each request are fully independent and their is no way you can know anything about how the page was before you requested a new page. This makes it impossible not to reload the footer on each request, using only HTTP.
You can use cookies to keep information between request, so you could start the player where it stopped before the request, but it will still reload (and stop for a short duration).
You can also have the rest of the page in a iframe, and only change the content of the iframe.
However these solutions is not very good for various reasons, so i would strongly recommend the last and best solution: ajax.
The simples solution is properly pjax as #aledalgrande suggested (or wiselink as suggested by #adbeel). This will i practice make your site a "one-site-application" where you use ajax to replace specific parts of the page instead of the whole page. It should however be fairly simple to integrate, even in a existing rails application.
Since you put jQuery as a tag I suggest you either look at http://api.jquery.com/load/.
You can using plain old HTML and making it easier & faster to deploy since the app is almost 'done'. Later you should implement a better (ajax) option.
Simplified: index.html
<iframe id="mainframe" src="other.html"></iframe>
<footer>
Don't reload me pls :D
</footer>
on page navigation (links) you act only on the mainframe, leaving the footer not reloaded.
NOTE: This is ugly and may will give you problems but might serve you to do minimal modification and having your site live asap.
Then rewriting the whole thing to using ajax could be 'some work required' to 'heavy work required' depending on how the app is already implemented. note that will never be 'few or no work required'.
I don't have a lot of hair, but I'm pulling out what little of it is left.
My MVC3 app serves images via Action like so
/Image/ShowImage/25-000252?t=a&o=1
a is predefined image size, o is image order for that item
Image is controller, ShowImage is action which returns FilePathResult. All this works without any problems except when Googlebot comes along. Then all of a sudden request validation kicks in
A potentially dangerous Request.Path value was detected from the client (?).
How and why are both beyond my ability to understand.
ShowImage action has ValidateInput(False), web.config has httpRuntime requestValidationMode="2.0" but nothing seems to help.
Turn on tracing for the app or install elmah or look in the logs for iis to see the path that is returning 500 status code. Then it should be clear what needs to change.
This is resolved by
http://geekswithblogs.net/renso/archive/2011/08/26/a-potentially-dangerous-request-value-was-detected-from-the-client.aspx
I need some help? Anyone experience this problem before with IE8 FLASH bug? Can not get this to work on all subsequent refresh to the flash. I have a flash piece which simply renders only on the first initial load. After that, if i refresh or visit the page, it does not load correctly. It seems I am having this problem with the swf only on subsequent loading of the page or whenever a refresh happens. Can you offer any ideas or services to help?
I have seen, on a number of occasions, issues like this occurring due to logical errors with pre-loaders.
Do you have a pre-loader?
If you do, how is it determining if the movie is loaded? Are you expecting a particular event to fire, which might have fired before you listen for it? Can you test to see if the movie is already loaded, before going into the preloader?
Hopefully you have a preloader... otherwise this answer is useless.
I've search high and low for an answer to this but unfortunately I'm stuck. The problem is only occuring in Firefox (tested IE, Chrome and Safari also - works fine, no errors of any sort). I'll detail the sequence of events to save posting all my code.
ASP.NET MVC 3 application, basic form loads into a jQuery UI dialog
Custom jQuery to hijax the form submit (serialize the form and then $.post to the server - no compiler errors when debugging and post shows up in Firebug without errors)
Http GET (automatically happens) getting the response object from the server (+ success text and XHR), response is plain HTML in this case (again, shows up in Firebug with no errors)
Custom jQuery to change the HTML of the UI dialog from it's current HTML to the response Html - this is where it fails.
I've used javascript alerts to debug the sequence of events and as soon as the post (and get) is complete, everything just... sort of stops.
As I say, only in firefox! Very odd, just wondering if there's any known bugs with ajax and firefox or anybody has heard of a similar situation?
I must also add, that on other parts of my site, this works perfectly in all browsers! The only difference between this form and the other forms that do successfully complete the function is that the response from this form is the same "page" again but updated rather than a new "page". (I use "page" as I got all this working with Javascript turned off first and for graceful degredation)
HELP! Or laugh, either is fine.
UPDATE
I have tried sending a view with a blank model back as the action result - works in every browser except firefox - firefox retains the values from the previous post! And then I got to thinking - that's a trait of firefox isn't it? And maybe that's why the original "re-direct" html response doesn't work?? I think it's time to give up and let people know they can't use Firefox for that particular function!
Ok so I'm answering my own question.
The only way I found to get round it is to use $.ajax instead of $.post and to use the option async : false
Hope this helps somebody.
Rob
Have you tried adding the attribute [OutputCache(Location = System.Web.UI.OutputCacheLocation.None)] to your Action for your GET? It sounds to me like a caching issue.
When I'm using Firebug 1.5, I'm getting 200 ABORTED errors on certain ajax requests. You can see this happen on this demo page by typing into the textfield. The functionality of the site seems to work just fine even with these errors. Is it safe to simply ignore these errors?
This wicket mailing list thread seems to indicate that the wicket ajax code is doing what it should. Also, this firebug issue seems to indicate there may be some concern. Not sure what to think.
I just spent 30 mins with a similar problem. While this is not an answer directly to the above, a google search for my problem got me here, so I thought I'd add it here in case it saves someone else some time. As always, my problem turned out be developer error. I was binding an ajax request to a submit button, but I'd forgotten to use preventDefault() on the button before making the XHR, so the request was being aborted as soon as the default behaviour for the button kicked in - sometimes before the response came back, sometimes not - but it would always report in firebug 1.5 to be aborted.
I am also encountering this. I can see it on your demo site above on every request, but also I see it on one of my sites. I didn't notice this before, and I am sure I would notice it since I stare at the console for hours everyday. Gives some pretty mixed messages.
I am using a mac with firebug 1.5. This bug has been reported on the firebug bug list id=2712 but seems to be going nowhere. It's a tricky one. I tend to notice it when i have 2 simultaneous requests fired off at the same time, and perhaps one preemptively returns before the other. But this shouldn't cause an Abort message.
Sounds like aborts on requests that already were coming back with an OK. Firebug will filter these out on some future release, see the code change here:
http://code.google.com/p/fbug/source/detail?r=6127
I saw your demo page with firebug and seems to be working fine, there is no error to it and note that 200 response denotes that request went successful -> OK, it is not an error abort like you say. Thanks