SymfonyCasts/reset-password-bundle

Hello! Tried to install the bundle on a fresh symfony 7 installation and it blocked the make:migration with an error:

jrushlow opened this issue · 9 comments

jrushlow commented

Hello! Tried to install the bundle on a fresh symfony 7 installation and it blocked the make:migration with an error:

[Semantical Error] The class "Doctrine\ORM\Mapping\Column" 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 "Doctrine\ORM\Mapping\Column".                                                                    
  If it is indeed no annotation, then you need to add @IgnoreAnnotation("ORM\Column") to the _class_ doc comment of property App\Entity\ResetPasswordRequest::$selector.

Annotations are not supported anymore in Symfony 7 and even if old annotations were removed from the entity ResetPasswordRequest.php. It's still present in the trait file.

Remove old annotations from ResetPasswordRequestTrait.php in vendor/symfonycasts/reset-password-bundle/src/Model/ResetPasswordRequestTrait.php did the trick to permit the make:migration

Originally posted by @xribant in #274 (comment)

jrushlow commented

@xribant - I'm not able to reproduce this error on a fresh symfony install. Can you provide:

  1. the exact steps used to create the new symfony 7 app
  2. your composer.json - at the very least the require && require-dev sections of the file
  3. the contents of config/packages/doctrine.yaml - specifically the doctrine.orm configuration

I would suspect this is caused by the doctrine config being set to use annotations rather than attributes.

When I do:

  1. symfony new --webapp --docker ./app-test-287
  2. bin/console make:user (Yes to defaults)
  3. bin/console make:reset-password (Yes to defaults)
  4. bin/console make:migration

I'm getting a success message with a generated migration file.

KhorneHoly commented

Hi @jrushlow.

The issue occurs for me with Symfony 6.4 while using the Stof DoctrineExtensions. As soon as I add this to my stof_doctrine_extensions.yaml, the same error occurs.

stof_doctrine_extensions:
    default_locale: en_US
    orm:
        default:
            loggable: true

There is an issue for this error on their project as well, but I'm not certain what causes this error: stof/StofDoctrineExtensionsBundle#470

Edit 1: Seems like the DoctrineExtensions isn't ready to be used with Doctrine 3 yet. As I haven't had issues with the RestPasswordBundle until I've added the DoctrineExtensions, the error message most likely displays an confusing text.

Edit 2: Downgrading doctrine/orm from 3.1.* to 2.19.* fixed this issue. It's a none issue for the RestPasswordBundle, but might be worth a notice for future reference, until DoctrineExtensions are ready for Doctrine 3.

  • 👍1
jrushlow commented

Howdy @KhorneHoly - can you create a gist of your composer.json && composer.lock file for me (when the error occurred)? I'd like to dig into this a bit more, but I don't have much to go on in order to reproduce the error.

featuriz commented

I faced the same now.
To be noted for this bundle developers(and all other bundle developers as well)
I found the solution here: symfony/symfony#48792

Solution:: remove double required annotation + attributes

mbabker commented

I don't know what make:migration does under the hood, but without a full stack trace pointing to what annotation(s) from what file(s) are trying to be read, it's hard to do anything but point to random GitHub repositories or random commits that have nothing to do with this specific error.

For the folks hitting that annotation-related error when having gedmo/doctrine-extensions installed at a minimum (whether that be your application added it explicitly or you're using StofDoctrineExtensionsBundle which integrates that library), the technical reason for it is that when an annotation or attribute reader is not explicitly injected into the extensions library's Doctrine event listeners, it will default to creating a generic Doctrine\Common\Annotations\AnnotationReader instance if the doctrine/annotations library is installed, and only attempts to create an attribute reader if running PHP 8 and the annotations library is not installed. The extensions library knows nothing about whether it's running inside a Symfony 7 application or in some other application integrating one of the Doctrine object managers, so it can't just magically change behaviors because of a framework being present.

For folks getting any kind of [Semantical Error] The class "Doctrine\ORM\Mapping\*" is not annotated with @Annotation. error, this generally means that you are running ORM 3.x (which dropped support for annotations) and something in your application is still parsing annotations. Whether that be through explicit configuration or some kind of fallback behavior (like the one I've described in the extensions library) is hard to say, but that is ultimately the reason for it, and this probably indicates that you're trying to use dependencies at versions that are not compatible with one another.

The symfony/symfony#48792 issue is specific to the Symfony DependencyInjection component and its handling of the older @required annotation alongside the newer #[Required] attribute; the fix for it is not a one-size-fits-all solution for every PHP file that has both annotations and attributes. So shooting off PRs that remove the annotations is just not going to be helpful as doing so will break backward compatibility for downstream users relying on annotation-based configuration.

  • 👍2
  • 👀1
featuriz commented

@mbabker

So shooting off PRs that remove the annotations is just not going to be helpful as doing so will break backward compatibility for downstream users relying on annotation-based configuration.

You are right.