After some time I always get an internal server error 500 when reloading the page a second time.
Clearing the cache fixes to problem for about 10 hours
Switching the browser lets me again load the page, gives me the error on second reload
Caching is not enabled for the search action.
Only one module is affected, other modules work during the time the site is down.
Any ideas where to look? The symfony error logs are not really helpful the request does not even reach symfony.
This could be related to route caching. Try disabling your route cache in factories.yml and see if this helps.
For Example:
routing:
class: sfPatternRouting
param:
load_configuration: true
suffix: ''
default_module: default
default_action: index
debug: %SF_DEBUG%
logging: %SF_LOGGING_ENABLED%
generate_shortest_url: true
extra_parameters_as_query_string: true
cache: ~
Related
I'd like to set the Symfony 4 profiler to log only exceptions. The application works in dev environment. Having default config everything works as expected - the profiler logs each request (including exceptions).
I found a setting concerning resolving my case: only_exceptions and according to the documentation (https://symfony.com/doc/current/reference/configuration/framework.html#only-exceptions), this should do the trick. But it doesn't, after changing this to true, the profiler logs entirely nothing, even though I deliberately throw an exception.
My config/packages/dev/web_profiler.yaml:
web_profiler:
toolbar: true
intercept_redirects: false
framework:
profiler: { only_exceptions: true }
I've tried this setting for both Symfony versions (3 & 4), in neither of them it seems to work. Is there anybody able to help me? Thanks in advance!
After loading my Twig-Template by Controller and showing it - it takes a while and i get this error displayed: "An error occurred while loading the web debug toolbar (404: Not Found)."
Now i researched about 2 hours and can't find the right solution for me! I found the "thing" causing this issue - its the following route:
showPage:
pattern: /{a}/{b}/{c}
defaults: { _controller: MyBundle:Page:show, a: null, b: null, c: / }
requirements:
b: \d+
c: .+
I changed the order in routing_dev.yml so that routing.yml will be imported before WDT so it can override it - routing_dev.yml looks now like:
_main:
resource: routing.yml
_wdt:
resource: "#WebProfilerBundle/Resources/config/routing/wdt.xml"
prefix: /_wdt
_profiler:
resource: "#WebProfilerBundle/Resources/config/routing/profiler.xml"
prefix: /_profiler
_configurator:
resource: "#SensioDistributionBundle/Resources/config/routing/webconfigurator.xml"
prefix: /_configurator
I use the current Symfony-Version 2.5.0 - the .htaccess file is the default one from Symfony2-Repo - mod_rewrite and mod_alias are enabled!
If i go to a non-existing page and symfony says no route for "bla" found - the toolbar works.
Do you have an Idea how to make an exception for WDT-Routes?
I was wrong with my thought it were a route Problem - the Problem caused in an EventListener which used Doctrine DBAL QueryBuilder and tried to pass the Object to "fetchAll" of DBAL-Connection.
This cause in an Error but Symfony doesn't tell anywhere it only shows my Site and says 404 for Debug-Toolbar.
Open log file app/logs/dev.log and search for CRITICAL keyword, You will found the Fatal Error that not catched by Symfony. Try to fix it.
Late to the party here, but I had the same situation and it was really hard to find the answer. It's exactly what nPoday said here on Jun 9 2014: I had a listener that was throwing an error, though it wasn't Doctrine related. It was an issue with an AWS wrapper, which wasn't even being fired by the application on startup nor the page I was loading that exhibited the issue. Definitely check your listeners, disable them one by one, and you might find the debug toolbar suddenly starts working.
There are many things that may break the toolbar, one of the most common ones is an unfronted error. So make sure you check all your logs before you pull all your hair out.
In my case there was "NOTICE: PHP message: PHP Fatal error: Access level to UserBundle\Entity\User::$id must be protected (as in class FOS\UserBundle\Model\User) or weaker in ..." since my id was private.
After fixing that toolbar has reappeard.
today I got an very odd situation. I am implementing a simple 1:m relation between two entites in Doctrine Symfony2.
There are Users and Groups. Each User should be added to exactly one Group.
But every 3-4 reload my controller spits out an error.
FatalErrorException: Compile Error: Cannot redeclare class Proxies\__CG__\Creativebrains\AthleteBundle\Entity\Group in /var/www/symfony2/app/cache/dev/doctrine/orm/Proxies/__CG__CreativebrainsAthleteBundleEntityGroup.php line 8
And a reload later I get the normal JSON output
{
id: 1,
username: "dominik",
email: "dominik#creativebrains.net",
enabled: true,
displayname: "Dominik",
group: {
name: "asd"
...
}
}
I think it is some sort of caching error but I cannot understand why.
Hopefully some one knows an answer.
Have a nice day!
The problem is related to APC opcode cache. I've been experiencing it just as you described, it seems to happen most with multiple simultaneous requests. Disabling APC solves the problem but it's not ideal. You can disable it just for these generated proxies by adding this to your php.ini file:
apc.filters = '-.*__CG__.*'
This solved the problem for me. It was only ever an issue in the dev environment so it shouldn't be used on production.
First of all, I've been looking around for informations about this but it was all about Symfony 1.x or even more confusing...
Environment
Symfony 2.3
FOSUserBundle + Custom User entity
Problem
In the web site I'm developing I would like user session to end (= have to log in again) either when they close their browser or after 2 hours.
In the Symfony2 documentation they say that the default timeout is set with the parameter "framework.session.cookie_lifetime" of the config.yml, and that its default value is 0 which means that the session expires when the user closes his browser.
Those options are still on default in my configuration file, but when I a open a session and then close the browser, if I reopen it and go to the website I'm still logged in... So that's where I started getting confused... I tried to force the cookie_lifetime value to 0, but it's the same.
The config.yml with the cookie_lifetime option setted :
framework:
translator: {fallback: %locale%}
secret: %secret%
default_locale: "%locale%"
trusted_proxies: ~
session:
cookie_lifetime: 0
fragments: ~
http_method_override: true
Do you have any idea why this behavior ?
Usually browsers don't end a session if you keep the tab open — even if you restart the browser.
How to disable profiler in Symfony2 in production?
I do not mean the toolbar - I mean the profiler.
I want to disable it in production, I use it extensively for development so the solution with removing its bundle is a no-go.
I have tried setting framework.profiler.only_exceptions to true. I have tried removing the framework.profiler section altogether. No matter what the profiler.db is growing after every request and every response contains x-debug-token header.
I have double-checked the config files (config.yml and config_prod.yml) and everything seems to be fined.
What's more the command app/console router:dump-apache --no-debug always dumps the _wdt and _profiler routes, but I don't have them in my routing_prod.yml and they don't seem to be present when trying to access them from the browser (404).
I'm running symfony 2.0 and I won't upgrade right now because of some major changes in 2.1 which would require a rewrite of many elements. It wouldn't be wise to start it just before initial deployment.
Symfony >= 2.2
As of Symfony 2.2 the profiler supports an enabled flag in the framework's configuration and is disabled by default in the test environment.
# app/config/config_test.yml
framework:
profiler:
enabled: false
See this Blog entry about Profiling by Fabien Potencier and the FrameworkBundle configuration reference for more details.
Update: This flag is still valid in Symfony 4.0.
Symfony <= 2.1
In Symfony <= 2.1 The profiler is disabled entirely if there's no framework.profilerkey in the configuration.
You can see this in the ProfilerPass of the Symfony2 FrameworkBundle configuration.
This is the case for the default config.yml and config_prod.yml (which includes the former). So if you didn't tinker with the default configurations you're fine.
In config_dev.yml however the default setting is:
framework:
profiler: { only_exceptions: false }
Which enables profiling for the dev environment and all enviroments that import config_dev.yml like config_test.yml.
If you want to unset the profiler value in a subsequent configuration use:
framework:
profiler: false
Values like {} or ~ won't unset the value. You have to use false.
Did you try this (enable only for development)
As the profiler adds some overhead, you might want to enable it only
under certain circumstances in the production environment. The
only-exceptions settings limits profiling to 500 pages, but what if
you want to get information when the client IP comes from a specific
address, or for a limited portion of the website? You can use a
request matcher:
framework:
profiler:
matcher: { ip: 192.168.0.0/24 }
http://symfony.com/doc/current/book/internals.html#profiler
or
the profiler can be disabled on a per-action basis by doing something like:
if(in_array($this->container->get('kernel')->getEnvironment(), array('prod'))) {
$this->container->get('profiler')->disable();
}
I figured it out, but still I'm not sure why the profiler settings didn't work. I did clear the cache with --no-debug after each change of the configuration.
Firstly I examined the Configuration of FrameworkBundle and found out that profiler conf node has canBeDisabled(). Then I checked what does it mean exactly.
It turns out that each canBeDisabled node has an implied child node enabled with default value set to true. You can either override it or set the parent node directly to false or null to disable the section. If you simply omit the profiler section then it is enabled by default.
Maybe I missed it in the docs, but I'm pretty sure it should be mentioned here. Also, in my opinion profiler should be disabled by default in production. I can't imagine a scenario when it would be beneficial to run profiler in production in the long run. I'll be happy if anybody proves me wrong.
BTW I noticed then as the profiler.db grows then each request becomes slower, but that may not be the case in prod.