EDIT: For anyone interested on solving the same issue, that did the trick:
echo `'xdebug.max_nesting_level = 250' >> /etc/php5/conf.d/xdebug.ini`
I've created 3 Admins for 3 entities linked to each other, where A Admin is embedding B Admin and B Admin embeds C Admin. B entity has a ManyToOne relation with A and B entity.
A entity embeds B entity with the following code:
$formMapper->add('b', 'sonata_type_collection', array(
'by_reference' => false
), array(
'edit' => 'inline',
'inline' => 'table',
'sortable' => 'position'
) );
B entity embeds C entity with the following one:
$formMapper->add( 'c', 'sonata_type_model', array(
'required' => true,
'label' => ucfirst( $this->trans( 'c', array(), $this->translationDomain, $this->langCode ) )
), array( 'edit' => 'list' ) );
Note: changing 'edit' => 'list'
in favour of 'edit' => 'standard'
avoids the following error.
Placing array( 'edit' => 'list' )
on B Admin entity on a sonata_type_model
form type gives the following error while editing A enity. If instead array( 'edit' => 'standard' )
is used then no error is output:
Sonata: Fatal error: Maximum function nesting level of '100' reached, aborting! in myProject/vendor/doctrine-common/lib/Doctrine/Common/Lexer.php on line 756
The tricky or curious thing is that no matter if edit is list or standard if i go to B admin to edit it. the problem only appears if i edit B embedded into A with edit list option set. And this is happening to me in some other entities where i implemented the same behaviour.
Here are A, B and C entity and how they link each other:
A entity:
class A
{
/**
* @ORM\Id
* @ORM\Column(type="integer", length=4)
* @ORM\GeneratedValue(strategy="IDENTITY")
*/
private $id;
/** @ORM\OneToMany(targetEntity="B", mappedBy="a", cascade={"persist"}, orphanRemoval=true ) */
protected $b;
}
B entity:
class B
{
/**
* @ORM\Id
* @ORM\Column(type="integer", length=4)
* @ORM\GeneratedValue(strategy="IDENTITY")
*/
private $id
/**
* @ORM\ManyToOne(targetEntity="C", inversedBy="b", cascade={"persist"} )
* @ORM\JoinColumn(name="c_id", nullable=false, referencedColumnName="id", onDelete="CASCADE")
*/
private $c;
/**
* @ORM\ManyToOne(targetEntity="A", inversedBy="b", cascade={"persist"} )
* @ORM\JoinColumn(name="a_id", nullable=false, referencedColumnName="id", onDelete="CASCADE")
*/
private $a;
}
C entity:
Class C
{
/**
* @ORM\Id
* @ORM\Column(type="integer", length=4)
* @ORM\GeneratedValue(strategy="IDENTITY")
*/
private $id;
/** @ORM\OneToMany(targetEntity="B", mappedBy="c", cascade={"persist"} ) */
private $b;
}
To be able to take a look at it all you can use sonata demo project to check for a similar behaviour.
As you can see it is the same use case which can be found on Sonata Project demo where Gallery is linked against GalleHasMedias which links against Media: http://demo.sonata-project.org/admin/sonata/media/gallery/255/edit?context=default As you can see, GalleryHasMedia has a ManyToOne relation with Gallery and another one with Media so when you edit a Gallery ou can see a sonata_type_model
with edit' => 'inline','inline' => 'table',
so a GalleryHasMedia is embedded inside Gallery form in order to be able to add new Medias which are going to be linked with the current Gallery and stored inside GalleryHasMedia
.
Has any one faced a situation like the exposed one? Hope someone could point to the right direction or help to get a clue on what's going on.
PD: For me it seems like B and C entities are linking/embedding each other in an endless loop. But as said, 3 Admins are working great separately (while A does not embeds B).
This is a common problem with servers running xdebug. You must increase the nesting level by increasing the xdebug.max_nesting_level
in your xdebug.ini configuration. Setting it to something like 250 should suffice.
One quick way to add the setting is to do this on your linux server:
echo `'xdebug.max_nesting_level = 250' >> /etc/php5/conf.d/xdebug.ini`
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With