👍 I've just noticed similar error in my own application. The problem seems to occur when a prefix is repeated in the block_prefixes array. The exception is thrown too early - in the example from @andrey1s the block form_row certainly exists even though the exception says otherwise.

Hi, thanks for reporting this problem :) How can it happen that a block name is repeated in the chain? Can you provide code that reproduces your problem?

for example

//src/AppBundle/Controller/IndexController.php
<?php

namespace AppBundle\Controller;

use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use Symfony\Component\HttpFoundation\Request;
use AppBundle\Form\Type\Other\SimpleType;

class IndexController extends Controller
{
    /**
     * @Route("/", name="homepage")
     */
    public function homepageAction(Request $request)
    {
        $form = $this
            ->createFormBuilder()
            ->add('simple', SimpleType::class)
            ->getForm()
        ;

        return $this->render('@App/Index/homepage.html.twig', ['form' => $form->createView()]);
    }
}

forms

<?php
//src/AppBundle/Form/Type/Other/SimpleType.php
namespace AppBundle\Form\Type\Other;

use Symfony\Component\Form\AbstractType;
use AppBundle\Form\Type\SimpleType as BaseType;

class SimpleType extends AbstractType
{
    public function getParent()
    {
        return BaseType::class;
    }
}

<?php
//src/AppBundle/Form/Type/SimpleType.php
namespace AppBundle\Form\Type;

use Symfony\Component\Form\AbstractType;
use Symfony\Component\Form\Extension\Core\Type\TextType;

class SimpleType extends AbstractType
{
    public function getParent()
    {
        return TextType::class;
    }
}

when there are two blocks with the same name is an error.
We can quickly fix the error in the form for example:

<?php
//src/AppBundle/Form/Type/Other/SimpleType.php
namespace AppBundle\Form\Type\Other;

use Symfony\Component\Form\AbstractType;
use AppBundle\Form\Type\SimpleType as BaseType;

class SimpleType extends AbstractType
{
    public function getParent()
    {
        return BaseType::class;
    }

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

Thanks for the example, I understand your use case now. This conveys a bigger problem IMO.

In a template, a block (e.g. checkbox_widget) expects a specific block when rendering the block for the parent type (form_widget). By returning the block of another type from getBlockPrefix() we mess up that inheritance chain:

• Twig blocks can't expect deterministic parent blocks anymore.
• We can't short-circuit the loading of parent blocks anymore as we did so far, reducing the potential for performance improvements.

We should consider to recommend returning unique values from getBlockPrefix().

@webmozart In that case we should modify the exception - if there is a duplicate in the array throw an exception about that instead of what is thrown currently. Probably only when a problem like this occurs to avoid unnecessary checking for non-unique prefixes for every field.

@webmozart if we need to use a unique template, then Yes, otherwise it's not necessary.
if use unique block_prefix, may be better to use by default, e.g. like this AppBundle\Form\Type\Other\SimpleType => other_simple and AppBundle\Form\Type\SimpleType => simple or AppBundle\Form\Type\Other\Another\SimpleType => other_ another_simple

or AbstractType::getBlockPrefix() should return an empty block name. And add only if not empty.

@enumag Throwing an exception sounds like the best solution to me.

@andrey1s Changing the default block name is not possible without breaking BC.

IIUC, this change should not be merged but a new exception should be added, is that correct? How do we moved forward?

@fabpot I think adding an exeption like this solves the problem (at least the exception message is not so confusing anymore). However I was unable to write a test for it since FormRenderer class doesn't have any tests.

@enumag Can you update this PR with the commit you mentioned above? Tests can be added later or by someone else if needed.

@fabpot I'm not the author of this PR so I'll have to create a new one instead. Wait a moment...

Does that mean we should close here in favour of #19127?

Closing in favor of #19127