I have one project which wasn't developed by me. And it has strange behaviour. I added new field to entity, generated setters/getters for this field as usual. After that I updated database schema through doctrine:schema:update, but now I see very strange behaviour - symfony throws error Call to undefined method %my method name%. I checked again, this method really exists.
After that I cleared a cache through rm -rf app/cache/*. The first page loading all works fine. But at second loading I got this error again. So, when I tried to clear cache again, this situation is repeated. When I tried to use get_class_methods($myEntity), it shows new methods after first page loading, but after second - not.
I tried to use commands like doctrine:cache:clear-*, but they are useless.
Anyone can help me with this problem?
Finally problem was solved when I restarted php-fpm. Such a mistery.
Related
I'm using Symfony 4.4.10 and I do have problem with correct error 4xx/5xx handling to get users to my custom html.
On production, when 500 error occurs, I'm getting this kind of screen:
Which is weird, because I followed this tutorial: https://symfony.com/doc/current/controller/error_pages.html
I have my templates overridden (like here), but still above screen occurs. (adding error500.html.twig file isn't changing anything)
When I'm debuging on dev it's ok, I mean, with this custom "_error" route.
What can be the problem here?
404 errors and sometimes work, sometimes not.
Regarding the documentation and your shared code, you are right.
Have you got clear cache dev and production environment ?
php bin/console cache:clear
I had some custom error handling code in Application_Error, which was doing some logging and then handing off to my Error controller action/view. I had a bizarre issue where sometimes - and only on my production server, not on my development machine - the error page would appear, but no error details were recorded in the log.
I spent several hours trying to figure this out, and it turns out that my error page was being invoked directly, without going through Application_Error!
I saw a throwaway comment on another SO post that implied that this might happen with the HandleError attribute - i.e. that it would look for a view called Error, and simply render that, bypassing Application_Error.
I was using Elmah.MVC, and so did not explicitly use the HandleError attribute, because Elmah does this for you. However, it turns out that Elmah also does the straight-to-error-view thing too, because when I renamed my view (and controller action) to something else, everything started working as expected.
Just posting this in case it helps someone else...
I've configured SonataMediaBundle, added relation to Media in my Entity. Admin for entity works fine until I add this snippet from docs:
twig:
form:
resources:
# other files
- 'SonataMediaBundle:Form:media_widgets.html.twig'
After that all I get is this error:
FatalErrorException: Compile Error: Cannot inherit previously-inherited or override constant MARKER from interface Doctrine\Common\Persistence\Proxy
What I'm doing wrong? How to make sonata_media_type work with its widget template?
googling for somedays for a similar error I came up with the conclusion that is has nothing to do with your code, but is some kind of strange bug in environment, more likely in APC.
Check this post if you are using amazon server: https://forums.aws.amazon.com/message.jspa?messageID=508800
After I did that upgrade the problem solved. I'm still waiting to see if it comes out again, because it was not a permanet error, and after each apache reload/restart it went away for a while...
Other op-caches may solve the problem without loosing performance.
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.
There are a couple of other questions on here regarding this but they are old and have not been answered satisfactorily IMHO.
I am getting this error - "Unknown record property / related component
"permissions" on "sfGuardUser", referer:" - in my error_log when I
attempt to login to my symfony 1.4 app after deployment. I do not get
it on my local machine.
When I submit the login form, Symfony throws a 500 error. If I refresh
the page, the login form is reposted and I am logged in.
Can anyone suggest what might be causing this?
The answer can be found here: http://oldforum.symfony-project.org/index.php/m/102097/
The solution is:
rm ./lib/model/doctrine/base/BaseSfGuard*
./symfony cc
from http://oldforum.symfony-project.org/index.php/m/102097/
It seems that at some point I had this relation defined in my own schema file and this had been cached somewhere. When I moved the code to a new server without the cache, Symfony generated classes in a location which overrode the plugin's versions.
When I submit the login form, Symfony
throws a 500 error. If I refresh the
page, the login form is reposted and I
am logged in.
What browser do you use? I have same problem,but only in Opera...
I don't like using build all commands. If an SQL statement fails, building all can delete data. Never user build all commands on a production environment for Symfony.