I have the following code :
$repo = $this->get('doctrine.orm.default_entity_manager')
->getRepository('Acme:Foo');
For the record, the code is working correctly since I can use $repo, its methods and the resulting entities without a problem.
However PhpStorm highlights the 'doctrine.orm.default_entity_manager' string and gives me the following error:
Missing service
I get the same error in my services files when referencing that particular service. Following that, obviously, autocomplete does not work. I can use the following workaround, of course:
/** #var \Doctrine\ORM\EntityManager $em */
$em = $this->get('doctrine.orm.default_entity_manager');
$em->getRepository('Acme:Foo');
This way I still get a warning but autocompletion works properly. However, I'd rather keep my code clean from this kind of annotation as much as possible, plus I'm almost sure there's an easy fix for that. I have of course cleared my cache multiple times.
How can I fix this?
EDIT: I need to mention I'm using the Symfony2 plugin.
In PhpStorm i accidentally mark directory "var" as "Excluded"
So my "fix" was easy:
right click on directory, "Mark Directory as" -> "Cancel Exclusion"
Using latest stable PHPStorm and Symfony plugin, I had problem with some services because my var/cache/ was in /dev/shm in my vagrant box (while PHPStorm is running on windows).
When I have all files var/cache it should be working well.
I think that it needs var/cache/dev/appDevDebugProjectContainer.xml to be generated, up to date, and accessible.
We did the following to avoid issues like you're describing:
In our services.yml I have defined:
entity_manager:
alias: doctrine.orm.entity_manager
The problem was that obviously the Symfony 2 plugin doesn't recognize some 'standard' services which are usually available.
And now using
$this->get('entity_manager');
isn't showing any issue with an activated Symfony 2 plugin.
We use a very similar approach for other 'general services' like Logger, Mailer etc.
As said in comments. Check in Settings -> Plugins Search Symfony Plugin
Then Install it.
Related
I just recently upgraded my project from symfony 4 to 6, without much problems. The current online version is using symfony6 without problem.
I am now trying to clean the code, removing some useless parts and other little modifications, and I just met a strange problem. All my pages are now giving me the error:
You cannot use the "renderView" method if the Twig Bundle is not available. Try running "composer require symfony/twig-bundle".
Problem is: the package is present, so the recommended command does nothing.
I tried to check the code triggering the exception:
protected function renderView(string $view, array $parameters = []): string
{
if (!$this->container->has('twig')) {
throw new \LogicException('You cannot use the "renderView" method if the Twig Bundle is not available. Try running "composer require symfony/twig-bundle".');
}
...
}
So I checked the twig service with bin/console debug:container twig, which gives me the same output as with the current working version.
There is a note:
"! [NOTE] The "twig" service or alias has been removed or inlined when the container was compiled."
But this note is also present in my production code without problem.
I brought no real modification to the controller files between the two versions, the main difference being files moved and namespaces adapted to this change.
I don't have any ideas other than doing all these changes all over again, but I fear I'll fall on the same result.
Edit:
The problem look larger that I thought, as I get the same problem with the security bundle.
I tried to inject \Twig\Environment in the controller method, and it autowired with no problems.
I tried to update all the recipes with composer recipes, with no interesting result.
I tried to compare it to a newly created Symfony6 controller with twig, but found no significant differences, except the use of php attributes, which I tried to use in my project, with no result either.
Result of bin/console debug:container HomeController:
Option Value
----------------- -------------------------------
Service ID App\Controller\HomeController
Class App\Controller\HomeController
Tags controller.service_arguments
container.service_subscriber
Calls setContainer
Public yes
Synthetic no
Lazy no
Shared yes
Abstract no
Autowired yes
Autoconfigured yes
Usages none
Edit:
To be honest, if twig is now a private service, not accessible through the container, why is the AbstractController still using this line:
if (!$this->container->has('twig')) {
throw new \LogicException('You cannot use the "renderView" method if the Twig Bundle is not available. Try running "composer require symfony/twig-bundle".');
}
Wouldn't that just cause an error for everyone ? Then why not, and only now for me while it doesn't for my current version (my production is operational with the same Symfony 6 packages)
Edit:
By playing in the vendors, I managed to find that in my original code, the ServiceLocator is used in the AbstractController, but in my bugged one, it seems to be a cached Container class that is used (as $this->container).
So the has() method called in not the same...
How about, I have a problem and it is before in symfony3 was run in the console:
php bin/console doctrine:mapping:import MiBundle yml
and generated and map an entity of the database but in Symfony 4 the command in the console is always the same, but the bundles are no longer occupied in the latest version so the previous command as it is does not work anymore, Someone could help me...
likewise generate the get and set
When using the new Symfony 4 directory structure without bundles the commands for importing the mapping and creating entities from an existing schema in the DoctrineBundle will no longer work properly. There is currently an ongoing discussion whether to update them, but the Doctrine team considers those tools counterproductive. You are not meant to blindly map the schema 1:1 to your domain model.
The best advice I can give for now is to temporarily create a bundle and then move the resulting files. This is also the workaround suggested in the github-issue regarding this: https://github.com/doctrine/DoctrineBundle/issues/729
The Symfony team is moving some of those commands into their own MakeBundle, but I don't think this command is already in there. Maybe you want to follow their progress.
In one Symfony bundle I define a compiler pass to preprocess some configuration. Part of that config is based on Doctrine entities, so I need to get the full metadata information for all application entities.
The compiler pass is executed very late (PassConfig::TYPE_BEFORE_REMOVING). I'm using $container->get('doctrine') like this to get the entity metadata:
$em = $container->get('doctrine')->getManagerForClass($entityClass);
$entityMetadata = $em->getMetadataFactory()->getMetadataFor($entityClass);
However, this is causing random failures for some users because of the use of the doctrine service during the Symfony container compilation.
I'd recommend to change your entities addressing. Mainly - create your models with interfaces and make entities implementing them.
Using resolve_target_entities Doctrine will "convert" them to the particular classes.
An example code is here: https://github.com/Sylius/SyliusResourceBundle/blob/master/DependencyInjection/Compiler/DoctrineTargetEntitiesResolverPass.php
Just make sure your bundle is registered before DoctrineBundle is registered.
Then - in your whole app - instead of AppBundle::Entity addressing, use FQDN of interface bound to an entity earlier.
I've experimented a bit with compilers and services and it's a very bad idea to base on cross-bundle services under compiling container process... Why? It's not reliable - sometimes it will work as you want, sometimes it will fail as you described.
Thank you all for your comments and ideas. I post an answer to explain how I solved this problem.
Trying to use the Doctrine service in a compiler pass was creating more and more problems for our users (and it was creating other minor issues with other services such as Twig). So this was definitely a bad solution for our needs.
So at the end I decided to change everything. We no longer use a compiler pass to process the configuration and instead we use a regular PHP class called during runtime.
In the dev environment, the configuration is processed for each request. It's a bit slower than before, but we prevent any caching issue. In the prod environment we use Doctrine Cache to process the configuration once. Besides, we've create a cache warmer to create the cached configuration before the first request hits the application.
I am trying to use simple things entity audit bundle in my application, but couldnt figure out the way to get this right. Please find the steps i am trying below,
1) Installed simple things bundle into vendor directory via composer file
2) Not sure where to autoload as given in the read me file
3) Added the setting of audited entities in config.yml
simple_things_entity_audit:
audited_entities:
- AcmeDemoBundle\Entity\Vendor
- AcmeDemoBundle\Entity\Employee
But Not sure how to register them as extension in doctrine configuration. I am very new to this bundle. Any help here would be really appreciated.
Use Acme\DemoBundle\Entity\Vendor instead of AcmeDemoBundle\Entity\Vendor
I moved a project to a hosted webspace (at all-inkl, de) which worked well on my local computer. It's possible to access the project at intern.wir-sind-kirche.de and to successfully login. If I click onto a menuitem after logging in this results in a "500 Internal Server Error". It happens during this call:
$entities = $em->getRepository('LFToolsCRMBundle:Mailinglist')->findAll();
which is placed in an action to show all stored data of the named entity in a table.
It looks as if the database is ok as far as I'm able to login.
Both versions of the project, on my local computer and at the webspace as well are completly identical.
Thanks for any help and hints.
Instead of using absolute annotation name, import Doctrine\ORM\Mapping namespace as ORM and then use #ORM\Index:
use Doctrine\ORM\Mapping as ORM
// ...
class MyEntity
{
/**
* #ORM\Index(...)
*/
public $someProperty;
}
Note also that annotations are case-sensitive, so there is no #ORM\index, it is #ORM\Index.
You could have different behavior on various machines because of different php or bundles versions.
It is often a permission problem on the app/cache and/or app/log folders. But when developing you should always use /web/app_dev.php it has great debug tools and will tell you explicitly what the problem is instead of throwing a 500 error. Additionally you should read the documentation available here: http://symfony.com/doc/master/book/index.html