I just got the firebug update 1.4.2 but now my console log doesn't clear itself between refreshes...
Anyone have any idea if this is a feature or a bug, and how to fix it?
Turned out something gone wrong with updating to the new firebug.
Besides rebooting my computer a few times extra, I haven't done anything to fix it. Somehow it's fixed though :)
Thanks.
Related
I'm not sure where it comes this bug but now if I try to load my project in the browser with this url "http://localhost:8000" appears just a blank page. I tried to put a die("message") in the first line of app.php and also in the app_dev.php but nothing happens. It's like is not loading these files.
If I use http://localhost:8000/app.php or http://localhost:8000/app_dev.php it works very well and shows what's suppose to show.
I'm wondering why is this happening now. I'm not sure how to fix this problem. I updated recently from 3.3 to 3.4 but not sure if this is affecting.
Anyone could help me?
https://github.com/symfony/symfony/issues/25515
The problem was updating to 3.4. We will have to wait to a more stable version.
I have this weird issue with Symfony 2, right after installation on my VPS. The welcome page is loaded properly except... that some images and some styles are loaded, but not rendered. Can You please help me with solving this mistery?
Hints:
* During the installation, I had a problem with 'data-time zone' - I don't know is that has anything to do with it but... may be it'll be a clue...
Thanx in advance for any advice!
UPDATE:
Things that are not loading properly throws the following messages under the console
Apparently it appeared that it's truly the Apache's installation fault.
This has been extremely frustrating. I installed a module Finder in Drupal installation. I was tweaking some settings in it and then after changing some settings it started showing off some Ajax errors and then there was the White Screen, showing this error:
Fatal error: Call to undefined function views_include() in /var/www/drupal/sites/all/modules/views/includes/plugins.inc on line 9
Using Drush, I disabled the Finder module and cleared the cache. But nothing happened. Then I disabled the Views module. The White Screen was now gone.
And now I am stuck. I had some pretty good work done in this site and when I re-enable the Views, White Screen reappears. It seems to me like the Finder module made some irreversible changes somewhere in Views. I mean how come my Views is not working when I've cleared the cache and Finder is disabled?
Has anybody ever come across such a thing in Drupal? How did you solve it?
UPDATE
I just found that the developer of the "Finder" module is claiming it to be a bug in Views. See here: http://drupal.org/node/1611106. As suggested, commenting out that particular line 9 in plugins.inc of Views module does work. However, I'm still skeptical to accept to be a bug in Views.
It's not Finder; it's either Drush botching an update or perhaps you relocating the module, causing the registry to become out-of-date. Check that views.module actually exists, Views is enabled in the system table and then rebuild the registry as nmc suggested.
That should fix it but, at worst, you can comment out the views_include('base'); call at the top of plugins.inc as a quick hack to recover your site.
I just got this error too. Funny enough it was also while playing around with settings in the finder module. Playing with the ajax settings to be precise.
Anyway, to get your site back when you get the error and white screen, close your browser and reopen it a a page other than your site and clear all the browser cache. You should then be able to see your site again.
It happen to me after setting 'Ajax' to 'yes' under the form heading on the edit finder page.
After you have reopened your browser and cleared the browser cache, go straight to the edit page for the finder that is the culprit and set 'ajax' to 'no'.
Perhaps the Registry Rebuild module may help you.
When would you need Registry Rebuild?
You might get something like:
PHP Fatal error: Class 'EntityAPIControllerExportable' not found in
...sites/all/modules/rules/includes/rules.core.inc on line 11
If this happens when you're trying to run update.php, and happens when
you're trying to clear your cache, well, you have some trouble. That's
what Registry Rebuild is for.
I've never used it myself so I recommend that you look into the code before running it but I hope it helps you.
See
http://randyfay.com/node/105 and
http://drupal.org/project/registry_rebuild
For me, rebuilding the registry with drush rr didn't work. Disabling the module, uninstalling ad reinstalling didn't help also. The only thing which worked was to clear the sessions table.
This issue has been happening for a while, and it's suspected to be session related since it pertains to the users browser. Opening a new browser (session) rids the issue. The application uses Global.asa (Only Application_OnStart and Sub Session_OnEnd, the rest are empty), Classic ASP (VbScript), IIS 7.0.
This error keeps popping up on url's which happen to be loading fine, until the page is refreshed for the second time, then it bogs out and even times out. In the same browser, if i even try to open that entire website, it times out at this point. For about 350000ms and then everything starts working again. Very weird!
If anyone can help with this, I haven't had any luck anywhere finding what may be causing this, besides something that has to do with the sessions, maybe in the application pool.. I'm not sure.. Any help on this would be appreciated.
Sometimes Google AdSense might cause such problems, disabling it should solve your issues.
To cure the real "root" of the problem and keep using AdSense, guess you'll have to contact Google.
I have a SharePoint site that I have added a few extra pages to in order to handle some custom AJAX requests.
Every now and then, about once a week, I get a call saying it's not working. When I look into it, the error I'm receiving is:
Could not load type 'My_Controls.Control_Name' .
Where My_Controls.Control_Name is the name of the page. An IIS restart solves the issue and gets it running again, but this is obviously of great concern to the client.
I have tried everything I could think of. In the past when I encountered this, setting compilation batch="false" usually did the trick, but this time it isn't resolving the problem.
Obviously this is a pain to troubleshoot because there isn't a way to reproduce the bug (it just pops up from time to time) and a simple IIS restart solves it.
Does anyone know what may be causing this or ideas to try and fix it?
Thanks