Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding Symfony4 support #2639

Merged
merged 27 commits into from Dec 18, 2017

Conversation

@weaverryan
Copy link

commented Nov 9, 2017

Hi guys!

I bumped the deps, made Travis test it, and fixed one test. Unless something isn't covered... this seems like an easy win!

Btw, there seems to be little consistency across bundles about how to organize .travis.yml so that Symfony 4 beta is included. I thought adding a "beta" stability test to the matrix was a good idea: it should always test the latest stable, or beta release I believe. But if I'm wrong of there's a better way, I'd love to know.

Cheers!

.travis.yml Outdated
@@ -14,6 +14,8 @@ env:
matrix:
fast_finish: true
include:
- php: 7.1
env: DEPENDENCIES=beta

This comment has been minimized.

Copy link
@xabbuh

xabbuh Nov 9, 2017

Member

What about also adding an explicit job for 3.4 to have a dedicated job for the next LTS release?

This comment has been minimized.

Copy link
@weaverryan

weaverryan Nov 10, 2017

Author

That's a good idea: I've re-ordered and restructured things. I think it makes sense to test each LTS release, and then also the latest release. Hopefully I've just done that :)

@xabbuh xabbuh referenced this pull request Nov 10, 2017
@tip2tail

This comment has been minimized.

Copy link

commented Nov 11, 2017

Does this include support for symfony/flex, seeing as that will be the default method of project creation in v4.0?

@weaverryan

This comment has been minimized.

Copy link
Author

commented Nov 12, 2017

@tip2tail There's nothing special about Flex that would need to be supported, except for the fact that the Flex directory structure is bundle-less, and I don't think FOSUserBundle relies on your app having a bundle.

So, yes :). Unrelated to this PR, it would be great to add a recipe for FOSUserBundle.

.travis.yml Outdated
@@ -32,6 +40,7 @@ cache:
- $HOME/.composer/cache

before_install:
- if [ "$DEPENDENCIES" = "beta" ]; then perl -pi -e 's/^}$/,"minimum-stability":"beta"}/' composer.json; fi;

This comment has been minimized.

Copy link
@Jean85

Jean85 Nov 15, 2017

Maybe a composer config minimum-stability beta command is better?

@Jean85

This comment has been minimized.

Copy link

commented Nov 15, 2017

Also, quick generic question: isn't dangerous allowing 3 different major versions of Symfony in the same bundle? To me, it seems an easy way to have issues of cross-compat down the line...

@weaverryan

This comment has been minimized.

Copy link
Author

commented Nov 16, 2017

@Jean85 There's no official best-practice about this that I'm aware of. Should bundles support all supported Symfony versions? Or should they only support the last few versions of Symfony when releasing minor versions (with new features)? The safest bet is to support all supported versions. I don't think there's anything dangerous about this - but it is potentially more work for bundle maintainers to keep their code compatible across so many versions.

@Jean85

This comment has been minimized.

Copy link

commented Nov 16, 2017

Yep, the more work is what I'm worried about. As an example, something deprecated in 3.x will be missing in 4 but will have an alternative, but only on 3, not on 2!

In my case (I'm maintaining sentry/sentry-symfony) I chose to have 2 major versions, one with ^2.7||^3.0, the other (to be released soon) with ^3.0||^4.0; this IMHO has the best balance between easier maintainability and better user experience, especially when upgrading between SF versions.

@XWB

This comment has been minimized.

Copy link
Member

commented Nov 16, 2017

Perhaps it is better to create a 2.x branch for bug fixes, and drop Symfony 2.x support in master.

@weaverryan

This comment has been minimized.

Copy link
Author

commented Nov 18, 2017

I actually like the idea of supporting 2 major versions only. It means that as soon as 4.0 is released, there is a new LTS (3.4) and so users will need to upgrade from the old LTS to the new LTS in order to get the new features from the bundle. I think that's a fair requirement.

Then, technically, bundles should continue to offer bug fixes for Symfony versions until they hit end-of-life. But, that's extra work. So maybe some bundles could do that, but I wouldn't expect all community bundles to do that in reality.

So I'm +1 for only supporting 2 major versions. And in well-maintained / popular bundles, we should aim to also make bug fixes available to all supported Symfony versions. And that should probably be up to the maintainer to decide.

@XWB

This comment has been minimized.

Copy link
Member

commented Nov 20, 2017

I've just created 2.0.x branch and bumped master to 3.0.x-dev

  • We should deprecate the 1.3.x branch
  • We should keep the 2.0.x branch for bug fixes
  • We should use master (3.0.x) for BC breaks.
@stof

This comment has been minimized.

Copy link
Member

commented Nov 21, 2017

@XWB please don't make us maintain 2.x and 3.x of the bundle yet. Dropping support of old Symfony versions is not a BC break (it is one only for people not using Composer, as Composer covers it for them, but adding a dependency would also be a BC break for these people so I don't care about them).
New features of FOSUserBundle should be added in a minor version. So master should be 2.1.x, not 3.0.x.

And btw, I don't think dropping support for 2.8 would simplify the maintenance at all (dropping 2.7 will simplify it due to the Form BC layer). If it is easy to support 2.8 to 4.0 in the codebase, I'd rather do it than maintaining 2 branches in parallel to make bug fixes available to 2.8 users (maintaining a single branch is less work for us.

@Jean85

This comment has been minimized.

Copy link

commented Nov 22, 2017

I agree with @stof but I stand by my opinion, supporting max 2 major of Symfony for each major of a bundle should be the limit; 2.8 is just a special case because it's the same as supporting 3.0, so it has the same BC promise as the 3.x SF major.

@xabbuh

This comment has been minimized.

Copy link
Member

commented Nov 22, 2017

2.8 is just a special case because it's the same as supporting 3.0, so it has the same BC promise as the 3.x SF major.

This will always be the case when new major versions are released (e.g. when 5.0 is released, 3.4 is still maintained by the core team with the same feature set as 4.0).

@weaverryan

This comment has been minimized.

Copy link
Author

commented Nov 24, 2017

Regardless of what we decide to support, unless I'm mistaken, this should be merged into master and then we need a new tag. This is the most popular Symfony bundle - we really need a compatible version. We can decide later exactly how old of versions we want to support.

@XWB could you merge and prepare a tab? 😇

"symfony/console": "^2.7 || ^3.0 || ^4.0",
"symfony/phpunit-bridge": "^2.7 || ^3.0 || ^4.0",
"symfony/validator": "^2.7 || ^3.0 || ^4.0",
"symfony/yaml": "^2.7 || ^3.0 || ^4.0",
"phpunit/phpunit": "~4.8.35|~5.4.3"

This comment has been minimized.

Copy link
@xabbuh

xabbuh Nov 24, 2017

Member

Do you really want to exclude 5.5+? The constraint should probably be ^4.8.35|^5.4.3 (for 4.x it actually doesn't really matter as there is no 4.9 release).

This comment has been minimized.

Copy link
@bocharsky-bw

bocharsky-bw Nov 24, 2017

Probably not relevant already? Looks like Ryan just reverted it to the original line

This comment has been minimized.

Copy link
@Jean85

Jean85 Nov 24, 2017

It's surely not relevant to this PR. We can address that elsewhere.

This comment has been minimized.

Copy link
@Jean85

Jean85 Nov 24, 2017

I've proposed the fix in #2647

@weaverryan

This comment has been minimized.

Copy link
Author

commented Nov 27, 2017

Ping @XWB! Could you merge this and create a release? Symfony 4 comes Thu, and this patch is quote tiny :). This is the 1st or 2nd most popular bundle that is still not Symfony 4 compat. I hope we can fix that!

@jblondeau2

This comment has been minimized.

Copy link

commented Nov 27, 2017

+1

@weaverryan

This comment has been minimized.

Copy link
Author

commented Nov 29, 2017

Conflict fixed! @XWB ... a merge and a tag? I'd love to have this be ready before Symfony 4 tomorrow...

.travis.yml Outdated
- php: 5.6
env: SYMFONY_VERSION=2.8.*
# test the latest stable 3.x release
- php: 5.6
env: SYMFONY_VERSION=^3.0

This comment has been minimized.

Copy link
@stof

stof Nov 29, 2017

Member

this does not make any sense. It should test the LTS. We don't want to have jobs for each minor

This comment has been minimized.

Copy link
@Jean85

Jean85 Nov 29, 2017

Well, it's ^3 so since tomorrow the latest LTS and the version for this job will be the same!

This comment has been minimized.

Copy link
@xabbuh

xabbuh Nov 29, 2017

Member

But this will use 3.3 which is not an LTS release.

.travis.yml Outdated
env: SYMFONY_VERSION=^3.0
# test the latest release (including beta releases)
- php: 7.1
env: DEPENDENCIES=beta

This comment has been minimized.

Copy link
@stof

stof Nov 29, 2017

Member

Please use a DEPENDENCIES=dev instead of beta. It would make the job much more useful.

@xabbuh xabbuh referenced this pull request Nov 29, 2017
@XWB

This comment has been minimized.

Copy link
Member

commented Nov 29, 2017

PR looks good in general, though I would like to see the beta dependency removed. We should test against the latest stable Symfony 4.x release.

Should bundles support all supported Symfony versions?

It kind of bothers me that a new major Symfony version can have all BC layers removed, yet bundles need to keep those layers. It feels counter intuitive.

Please don't make us maintain 2.x and 3.x of the bundle yet. Dropping support of old Symfony versions is not a BC break

Yes I bumped master back to 2.1

And btw, I don't think dropping support for 2.8 would simplify the maintenance at all (dropping 2.7 will simplify it due to the Form BC layer). If it is easy to support 2.8 to 4.0 in the codebase

Thanks, I'm gonna drop Symfony 2.7 support.

.travis.yml Outdated
@@ -32,6 +36,7 @@ cache:
- $HOME/.composer/cache

before_install:
- if [[ -v $STABILITY ]]; then composer config minimum-stability $STABILITY; fi;
- if [ "$SYMFONY_VERSION" != "" ]; then composer require "symfony/symfony:${SYMFONY_VERSION}" --no-update; fi;

This comment has been minimized.

Copy link
@stof

stof Nov 29, 2017

Member

this line must be updated, as you replaced SYMFONY_VERSION=2.8.* by DEPENDENCIES="symfony/lts:^2" in the job matrix and this is the corresponding one

.travis.yml Outdated
allow_failures:
- php: 7.1

This comment has been minimized.

Copy link
@stof

stof Nov 29, 2017

Member

Remove php: 7.1 from the conditions matching the allowed failure (matching any PHP version as long as it has env: STABILITY="dev"). This way, we have a single place to update when changing the PHP version for the dev job

.travis.yml Outdated
allow_failures:
- php: 7.1
env: STABILITY="dev"
- php: hhvm

This comment has been minimized.

Copy link
@stof

stof Nov 29, 2017

Member

I suggest removing testing on HHVM as HHVM stopped bothering about PHP compat and Symfony dropped support for it. I see no interest into debugging HHVM failures if they don't care about PHP compat, so I don't care about having it on CI (I removed it from any project I maintain for which I reworked the Travis config after their announcement)

@stof

This comment has been minimized.

Copy link
Member

commented Nov 29, 2017

@weaverryan please rebase, as this PR conflicts with #2651 dropping SF 2.7 support to make maintenance easier

@weaverryan weaverryan force-pushed the weaverryan:patch-1 branch from 2d1226a to d11627c Nov 29, 2017

@weaverryan

This comment has been minimized.

Copy link
Author

commented Nov 29, 2017

Ok! This should now be ready:

  1. I made several changes to .travis.yml from Stof's feedback
  2. I added public=true to all currently-public services and aliases (except for listeners & form types - these should be public, and by not adding making any changes, they will become private in 4.0).

I think we should merge this immediately. That will make it easier to test. Then, we can tag a new version shortly after (probably people from the community can help us test, once it's merged).

@ceesvanegmond

This comment has been minimized.

Copy link

commented Feb 6, 2018

Any idea when a stable 2.1 release comes out?

@mirkorap

This comment has been minimized.

Copy link

commented Feb 16, 2018

How can I override the RegistrationFormType in Symfony 4? I do in this way, but it doesn't work:

My RegistrationType
image

Explicit service config (services.yaml)
image

fos_user.yaml:
image

In my entity User class, I declare firstname as protected property and setter/getter method of it (setFirstname and getFirstname). Of course my entity extends BaseUser of FOSUserBundle.
image

But in my Twig template, if I use form_widget(form.firstname), I get an error:

Twig template:
image

The error is:

Neither the property "firstname" nor one of the methods "firstname()", "getfirstname()"/"isfirstname()"/"hasfirstname()" or "__call()" exist and have public access in class "Symfony\Component\Form\FormView".

@richard4339

This comment has been minimized.

Copy link

commented Feb 17, 2018

@mirkorap it took me a bit to get this, but using the latest documentation I finally got it!

What I can't see from your example above is if you did add the getter/setters, and tbh since you got that far I'm assuming your RegistrationType class and service registration is fine. However, I'm putting everything I did below.

First off, I followed the example here exactly, only I put my form in a bundle and used the field timezone.

<?php

namespace App\CWM\CWMBundle\Form;

use Symfony\Component\Form\AbstractType;
use Symfony\Component\Form\FormBuilderInterface;

class RegistrationType extends AbstractType
{
    public function buildForm(FormBuilderInterface $builder, array $options)
    {
        $builder
            ->add('timezone')
        ;
    }

    public function getParent()
    {
        return 'FOS\UserBundle\Form\Type\RegistrationFormType';
    }

    public function getBlockPrefix()
    {
        return 'app_user_registration';
    }
}

That's really the main difference.

fos_user:
    registration:
        form:
            type: App\CWM\CWMBundle\Form\RegistrationType`

`services:
    app.form.registration:
        class: App\CWM\CWMBundle\Form\RegistrationType
        tags:
            - { name: form.type, alias: app_user_registration  }

Now I did this and got your getter/setter issue. Realized I hadn't added

    /**
     * @return \DateTimeZone
     */
    public function getTimezone()
    {
        return $this->timezone;
    }

    /**
     * @param \DateTimeZone $timezone
     * @return User
     */
    public function setTimezone(\DateTimeZone $timezone): User
    {
        $this->timezone = $timezone;
        return $this;
    }

into my User class. Once I did this it worked.

image

@mirkorap

This comment has been minimized.

Copy link

commented Feb 19, 2018

@richard4339 thanks a lot, I'll try this configuration.

@pribeirojtm

This comment has been minimized.

Question; Could you turn these private properties in protected? I'm asking this because my customized UserBundle extends this FosUserBundle, and I'm extending some controllers, and I want to use, for example, $userManager in my Controller Class class. How can I achive that without having to inject all the required services that are used in Base Controller class, and having to call parent::__construct(...) . Thanks in advance.

This comment has been minimized.

Copy link
Member

replied Feb 19, 2018

I don't want to maintain backward compatibility on all these properties. It would make the maintenance cost higher. This is why they are private.

I'm already not in favor of extending our controller classes and I'm not ensuring BC for such usage (as it would then forbid us to make most changes to our controllers, requiring us to reject any new feature requiring a change to them). So I don't want to make this case easier by switching to protected.
As soon as you have an extra dependency, you will need to override the constructor and call the parent one anyway, so this would even only make it simpler when having no additional dependency.

This comment has been minimized.

Copy link

replied Feb 19, 2018

Thanks. So because I'm extending FosUserBundle and extending this controller, I must have to inject all necessary services in my controller and then call the parent::consctrunct(... right? Do you recommend another way of doing this? I'm using sf 3.4
Thanks

This comment has been minimized.

Copy link
Member

replied Feb 19, 2018

Well, not calling the parent constructor would leave the class in an unusable state. So yes, calling the parent constructor is mandatory.

We switched from a using the container as a service locator to using DI, because Symfony 3.4 discourages the usage of the DIC as a service locator (as it makes services private by default, and so unusable through service location). Making the constructor bigger is the side-effect of making dependencies explicit. I have no plan to revert this.

My recommendation is to avoid extending the FOSUserBundle controllers. Many use cases can be implemented by hooking into the FOSUserBundle events instead. But without more details about what your own code does, I cannot give you advices about the best way to handle it.

Can you create an issue to discuss this though ? discussions on commits tend to be lost as the only way to know about them is the notification (and so it is a one-time usage). I don't go over all past commits to check for on-going discussions on them (and you are even lucky that I saw the notifications on this one, as I don't read all my github notifications).

This comment has been minimized.

Copy link

replied Feb 19, 2018

Thanks for the advices.

@juhulee

This comment has been minimized.

Copy link

commented on 255d13c Feb 21, 2018

Hi,
I've got a question about those changes. We are having a stateless application, so we're not using sessions.
Since those changes appear, composer update always throws an error "[LogicException]
FOSUserBundle requires the "session" service to be available." on ScriptHandler::clearCache.
I went back to version 2.0.2 and the error was gone.
I tried adding session: false to the config, then I got problems with the registration. So I added registration: false, then I got problems with the email-configs and so on.
Could you help me how I can work with version 2.1.* without having sessions?
Or is there maybe a bug here?
Thanks alot,
Jule

This comment has been minimized.

Copy link
Member

replied Feb 21, 2018

@juhulee the session is needed only for setting flash messages and for the registration layer. Disabling these 2 will not trigger the session required error anymore in 2.1.1

@aleixfabra

This comment has been minimized.

Copy link

commented Jul 18, 2018

Hi guys!

How is FOSUserBundle Symfony 4 support? Is it fully integrated?

For example, @blackbart420 said that "with SF4, the bundle should create the config file fos_user.yaml but for now you have to add it by yourself."

It also seems that the documentation is not updated (it uses files paths from Symfony 3) https://symfony.com/doc/master/bundles/FOSUserBundle/index.html

Is there any guide for Symfony 4 setup?

I would be grateful if anyone could fill me in with the current state of the integration.

Thanks!

@yonisolo

This comment has been minimized.

Copy link

commented Jul 19, 2018

Hi @aleixfabra,
we use it with symfony 4.0.12 without any problem, however there is still lots of deprecated features avoiding us to use it with symfony 4.1, for example User Checker and advanced User Interface...
But this still works fine. Since we did the migration some time ago, I don't know if the config file is generated or not. here an example of config file which is working for us:

fos_user:
    db_driver: orm
        firewall_name: main
    user_class: App\Entity\User
    group:
        group_class: App\Entity\Group
    from_email:
        address: "donotreply@test.com"
        sender_name: "Account Test"
    use_flash_notifications: false
    service:
        mailer: fos_user.mailer.twig_swift
    resetting:
        token_ttl: 86400
        email:
            from_email:
                address:        donotreply@test.com
                sender_name:    "Account Test"
            template:   email/password_resetting.email.twig
    registration:
        confirmation:
            enabled: true
            from_email:
                address:        donotreply@test.com
                sender_name:    "Account creation"
            template: email/confirm_registration.email.twig
        form:
            type: App\Form\RegistrationFormType

we use composer: "friendsofsymfony/user-bundle": "^2.1"

@aleixfabra

This comment has been minimized.

Copy link

commented Jul 20, 2018

It will be Symfony 4.1 support soon?

Thanks!

@Tomsgu

This comment has been minimized.

Copy link

commented Jul 20, 2018

I am using it with Symfony 4.1 in more than 3 different projects without any problems. So I don’t understand what you’re asking about.

@yonisolo

This comment has been minimized.

Copy link

commented Jul 20, 2018

@aleixfabra
Obviously, there are just few deprecated features for 4.1 but this should work, we just avoid it for the moment:

The "FOS\UserBundle\Model\UserInterface" interface extends "Symfony\Component\Security\Core\User\AdvancedUserInterface" that is deprecated since Symfony 4.1 *.

@Tomsgu do you use the dev-master?

@aleixfabra

This comment has been minimized.

Copy link

commented Jul 23, 2018

This has worked for me:

$ composer require friendsofsymfony/user-bundle "^2.1"
// config/packages/fos_user.yaml

fos_user:
    db_driver: orm
    firewall_name: main
    user_class: App\Entity\User
    from_email:
        address: test
        sender_name: test
// config/packages/framework.yaml

framework:
    // ...

    templating:
        engines: ['twig']
// config/packages/security.yaml

security:
    encoders:
        FOS\UserBundle\Model\UserInterface: bcrypt

    role_hierarchy:
        ROLE_ADMIN:       ROLE_USER
        ROLE_SUPER_ADMIN: ROLE_ADMIN

    # https://symfony.com/doc/current/security.html#where-do-users-come-from-user-providers
    providers:
        in_memory: { memory: ~ }
        fos_userbundle:
            id: fos_user.user_provider.username

    firewalls:
        dev:
            pattern: ^/(_(profiler|wdt)|css|images|js)/
            security: false
        main:
            pattern: ^/
            form_login:
                provider: fos_userbundle
                csrf_token_generator: security.csrf.token_manager
            logout:       true
            anonymous:    true

    # Easy way to control access for large sections of your site
    # Note: Only the *first* access control that matches will be used
    access_control:
        - { path: ^/login$, role: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/register, role: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/resetting, role: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/admin/, role: ROLE_ADMIN }
// config/routes/fos_user.yaml

fos_user:
    resource: "@FOSUserBundle/Resources/config/routing/all.xml"
<?php

namespace App\Entity;

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

/**
 * @ORM\Entity(repositoryClass="App\Repository\UserRepository")
 */
class User extends BaseUser
{
    /**
     * @ORM\Id()
     * @ORM\GeneratedValue()
     * @ORM\Column(type="integer")
     */
    protected $id;

    public function __construct()
    {
        parent::__construct();
    }
}
<?php

namespace App\Repository;

use App\Entity\User;
use Doctrine\Bundle\DoctrineBundle\Repository\ServiceEntityRepository;
use Symfony\Bridge\Doctrine\RegistryInterface;

/**
 * @method User|null find($id, $lockMode = null, $lockVersion = null)
 * @method User|null findOneBy(array $criteria, array $orderBy = null)
 * @method User[]    findAll()
 * @method User[]    findBy(array $criteria, array $orderBy = null, $limit = null, $offset = null)
 */
class UserRepository extends ServiceEntityRepository
{
    public function __construct(RegistryInterface $registry)
    {
        parent::__construct($registry, User::class);
    }
}
$ php bin/console doctrine:schema:update --force
@RoestVrijStaal

This comment has been minimized.

Copy link

commented Aug 1, 2018

Thanks for not updating the docs for SF4 👎

@xabbuh

This comment has been minimized.

Copy link
Member

commented Aug 1, 2018

@RoestVrijStaal This is open source. You could be the one contributing the documentation update.

@RoestVrijStaal

This comment has been minimized.

Copy link

commented Aug 2, 2018

@xabbuh Yes, i know.

BUT. I don't know anything about the internals (read: the internals) of FOSUserBundle nor Symfony, nor I want to know those (Blackboxing, anyone?).

@danabrey

This comment has been minimized.

Copy link

commented Aug 2, 2018

@RoestVrijStaal I don't want to read passive-aggressive, selfish comments on open source projects, and yet here we are.

@ceesvanegmond

This comment has been minimized.

Copy link

commented Aug 2, 2018

@danabrey Totally agree with you. @RoestVrijStaal Welcome to open source. If you want to add new documentation, please do! We're all in this together :-)

@polishExperiment

This comment has been minimized.

Copy link

commented Oct 10, 2018

@xabbuh I would like to contribute to documentation update. I don't know how though. Can You or someone point me towards how to do this?

@CyrilCharlier

This comment has been minimized.

Copy link

commented Oct 10, 2018

@xabbuh I would like to contribute to documentation update. I don't know how though. Can You or someone point me towards how to do this?

Just go to this adress :

https://github.com/FriendsOfSymfony/FOSUserBundle/edit/master/Resources/doc/index.rst

;)

@gustawdaniel

This comment has been minimized.

Copy link

commented Dec 10, 2018

In docs there is written:

The easiest way to override a bundle's template is to simply place a new one in your app/Resources folder. To override the layout template located at Resources/views/layout.html.twig in the FOSUserBundle directory, you would place your new layout template at app/Resources/FOSUserBundle/views/layout.html.twig.

But in symfony 4 there is not catalog app and twig files are located in /templates by default.

Know anyone how to override FOS views in symfony4?

@gustawdaniel

This comment has been minimized.

Copy link

commented Dec 10, 2018

Ok. I found instead app I should use src

/src/Resources/FOSUserBundle
@yonisolo

This comment has been minimized.

Copy link

commented Dec 10, 2018

Hi @gustawdaniel , views can be overridden in templates/bundles/FOSUserBundle/... we use symfony 4.1 and it works without any problem

@gustawdaniel

This comment has been minimized.

Copy link

commented Dec 10, 2018

Thanks @yonisolo but in my case templates/bundles/FOSUserBundle/views/... does not work...

Ok I had installed version "friendsofsymfony/user-bundle": "~2.0" because of I followed by tutorial:

https://ourcodeworld.com/articles/read/794/how-to-install-and-configure-fosuserbundle-in-symfony-4

When I updated to 2.1

There is no error:

Executing script cache:clear [KO]
 [KO]
Script cache:clear returned with error code 1
!!  
!!  In ArrayNode.php line 228:
!!                                                                       
!!    The child node "db_driver" at path "fos_user" must be configured.  
!!                                                                       
!!  
!!  
Script @auto-scripts was called via post-update-cmd

And move templates to templates/bundles/FOSUserBundle/ works only if you remove directory views

zrzut ekranu z 2018-12-10 11-20-55

@yonisolo

This comment has been minimized.

Copy link

commented Dec 10, 2018

yes if you have only views to override, you don't need to add /src/Resources/FOSUserBundle
directory and all logic behind, but if you need to override more logic, then I don't know if it's better to separate view templates from src or keep it inside...

@alex4102

This comment has been minimized.

Copy link

commented on 7c10a15 Aug 7, 2019

Now my {{ render(controller('FOSUserBundle:Resetting:request')) }} not works because of construct function. Do you know how to embed the request form without duplicate it ?

@alex4102

This comment has been minimized.

Copy link

commented on bcbe7d1 Aug 7, 2019

Now my {{ render(controller('FOSUserBundle:Registration:register')) }} not works because of construct function for service. Do you know how to embed the request form without duplicate it ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.