FOSUserBundle is a great bundle for Symfony2 that implements Security, Authenticity and Authorization for Users. Though is very easy to install and override, it needs a good understanding of the Symfony2′s philosophy, in order to do that in a good manner.

I needed to override the registration process offered by the bundle, in order that the user might choose the role, this feature doesn’t come by default with the bundle.

The steps for doing this task are the following (of course, most of them can be found at FOSUserBundle documentation):

MainUserBundle is the bundle that contains the User entity that extends the User in FOSUserBundle.

1. In MainUserBundle in services.yml I had to add

services:
  main_user.registration.form.type:
    class: Main\UserBundle\Form\Type\RegistrationFormType
    arguments: [%fos_user.model.user.class%,
                      %security.role_hierarchy.roles%]
    tags:
      - { name: form.type, alias: main_user_registration }

Notice %security.role_hierarchy.roles%, this was added in order that the form should receive as parameter an array with all the roles specified in app/config/security.yml. This is necessary because the form is instantiated through the above service:

$form = $this->container->get('fos_user.registration.form');

2. Created the RegistrationFormType.php in my bundle extending the form FOSUserBundle in Main/UserBundle/Form/Type/RegistrationFormType.php.

In this form I had to override also the constructor to tell him to receive the parameter which contained the roles.

 public function __construct($class, $roles_hierarchy = null)
    {
        $this->roles_hierarchy = $roles_hierarchy;
    }

And so I can add a form choice field for role,  with the available choices being the array from the constructor.

3. Finally I had to modify app/config/config.yml
fos_user:
    ...
    registration:
        form:
            type:
              main_user_registration //this is the same alias
                    specified in services

That’s all!

Sonata Admin Bundle implements for Symfony2 the correspondent to AdminGenerator plugin from Symfony version 1.4. It’s easy to install, and not so hard to configure, but it can get a little bit complicated especially if you don’t understand completely the philosophy of Symfony2 (this is my case).

Anyway, with the help of the online documentation available I manage the configure the Sonata AdminBundle and I will list here the steps required to create own list actions for entities without modifying the bundle.

There are some actions that exist by default as is edit, view or delete, but in my case, I had to work with books, I needed to implement publish action for each book, in the following way:

1. In MyBundle/Admin/BookAdmin  (Book is the name of the entity) overide the method:

public function configureListFields(ListMapper $listMapper) {
 $listMapper
 //add fields
 // add custom action links  
 ->add('_action', 'actions', array( 'actions' => array(  
 //....
 'unpublish' => array('template' =>
 'MyBundle:Admin:action_unpublish.html.twig'),)));
} 

This action has a number of optional values that can be declared in an array, and among them is the template option through which you can specify the template that displays the link to this action.

The template I used was located in MyBundle (the bundle that contained the entity) in Resources/Views/Admin

3.  In BookAdmin override the method configureRoutes to add the route for that action

Don’t forget the namespace!

use Sonata\AdminBundle\Route\RouteCollection;

class BookAdmin extends Admin {

...

protected function configureRoutes(RouteCollection $collection) {
 $collection->add('unpublish',
 $this->getRouterIdParameter().'/unpublish'); }

}

4. Create the action in MyBundle/Controller/BookAdminController with the name publishAction($id)

In this action you may put the desired logic.

As I figured it out, until now, Symfony2 hasn’t got a common schema.yml for all entities (an entity is a class/object that maps the correspondent table) as was in Symfony 1.4, but the database configurations are made separate for every entity. In these conditions creating a database starting from the existing entities is a much more laborious task than it was in Symfony 1.4, but not impossible.

There is, although, another solution to this problem, building the entities starting from an existing database. There is a good tutorial in Symfony2 cookbook, but I will also list here the commands needed to complete this task. All of these commands assume that I configured the parameter.ini correctly, so Symfony knows which is the database to use, and also that the bundle Main/MyBundle is initialized, in order to store the entities that will be created.

1. First Symfony needs to generate the metadata corresponding to the tables through the following command. This will create YAML files but it can also create XML files.

     php app/console doctrine:mapping:convert yml ./src/Main/MyBundle /Resources/config/doctrine/metadata/orm --from-database --force

2. Now Symfony can import the configurations from the metadata files

     php app/console doctrine:mapping:import MainMyBundle yml

3. The entities can be generated based on the configuration files

     php app/console doctrine:generate:entities MainMyBundle

That’s all!

But one needs to pay attention to the way he builds his database from the beginning.  For example the relations too must be specified when building the database otherwise Doctrine will not be able to detect them. In phpMyAdmin this is done in the following way:

• go to the structure of the table that will contain the foreign key
• create an index on the field that you want it to be a foreign key
• go back to the structure of the table and click Relation View
• on the field that we want to make a foreign key specify to which other key it is related

For example if you want to have two tables book and author, than the primary key will be in author table, since it is unique, but one author can write one or many books, and the foreign key will be the author_id field in book table.

Admin Generator  for Symfony 1.4 is a powerful tool that creates a fully operational backend application, for administering the site.

The idea behind it, is to create fully operational modules based on module classes, by specifying the model class name in the line command that creates the module:

php symfony doctrine:generate-admin backend Profile

Another important aspect is the generator.yml file which  contains all the configuration necessary for the Admin Generator. Also they also provide a default styling made available by typing the following comand on the console:

$ php symfony plugin:publish-assets 

This article is not a tutorial about how to implement Admin Generator since Symfony’s tutorial is a very good one, but my aim is to underline only some aspects that aren’t so well documented in the official documentation.

A problem I faced was the need to make conditional object actions, that depend on the state off the object.

The solution was to override the _list_td_actions.php file that is situated in the cache. All the files for the backend are generated every time and are stored in cache. In the new template, I had the object upon which I made the action, and it contained all the data from its table in the database, so it was easy to put a condition concerning the state of the object.The same thing can be done with batch actions.

There were several solutions provided on Symfony’s forums but none of them worked, so the solution I implemented was to copy the needed templates in the backend app, keeping their path the same.

<?php if($profile['is_active'] == 1): ?>
  <li>
   <?php echo link_to(__('Deactivate', array(), 'messages'), 
 'profile/ListDeactivate?id='.$profile->getId(), array()); ?>
  </li>
<?php endif; ?>

One important thing here is that when changes are being made to the generator.yml, concerning the template, the template in the backend app previously copied is not modified so it has to be copied again.