From the /posts/edit-view I'm submitting a form to the action addCategory in my Post controller.
The action does all the work it has to do, and subsequently calls $this->redirect($this->referer());.
At first sight my app works fine, but I encountered some hickups when moving to a production server. Monitoring the calls in Firebug I see that the action acually returns a 302 Found but the 'Response' is Failed to load source for: http://localhost/xps/posts/addCategory.
This happens on both dev en production servers, only on the production server it makes the redirect flow fail. On both servers the controller actions are executed well: category is added.
Removing all the code in the action results in the same failure. Removing the redirect removes the failure, but that's not getting me anywhere.
A second (though maybe irrelevant) irregularity is that the submit method of the form is identified as PUT in Firebug although I explicitly set it to POST in Cake.
I recently switched from CakePHP 1.3.4 to 1.3.6, but reversing does not change the behavior
I use the RequestHandler, Session and Auth components and call parent::beforeFilter() in beforeFilter().
I also found the following thread http://cakephp.1045679.n5.nabble.com/puzzle-over-activity-td1260972.html It suggests to remove $this->Auth->authorize = 'controller'; but I don't have that stated anywhere anyway.
Does anyone have an idea where to look next?
Just a guess, but if you are using Security component, it might cause problems. Also, sometimes when using the ajax and sessions it can cause problems. Maybe if the page requires sessions, you could try it without sessions and see if it works.
Ok, I found it.
The Failed to load source is still there but is not the cause of failure.
In one of my Behaviors I had a space after ?> which messed up the headers, which made me look into the wrong detail.
Related
"$digest already in progress" when manually changing URL
I have a hybrid AngularJs/Angular app. If I'm on a page, say localhost/home, and I manually edit the URL to localhost/otherPage and hit enter, the browser navigates to the other page, but I get this error:
The error does not occur if:
I navigate to the same page using in-app links
I open a new tab to navigate directly to localhost/otherPage
The stacktrace doesn't show any of my code, so I'm not sure how to debug this. Also, I don't know what difference it makes to the router whether you're "editing" the URL to navigate from home to otherPage as opposed to directly resolving the otherPage URL in a new tab.
Thanks for any help!
From the Docs:
Diagnosing This Error
When you get this error it can be rather daunting to diagnose the cause of the issue. The best course of action is to investigate the stack trace from the error. You need to look for places where $apply or $digest have been called and find the context in which this occurred.
There should be two calls:
The first call is the good $apply/$digest and would normally be triggered by some event near the top of the call stack.
The second call is the bad $apply/$digest and this is the one to investigate.
Once you have identified this call you work your way up the stack to see what the problem is.
If the second call was made in your application code then you should look at why this code has been called from within an $apply/$digest. It may be a simple oversight or maybe it fits with the sync/async scenario described earlier.
If the second call was made inside an AngularJS directive then it is likely that it matches the second programmatic event trigger scenario described earlier. In this case you may need to look further up the tree to what triggered the event in the first place.
For more information, see
AngularJS Error Reference - $rootScope:inprog - Diagnosing This Error
We're having strange, sporadic JavaScript error messages in our production log files (JavaScript errors are logged in the backend):
Uncaught Error: [$compile:tpload] http://errors.angularjs.org/1.2.16/$compile/tpload?p0=modules%2Fsome%2valid-directive-path.tpl.html
The error occurs only with directives. I'm not able to reproduce the errors locally. The templateUrl for the directives are all valid.
The only possible scenario that came to my mind was if the user presses the cancel/stop button in the browser while the page is loading (then i'm able to reproduce the error).
Does anyone have another idea or explanation? Or even a solution :-)
Cheers
Michael
We resolved the issue like this:
Since we are caching our HTML templates with $templateCache using the grunt ngTemplate plugin (https://www.npmjs.com/package/grunt-angular-templates) we do not have the above issues anymore.
Out of interest I was able to recreate this issue. By adding logging to angular I established that when the template load fails it does so with a status of 0 which made me think that the request was actually cancelled. This theory was backed up by the fact that we see no server side errors.
If I emulate a device that cannot support html5 routing and then add an arbitrary query string to the end of the route, it causes an infinite digest loop and in the end the whole page reloads a few times. This in turn was causing the outstanding template requests to be cancelled leading to exactly the errors I was seeing in the logs.
So, for me at least, this is really nothing to do with the loading of the templates, it's just an angular bug (which hopefully is going to be fixed in angular 1.3.8)
Two questions:
Is there a way in CodeIgniter to check if a library had been loaded? If the session library is loaded, I want to show a user-specific page.
If my database is offline and CodeIgniter is unable to connect, how can I display a custom message to users rather than the default error page?
Don't know if this is best (or even good) practice but I found using something like
if(isset($CI->session)):
//show user specific page
endif;
works for me so far, eg. the last 5 mins since I tried it =). In my case I didn't want the debug message:
Session class already loaded. Second attempt ignored.
polluting my logs, so I used:
if(!isset($CI->session)):
$CI->load->library('session');
endif;
hth..
Found this on Codeigniter
forum:
"If you look in the Loader
library, in the function
_ci_load_class, you’ll see that it checks if that class has already
been loaded, and will only load it
again if its being assigned to a new
variable.
Interestingly enough, if you load
the same class multiple times, the
memory usage does go up though"
So if you call $this->load->library(LIB_NAME) more than once, it will only actually load it once. This is from 2009 and CI has been
updated many times since then so not
sure if it's still true.
I hope your db never goes down. But
if it does $CI->db->conn_id
returns true if it can connect.
Symptom: I'm running a Google Website Optimizer A-B test on a web page, which is reached after the user fills out a form. The form data appears to arrive successfully when GWO does not fire a redirect (when the default page is reached after submitting the web form). The data does not appear to arrive, however, when the alternate page is reached (i.e. when GWO redirects the user).
Details: I wouldn't attribute this to GWO, except that in my development environment, where I was obliged to comment out the GWO javascript, everything works as it should do. (The GWO code had to be omitted, of course, to prevent my browser redirecting me to the production environment, i.e. the live version of my site.) (Naturally, without the GWO code in place, I had to hard code a change to my form's action attribute in order to verify that my query data was handled successfully by the alternate destination page.)
Really, it looks as though GWO is just failing to pass on the requisite query parameters when it performs its redirect, but that seems unlikely. Can you give me any advice?
Fixed (rather): I changed the form to pass GET (not POST) data, and indeed, GWO was able to collect that query data and pass it on to the new URL. (I find that surprising, since the url is stipulated, and I should have thought it easier to accept and pass on POST data.)
The simple thing of calling FB.init (right before </body>) and then FB.getLoginStatus(callback) doesn't fire the callback function.
After some debugging, I think the SDK is stuck in the "loading" (i.e. FB.Auth._loadState == 'loading') phase and never gets to "loaded", so all callbacks are queued until the SDK has loaded.
If I force-fire the "loaded" event during debugging - with FB.Event.fire('FB.loginStatus', 'loaded') in case you're intersted - then the callbacks are invoked correctly.
Extra details that might be relevant:
My app is a facebook iframe app (loaded via apps.facebook.com/myapp)
I'm using IE9. The same behavior happens in Chrome
The app is hosted in http://localhost
What's going on? Why is the SDK never gets to loaded?
Thanks
UPDATE: Just tried it on Chrome and it worked (not sure why it didn't work before). Still doesn't work in IE
I had this same problem in Firefox 3.5 on Windows, but only on the very first log in to the page (probably because it was a slower machine and there was some weird timing issues going on).
I fixed it by forcing FB to refresh the login status cookie every time it checks:
FB.getLoginStatus(callback, true); //second argument forces a refresh from Facebook's server.
Without "force=true", sometimes it wouldn't fire the callback.
I had the exact same problem, and I solved it disabling "Secure Browsing" in the Facebook Security settings. Keeping Secure Browsing on forces the pages as "https", but I had no "Secure Canvas URL" set up, and this gave me a lot of errors in the console as well.
Hope this may help someone :)
In my experience, getLoginStatus() never calls the callback in Firefox when third-party cookies are disabled.
The original poster mentioned his application is hosted on http://localhost. I've never had luck with that, and believe it will cause problems.
Just today, I've had problems where getLoginStatus is not calling the callback on any browser, unless the user is actually connected to the app! I'm hoping this is a bug on facebook's end that they will solve.
Yet another possibility for FB.getLoginStatus not firing its callback is when using a "test" user account that has not been authorized to view that application. Its pretty bad that facebook doesn't give you any error messages.
I have also seen failed callbacks on bad appIds and redirectUrls.
I also ran into this issue specifically in Chrome. I tried calling it on page load and after a user-initiated action with no success.
It turned out that it was not a cross-domain issue. The getLoginStatus() call was being blocked by the Un-Passwordise extension in Chrome. As soon as I disabled the extension, it worked perfectly, even on page load.
More info about this issue here: Chrome-only cross-domain scripting errs in Facebook iFrame App upon FB.Login(..)
I understand that this question is a little old now, but I ran across it searching for solutions.
Double-check what you have set in your Facebook app configuration under the section "Website with Facebook Login". The Site URL domain must match the domain your page with the FB.getLoginStatus (and other related auth Javascript) is served from.
After hours of struggling, I realized that I could not reuse an existing app configuration I had on a new server and had to create a new app to handle the website login for this new server.
The other answers are probably equally valid in your specific case, but since there may be others like me who have struggled for a while on this, hopefully this gives you one other place to check. Making a new app with the correct Site URL was the answer in my particular case.