I have problem, after insert or update in my screen i see message:
Warning:
rename(C:\Users\Name\Desktop\BaseApp\var\cache\dev/doctrine/orm/Proxies__CG__AppBundleEntityCategory.php.57483ae07bdb29.50220410,C:\Users\Name\Desktop\BaseApp\var\cache\dev/doctrine/orm/Proxies__CG__AppBundleEntityCategory.php):
All time after update i see this message, after reload page all is right,
i use my app on windows, dev mode, symfony3,
Regards!
The problem is that the Doctrine's proxy class generation code doesn't handle concurrent requests very well. It works on Unix-like systems, but not on Windows, where you can't just rename over a file that is open.
See configuration of the doctrine bundle. You'll most like have auto_generate_proxy_classes set to "%kernel.debug%" (this is the default setting in symfony standard edition).
Try changing auto_generate_proxy_classes to false. You'll now have to manually clear the cache if you change your entities, but that error should be gone.
Related
I have an application based on Symfony 2.8. A feature is working well in my local dev environment but failing in production. I want to make my local environment use prod mode in order to hopefully replicate the problem. What I have tried:
export SYMFONY_ENV=prod
app/console cache:clear --no-warmup
This appeared at first to be working, as I got a message about the cache being cleared in the prod environment, but when I loaded the app, the debug toolbar was visible and said I was in dev mode.
I have also tried looking in both parameters.yml and config.yml for any denotation of the environment. I didn't find anything.
What should I try next?
The answer can depend on a lot of factors: what web-server is used, what web-server config is used, do you use php-fpm or else, etc.
Console commands like "export SYMFONY_ENV=prod" set environment only for console commands in the same session. But they can't affect your web server behavior.
When you open a page of your project in a browser, the application doesn't know anything about commands what you have typed in a terminal. If you see a debug console probably the app entry point is "web/app_dev.php", and the environment is defined here like:
// web/app_dev.php
$kernel = new AppKernel('dev', true);
Try to change 'dev' by 'prod'
Well, in symfony2 dev mode is being accessed through file web/app_dev.php, prod - web/app.php.
So if you are using your own local web-server (apache or nginx), in order to see the app in prod mode, you may want to provide your web-server the default symfony configuration, e.g. as described here : https://symfony.com/doc/2.8/setup/web_server_configuration.html#nginx
In case you are using symfony built-in web-server, you may want to use the solution ox160d05d provided. I would recommend using own local web-server though.
Yesterday my Web Profiler stopped working, in Symfony v.3.0.9 (on Win, with WAMP, PHP v7.0.4). Before that it worked just fine and I'm not sure exactly what happened when it stopped.
I first checked the JS errors being reported, then possible errors in dev.log, then tried clearing the cache (with cache:clear), also as an admin and also manually in file system. Nothing helped.
There are no errors returned anywhere and there are no tries from client side to even call it with AJAX. I tried restarting Apache, Wamp & Windows.
Then, I tried composer update, which naturally brought up some new, unrelated issues, and eventually I ended up installing Symfony 3.1, but still no sign of Profiler.
My HTML page does have a body, so the solution here: Web Profiler not showing up in dev doesn't help me. All other mentions of this problem usually lead to some compiling issue, which I don't have (or didn't find it yet).
I also made sure I am running in dev mode, by putting breakpoints in app_dev.php directly.
Has anyone any other/new idea what could be going on?
Addition: I also tried updating Symfony to 3.2, without Profiler appearing.
Addition #2: Just wanted to share, that the only way I can get my Web Profiler to show is, after the cache is rebuilt, go into the var/cache/dev/appDevDebugProjectContainer.php, into the getProfilerService() function and manually comment out the line with:
$instance->disable();
Ugly as hell, but I haven't find any other solution until now. At least, now I see that somehow Symfony decides, based on some internal logic, to actually not show the profiler. At least there is some logic at works.
The final answer to my "mysterious" issue was that someone in the team changed the profiler's setting in the config_dev.yml, and set the:
framework:
profiler:
collect: false
Getting that back to collect:true (which is also its default value) made it all work.
I am getting the infamous Doctrine "PHP Rename Access Denied Code 5" error in my Symfony2 project when logging in using the User entity:
\\app\\cache\\dev/doctrine/orm/Proxies\\__CG__AcmeDemoBundleEntityUser.php): Access is denied. (code: 5)
I will log in OK, and if I am lucky, I can load a page before the session is killed as a result of the user authentication failing as a result of this error. It only happens with this one entity.
My colleague, with the same set up and same project has the same error but for a different entity (and ONLY that entity).
This problem has been reported on here before, with a link to the bug on Doctrine's GitHub which was confirmed fixed as of 2.5 (confirmed in Doctrine ORM 2.5 Release Notes).
My Symfony2 project is running with Doctrine ORM 2.5.4 yet I am still getting the same error.
Attempted Fixes
Reinstall XAMPP;
Deleted project & pulled project from git;
Updated vendor projects (maybe an old Doctrine ORM package remained);
Closing PHPStorm (maybe it's locking the files for indexing);
Disabled Windows indexing (same reason as above).
Changing the value of auto_generate_proxy_classes from %kernel.debug% to false in config_dev.yml prevents the problem, but this hides the issue instead of fixing it.
Has anyone managed to actually fix this?
Have you tried to set up auto_generate_proxy_classes to a underlying constant value for AbstractProxyFactory::AUTOGENERATE_EVAL or AbstractProxyFactory::AUTOGENERATE_FILE_NOT_EXISTS.
According to this documentation section Advanced Configuration > Auto-generating Proxy Classes this should fix the access denied problem in development environment.
Also, you should make sure your production configuration follows this recommendation:
In a production environment, it is highly recommended to use AUTOGENERATE_NEVER to allow for optimal performances. The other options are interesting in development environment.
I have a website in Symfony linked to a a MySQL database. The website is having some troubles, so I have to update the information in the database. The thing is, when I update on the database, it stays updated there but on the website it doesn't show any changes.
For example, a user is registered. I go to the database to change the email so I can register another account with the same email. The database is updated with the new email, but on the website it says that the old email is still in use.
I know that I am updating the right database, because when I register a new client on the website, it appears on the database. Any ideas on to why this might be happening?
Like Angel Iliikov mentions in the comments, it's very likely a caching issue. The following suggestions assumes you have access to the command line - which a typical Symfony user should. If you don't already have it, most hosting providers allow you to get SSH access.
Clear the following caches:
1. Symfony's cache
Symfony will store a lot of data in the cache files to prevent it from having to process requests from scratch. When Symfony apps go wonky, a very common fix is to clear this cache and retry. The standard way to clear this cache is with a console command run at your project's root directory:
$ app/console cache:clear
If you run into issues, David Soussan answer provides more information on this one.
2. Doctrine's cache
According to commenters on another question (formatted by me):
The doctrine cache is often stored in apc rather than in the file
system so removing the cache files would not help. The general app/console cache:clear is only for the symfony (app) cache. I don't think it clears the doctrine cache(s).
-caponica
Alternative PHP Cache (APC) is an optional component enabled in php.ini. It's possible Doctrine is caching information there as well if it happens to be enabled.
The accepted answer on the previously mentioned question provides an answer for clearing Doctrine's cache:
$ app/console doctrine:cache:clear-metadata
$ app/console doctrine:cache:clear-query
$ app/console doctrine:cache:clear-result
-amitchhajer
3. Your browser's cache
This is very unlikely to be causing any issues. But if you are doing something to send caching headers over HTTP - it's possible that the application would have properly updated the data, but your browser is displaying an old page.
Each browser has a different way of clearing cache. Google provides support for how to do it Chrome. and Mozilla provides support for how do it in Firefox.
If clearing the cache doesn't solve your problem, it's likely a problem with your application or workflow and will need debugging. A few things you can try:
Make sure you really updated the correct database. Confirm this
on two separate DB clients.
Create your own Symfony
command
where the only thing you do is query the database. If it returns the correct result, you should check that other components are using the same query. If not, check your config/parameters to ensure you're using the right database.
If your Symfony application is not showing the updated database record that is because it is using the cache which still contains the old data. This is often a problem with Symfony, refreshing the page just reloads from the cache. Try clearing the cache first. Now, very often cache:clear does not work from the command line, I've had it happen all the time and never really understood why. The answer is to just delete all the cache files, as per Fabien Potencier's tip: http://fabien.potencier.org/a-symfony-tip-clear-the-cache-without-the-command-line.html. That works and is my go-to solution for when eg; composer update did not clear the cache afterwards. In fact I got into the habit of just deleting the cache files on my dev machine before doing composer install or update.
Adam,
Use these commands to clear your cache:
# dev environment
$ app/console cache:clear
# production environment
$ app/console cache:clear --env=prod
I had problems using the mysql database supplied by my host server at first but then I installed the latest mysql database version available in softaculus inside my host server and then I was able to access mysql inside softaculus or directly by the url (www.mypage.com/mysql). Finally it works perfectly. You can try to do something similar.
Context : I have been asked today to add a new feature on a quite old project (something like Symfony 2.0). It consisted in adding a new attribute to an entity and add the corresponding field to the edition form. Child play : I have edited the code and it works well in dev environment (set directly in app.php)
Problem : When the environment set in app.php is prod, the entity is not persisted when the form is submitted, nor retrieved when the form is loaded.
Investigations : What I have checked so far in prod env :
The submitted form is correct
The controller manages to map the form and to hydrate the entity correctly
I have deleted the cache multiple times both manually and from command line
I have checked the SQL query after the form has been submitted, the query does not update my new field as expected
Supposition : The problem seems to apppear when the entity is flushed, it is like the new field was completely ignored.
Assumption : After having exposed my problem to more experienced symfony developers, the only suggestion was that there may be a PHP cache (not the symfony one) somewhere parasitizing my prodenv. This assumption is being tested (I could not restart apache myself) and I will be able to test it maybe tomorrow in the best scenario.
Still, I feel like the PHP cache assumption has 10% chance to be the good one. I can not share with you the whole project code, but I am asking you if you could post every idea you might have regarding this issue.
UPDATE : I have restarted Apache2. Problem is still persisting. It seems like Doctrine builds its cache on a former version of the project (It does not see any changes in the annotations for example) even though app/cache/ is empty. Any idea ?
I have deleted the cache multiple times both manually and from command
line
Can you clarify? Symfony's cache is not the same as doctrine's. Depending on your configuration doctrine could be using something like apc, reddis or something else to cache its own queries and result data. If you haven't yet, try to perform these commands:
app/console doctrine:cache:clear-metadata
app/console doctrine:cache:clear-query
app/console doctrine:cache:clear-result
If you're still out of luck, I'm more than 10% sure that an apache restart will do the trick.
If this worked, you should check your prods config yml and see if you find something like:
metadata_cache_driver : something
result_cache_driver : something
query_cache_driver : something
Full answer was to execute :
app/console doctrine:cache:clear-metadata --env=prod
The caching was caused by a memcache configuration only present in production environment.