Newest build caused UndefinedOptionsException for "fields" and "legend"

[brianshaw]

The options "fields", "legend" do not exist. Known options are: "action", "allow_extra_fields", "attr", "auto_initialize", "block_name", "by_reference", "cascade_validation", "compound", "constraints", "csrf_field_name", "csrf_message", "csrf_protection", "csrf_provider", "csrf_token_id", "csrf_token_manager", "data", "data_class", "disabled", "empty_data", "error_bubbling", "error_mapping", "extra_fields_message", "help", "inherit_data", "intention", "invalid_message", "invalid_message_parameters", "label", "label_attr", "label_format", "mapped", "max_length", "method", "pattern", "post_max_size_message", "property_path", "read_only", "required", "translation_domain", "trim", "validation_groups", "virtual". 500 Internal Server Error - UndefinedOptionsException

Reverting back to cd1e3831014cb8d9f0b71813750b9df715458122 fixes the error.

This error happens when I set the fields or legend variable here: $builder->add('general', 'fieldset', array( 'label' => false, 'legend' => 'General', 'fields' => array( array( 'name'=>'name', 'type'=>'text', 'attr'=> array( 'label' => 'entry_name', 'constraints' => array( new NotBlank(), new Length(array( 'min' => 3, 'max' => 255 )), ) ) ),

....... and so on.

Did I miss something?

[Winde4th]

You have to use configureOptions() from OptionsResolver instead of setDefaultOptions() from OptionsResolverInterface

[Mondane]

@adamquaile do you have an estimate when a new version will be available that's compatible with symfony 3.1 ?

[Mondane]

@adamquaile I've updated my composer.json to

"adamquaile/symfony-fieldset-bundle": "dev-master#951f7fe9738ff98890fbc9ad236161514077fb3c",

and my form doesn't break anymore. Is this commit ready to be tagged?

[adamquaile]

@Mondane @ABM-Dan That commit is now tagged asv1.0.1 so you can stop pinning to that commit if you have been.

Also, I have updated the composer.json to allow for Symfony3 - just a PR for now as I haven't had a chance to test it. Feel free to have a go, and I'll get that merged and tagged once we know it's working: https://github.com/adamquaile/AdamQuaileFieldsetBundle/pull/16

[Mondane]

@adamquaile it turns out, composer will install 1.1.0 :

• Updating adamquaile/symfony-fieldset-bundle (dev-master 951f7fe => 1.1.0) Checking out cd1e3831014cb8d9f0b71813750b9df715458122

I suggest removing tag 1.0.1 and retagging it as 1.1.1 to avoid this problem. For now, I'll link to the specific commit.

[adamquaile]

@Mondane You're right, that was incorrectly tagged, at 1.0.1 instead of 1.1.1. I've updated it now.

[Mondane]

@adamquaile I don't know why, but I still can't update to v1.1.1. I've set this line in *composer.json:

"adamquaile/symfony-fieldset-bundle": "~1.1.1",

which gives me:

Problem 1

• The requested package adamquaile/symfony-fieldset-bundle ~1.1.1 exists as adamquaile/symfony-fieldset-bundle[0.0.0, 1.0.0, 1.1.0, dev-feature/symfony-3-support, dev-master] but these are rejected by your constraint.

NB When I use "adamquaile/symfony-fieldset-bundle": "~1.1", tag 1.1.0 is installed.

[adamquaile]

@Mondane It's not appearing in packagist for some reason, even though it's tagged in Github. I wonder why..

[Mondane]

@adamquaile I've asked Packagist what it could be, their reply:

Hey,

This is because of https://github.com/adamquaile/AdamQuaileFieldsetBundle/blob/951f7fe9738ff98890fbc9ad236161514077fb3c/composer.json#L3

Just remove the field from the json and future tags will be fine, if you keep in there you have to make sure you update it to match the tag name every time before tagging.

Best, Jordi

[adamquaile]

@Mondane D'oh! Of course! I've removed and tagged v1.1.3 and it's on packagist here: https://packagist.org/packages/adamquaile/symfony-fieldset-bundle#v1.1.3 .

Thanks for figuring that out.