👍 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<?phpnamespaceAppBundle\Controller;useSensio\Bundle\FrameworkExtraBundle\Configuration\Route;useSymfony\Bundle\FrameworkBundle\Controller\Controller;useSymfony\Component\HttpFoundation\Request;useAppBundle\Form\Type\Other\SimpleType;class IndexControllerextends Controller{/**     * @Route("/", name="homepage")     */publicfunctionhomepageAction(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.phpnamespaceAppBundle\Form\Type\Other;useSymfony\Component\Form\AbstractType;useAppBundle\Form\Type\SimpleTypeasBaseType;class SimpleTypeextends AbstractType{publicfunctiongetParent()    {return BaseType::class;    }}

<?php//src/AppBundle/Form/Type/SimpleType.phpnamespaceAppBundle\Form\Type;useSymfony\Component\Form\AbstractType;useSymfony\Component\Form\Extension\Core\Type\TextType;class SimpleTypeextends AbstractType{publicfunctiongetParent()    {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.phpnamespaceAppBundle\Form\Type\Other;useSymfony\Component\Form\AbstractType;useAppBundle\Form\Type\SimpleTypeasBaseType;class SimpleTypeextends AbstractType{publicfunctiongetParent()    {return BaseType::class;    }publicfunctiongetBlockPrefix()    {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 ofanother type fromgetBlockPrefix() 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 anymoreas we did so far, reducing the potential for performance improvements.

We should consider to recommend returning unique values fromgetBlockPrefix().

@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 thisAppBundle\Form\Type\Other\SimpleType =>other_simple andAppBundle\Form\Type\SimpleType =>simple orAppBundle\Form\Type\Other\Another\SimpleType =>other_ another_simple

orAbstractType::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 likethis 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