2016-06-14 6 views
0

Unser Projekt wurde von Symfony 2.1 auf 2.3 und jetzt auf 2.7 migriert. FOSUserBundle hat seine eigenen Eigenschaften auf 2.1 erstellt, aber nicht auf den späteren Editionen.Extended FOSUserBundle Keine Basiseinheiten erstellen

php app/console doctrine: schema: update führt tatsächlich zu befehlen, den vorhandenen username, usernameCanonical, etc., Felder zu löschen.

Darüber hinaus, wenn Sie sich mit unserem Protokoll in Form einzuloggen versucht, erhalten wir:

"exception":"[object] (Symfony\\Component\\Security\\Core\\Exception\\AuthenticationServiceException(code: 0): Unrecognized field: usernameCanonical at .../vendor/symfony/symfony/src/Symfony/Component/Security/Core/Authentication/Provider/DaoAuthenticationProvider.php:94 

Es scheint das System keine Kenntnis von den FOSUserBundle Einheiten hat, die unsere erweiterten Basis Benutzer begleiten.

Ich habe unsere erweiterte Benutzerklasse auf den Standard als Test reduziert und immer noch die gleichen Probleme. Hier ist der aktuelle Code und Konfiguration:

config.yml

orm: 
     #default_entity_manager: ~ 
     auto_generate_proxy_classes: %kernel.debug% 
     auto_mapping: true 
     result_cache_driver: 
      type: memcached 
      host: 127.0.0.1 
      port: 11211 
      instance_class: Memcached 
     metadata_cache_driver: 
      type: memcached 
      host: 127.0.0.1 
      port: 11211 
      instance_class: Memcached 
     query_cache_driver: 
      type: memcached 
      host: 127.0.0.1 
      port: 11211 
      instance_class: Memcached 
     filters: 
      softdeleteable: 
       class: Gedmo\SoftDeleteable\Filter\SoftDeleteableFilter 
       enabled: true 

     mappings: 
      FOSUserBundle: ~ 

fos_user: 
    db_driver: orm 
    firewall_name: main 
    user_class: ODR\OpenRepository\UserBundle\Entity\User 
    change_password: 
     form: 
      type: odr_user_change_password 

security.yml

firewalls: 
    main: 
     pattern: ^/ 
     form_login: 
      provider: fos_userbundle 
      # Symfony >= 2.8 
      # csrf_token_generator: security.csrf.token_manager 
      # Symfony < 2.8 
      csrf_provider: form.csrf_provider 
     remember_me: 
      key:  asdlkjf2ji802fiuaskdjokjhafsdjsfdjhjh 
      lifetime: 1209600 
      path: /
      domain: ~ 

Benutzerklasse [src/ODR/OpenRepository/UserBundle/Entity/User.php]

namespace ODR\OpenRepository\UserBundle\Entity; 

use FOS\UserBundle\Model\User as BaseUser; 
use Doctrine\ORM\Mapping as ORM; 

/** 
* @ORM\Entity 
* @ORM\Table(name="fos_user") 
*/ 
class User extends BaseUser 
{ 
    /** 
    * @ORM\Id 
    * @ORM\Column(type="integer") 
    * @ORM\GeneratedValue(strategy="AUTO") 
    */ 
    protected $id; 

    public function __construct() 
    { 
     parent::__construct(); 
     // your own logic 
    } 
} 

Running:

php app/console doctrine:mapping:info 

zeigt die FOS-Benutzer- oder Gruppenentitäten nicht als zugeordnet an. Es zeigt zwar unsere Benutzerklasse, aber die Erweiterung scheint die Basiseigenschaften nicht zu erfassen.

Vielen Dank für Ihre Unterstützung.

Antwort

1

Wie bei Aktualisierungsproblemen üblich, stellte sich das Problem als inkorrekte Abhängigkeit heraus.

die composer.json aktualisiert alle richtigen Abhängigkeiten enthalten, wie im Referenz composer.json gezeigt:

https://github.com/symfony/symfony-standard/blob/2.7/composer.json

das Problem gelöst. Unsere Doku-Version war nicht korrekt und identifizierte die FOSUserBundle-Elternklasse fälschlicherweise als "vorübergehend", sodass sie nicht in das Metadaten-Array kompiliert wurde.

Nach dem Aktualisieren der Datei composer.json und Ausführen von composer update wurden alle korrekt generierten Schemas und die Anmeldungsfunktionalität wiederhergestellt.

0

Haben Sie das fos-Routing zur Routing-Konfiguration hinzugefügt?

+0

Ja - Routing ist auch in der Routing-Konfiguration. Wir verwenden nicht die "Registrierung" Routing, also laden wir explizit die anderen vier Routen. Auch beim Laden über die Route "all.xml" zeigt das System dieselben Probleme an. –