I am using both phpstan and apidoc, but i have an error on phpstan that i can't find a way to solve or ignore.
Error message "Internal error: [Semantical Error] The annotation "#apiDefine" in class App\Controller\UserController was never imported. Did you maybe forget to add a "use" statement for this annotation?
Run PHPStan with --debug option and post the stack trace to:
https://github.com/phpstan/phpstan/issues/new?template=Bug_report.md" cannot be ignored, use excludePaths instead.
To my understanding, apidoc doesn't need any import, but when phpstan goes on my file it does not know this annotation so it triggers an error.
In my opinion the best solutions would be to ignore this kind of error, but it say:
cannot be ignored, use excludePaths instead.
But i would like to keep this file in the phpstan analyse.
How could i fix this error or ignore it ?
I wanted to ignore the annotations from api doc, but it wasn't possible. Instead I can ignore the annotations from doctrine
/**
* #IgnoreAnnotation("apiName")
* #IgnoreAnnotation("apiDefine")
* #IgnoreAnnotation("apiGroup")
* #IgnoreAnnotation("apiParam")
* #IgnoreAnnotation("apiSuccess")
*/
class UserController extends ControllerBase
The only downside that I see is the need to add it for each files.
Related
I'm trying to create a crud in Symfony 4.4 with bin/console make:crud command but I'm getting the following error
In MakeCrud.php line 103:
Call to a member function getRepositoryClass() on null
this is part of the class I'm trying to use for the crud
<?php
namespace Domain\Entity;
use Doctrine\Common\Collections\ArrayCollection;
use Doctrine\Common\Collections\Collection;
class Segment
{
private $id;
private $uidentifier;
private $name;
I type the class name with the namespasce oto genterate crud but I get the error, what could be wrong?
So I got a little bit curious and confirmed that it is a namespace issue.
I made myself a Domain\Entity\Segment class and then ran
bin/console make:crud 'Domain\Entity\Segment'
And got the same error message.
The make:crud command expects entities to live under App\Entity. Does not seem to be any way to convince it to look under Domain\Entity just for entities.
However the Maker Bundle itself allows you to change the name of the App's root namespace:
# config/packages/maker.yaml Need to add this file
maker:
root_namespace: Domain
# Then run
bin/console make:crud Segment
And it works. The problem is that the root namespace is used for generating all the files so, for example, you end up with a Domain\Controller\SegmentController class which is probably not where you want them to be.
I checked the source and there is no easy way to adjust just the entity namespace. If you plan on using crud quite a bit then you either need to copy your entities to App\Entity or specify the root_namespace and then copy/refactor your generated controllers and forms. Either way it will be a pain.
I suppose you could also fork the maker bundle and edit the source code directly. Might actually be worth the effort if you have a bunch of crud to generate. But that will be left as an exercise.
Since Symfony 3.3 the file app/autoload.php disappeared. But I used it to register a custom mapping type as described here.
My current app/autoload.php looks like this:
use Doctrine\Common\Annotations\AnnotationRegistry;
use Composer\Autoload\ClassLoader;
use Doctrine\ODM\MongoDB\Mapping\Driver\AnnotationDriver;
use Doctrine\ODM\MongoDB\Types\Type;
/** #var ClassLoader $loader */
$loader = require __DIR__.'/../vendor/autoload.php';
Type::addType("MyCustomType", "Com\\MyBundle\\Db\\MyCustomTypeClass");
AnnotationRegistry::registerLoader([$loader, 'loadClass']);
AnnotationDriver::registerAnnotationClasses();
return $loader;
As stated here, AnnotationDriver::registerAnnotationClasses();doesn't need to be called any longer with Symfony 3.3. But I don't know, where to put
Type::addType("MyCustomType", "Com\\MyBundle\\Db\\MyCustomTypeClass");
I tried to put it into the boot() method of MyBundle class which extends Bundle. But when I execute my unit tests for the first time after having applied the change, I get InvalidArgumentException: Invalid type specified "MyCustomType".. When I execute them again, I get Doctrine\ODM\MongoDB\Mapping\MappingException: Type MyCustomType already exists..
As referenced on the official documentation: http://symfony.com/doc/current/doctrine/dbal.html#registering-custom-mapping-types
# app/config/config.yml
doctrine:
dbal:
types:
my_custom_type: Com\\MyBundle\\Db\\MyCustomTypeClass
I found a solution for my problem here. Although this solution is for Doctrine-ORM, it also works for Doctrine-ODM (Doctrine/MongoDB).
It uses the same approach that I tried first: to put the Type::addType call into the boot() method of the Bundle class. However, it checks first if the type already exists:
public function boot() {
if(!Type::hasType("MyCustomType")) {
Type::addType("MyCustomType", "Com\\MyBundle\\Db\\MyCustomTypeClass");
}
}
This works, though I'm not sure, if it is the most elegant solution.
Edit:
Though it seemed to work (unit tests are working) it does not run on the server. And it seems to have something to do with the Hydrators.
The first call to bin/console server:run gives an error: Uncaught InvalidArgumentException: Invalid type specified "MyCustomType"
After terminating the server, the restart of the server does work.
But then browsing to any URL that is mapped to a controller gives again an (1/1) InvalidArgumentException Invalid type specified "MyCustomType". (now displayed in the browser).
Reloading the URL does work.
At this point, the app works, but a restart of the server gives again the problem mentioned at 1.
I need to get 2 entity objects from the path parameter in Symfony 3.
From the document, I can do:
/**
* #Route("/blog/{id}/comments/{comment_id}")
* #Entity("comment", expr="repository.find(comment_id)")
*/
public function showAction(Post $post, Comment $comment)
{
}
However, I could not find out where that #Entity comes from. The page return with error:
[Semantical Error] The annotation "#Entity" in method ABCBundle\Controller\ABCController::editAction() was never imported. Did you maybe forget to add a "use" statement for this annotation? in /srv/www/symfony3/src/ABCBundleController (which is being imported from "/srv/www/symfony3/src/ABCBundle/Resources/config/routing.yml").
Does anyone know?
You may want to add this use statement:
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Entity;
See SensioFrameWorkExtraBundle at github
I am implementing Swagger-PHP for an API we've built.
Here is a brief recap:
Language: PHP5.3
Framework: FuelPHP 1.5.3
Environment: Local (served with Nginx)
Now I have an API method defined as follow:
/**
* #SWG\Api(
* path="/site/list",
* description="Get sites list",
* #SWG\Operation(...,
* #SWG\Parameter(...),
* #SWG\ResponseMessage(...),
* #SWG\ResponseMessage(...)
* )
* )
*/
public function action_run()
{
//doing stuff
}
I now try the following (from elsewhere in my application) to generate the JSON:
$swagger = new Swagger\Swagger('my/root/dir');
$swagger->getResource('/site/list', array('output' => 'json'));
And that first line here (when instanciating my Swagger class) is throwing me an error:
ErrorException [ User Warning ]: [Semantical Error] The class
"package" is not annotated with #Annotation. Are you sure this class
can be used as annotation? If so, then you need to add #Annotation to
the class doc comment of "package". If it is indeed no annotation,
then you need to add #IgnoreAnnotation("package") to the class doc
comment of class #Swagger\Annotations\Api.
Adding the #IgnoreAnnotation("package") is actually not helping.
I notice the error disappears if I remove the #package from here:
https://github.com/zircote/swagger-php/blob/master/library/Swagger/Annotations/Api.php#L28
But that's not a solution.
I'm guessing this is mainly Doctrine-related but I can't seem to figure it out.
Thanks for any tips or ideas on that matter.
Because FuelPHP has a Package class (in fuel/core/package.php), which isn’t an #Annotation the DocParser generates this warning.
Swagger-PHP uses the $docParser->setIgnoreNotImportedAnnotations(true) setting, which should prevent warnings like these.
I've reported the issue and fixed the problem but sadly the patch was rejected
Report the issue (again) to doctrine, the more people complain the faster it gets fixed 😉
As a workaround replace your DocParser.php with this version
I am trying to use ExclusionPolicy however I keep getting an "Annotation does not exist, or could not be auto-loaded" error.
Here is the exact error being thrown out:
[Semantical Error] The annotation
"#JMS\SerializerBundle\Annotation\ExclusionPolicy" in class
Acme\DemoBundle\Entity\Attributes does not exist, or could not be
auto-loaded.
My code is as follows:
namespace Acme\DemoBundle\Entity;
use Doctrine\ORM\Mapping as ORM;
use Symfony\Component\Validator\Constraints;
use JMS\SerializerBundle\Annotation\ExclusionPolicy;
use JMS\SerializerBundle\Annotation\Expose;
/**
* Acme\DemoBundle\Entity\Attributes
*
* #ORM\Table()
* #ORM\Entity(repositoryClass="Acme\DemoBundle\Entity\AttributesRepository")
*
* #ExclusionPolicy("all")
*/
class Attributes
{
...
}
your problem is caused by using the wrong namespace.
Instead of:
use JMS\SerializerBundle\Annotation\ExclusionPolicy;
use JMS\SerializerBundle\Annotation\Expose;
It should be:
use JMS\Serializer\Annotation\ExclusionPolicy;
use JMS\Serializer\Annotation\Expose;
Notice "Bundle" is gone. In Ver 0.11 it was extracted to its own repository.
The changelog is as follows:
Namespace Changes
The core library has been extracted to a dedicated repository
schmittjoh/serializer to make it easier re-usable in any kind of PHP
project, not only in Symfony2 projects. This results in several
namespace changes. You can adjust your projects by performing these
replacements (in order):
JMS\SerializerBundle\Serializer -> JMS\Serializer
JMS\SerializerBundle -> JMS\Serializer
JMS\Serializer\DependencyInjection -> JMS\SerializerBundle\DependencyInjection
Dependency Changes
You might need to increase versions of jms/di-extra-bundle, and also
jms/security-extra-bundle depending on your stability settings.
Sometimes it is also necessary to run a composer update twice because
of a bug in composer's solving algorithm.