Allowed value and default value settings are not properly saved

Same error when setting default value function to any field type.
Also default_value_function value not saved.

Thanks -- this solves my problem as well.

the patch working well.

The patch didn't apply neatly on the current dev version, but after applying it manually it works for me.

Patch does not apply and can't be applied manually to current dev

@tobiasb Thanks for the patch :)

I've rerolled it against latest HEAD. Should work again.

Same issue here. The above file is a diff file? I've use patch files but not a diff file. Will this be added to dev?

@MrPhilbert: You should be able to use the .diff file as patch - it's just a file naming "issue".

subscribe

+++ cck.module
@@ -97,7 +97,7 @@ function cck_allowed_values_form(&$form, $form_state, $field) {
-  $default_value_function = $instance['settings']['default_value_function'];
+  $default_value_function = isset($instance['default_value_function']) ? $instance['default_value_function'] : '';

Incorrect. The value lies in $instance['settings']['default_value_function'], and Field API normally takes care of always populating the entry.

+++ cck.module
@@ -135,8 +135,8 @@ function cck_default_value_form(&$form, $form_state, $field) {
+  $field = isset($form['#field']) ? $form['#field'] : field_info_field($form['field']['field_name']['#value']);

$form['#field'] should also always be present.
If it's not, something is seriously wrong and should be fixed upstream, we don't want to hide that under the carpet and pretend it didn't happen.

More generally, we do not sprinkle code with random isset's all over the place.
I'm won't fixing this as is stands now. If there are actual reported warnings, with line numbers and steps to reproduce, let's investigate them one by one in dedicated issues..

Powered by Dreditor.

As per #12

I think this is in fact a single issue that has to be resolved, so I'm going to reopen with your permission.

How to recreate: Visit any edit or form settings form for a select-type field, configure, and submit. There is a set of problems: Some field values are not saved (as can be viewed in the cck_field_settings table). And some accessed array indexes do not exist, for related reasons, resulting in the OP report.

Many of the problems here are because these forms are injected on both the edit (instance) and the field settings tabs/forms.

$form['#field'] should also always be present.
If it's not, something is seriously wrong and should be fixed upstream, we don't want to hide that under the carpet and pretend it didn't happen.

$form['#field'] and $form['#instance'] are set on the "edit" (instance) tab, but they are not set on the field settings tab.

I'm close to a patch for your review, but don't want to lose this information.

That code needed some love :-). Warnings indeed, plus didn't actually work.

Committed the attached patch, which should fix the issues.

Thanks so much. I actually worked on it quite a bit on the plane, but didn't get far enough to post :-) It's downright hard to get your head into that stuff. Glad your head's in it.

Well, FWIW, now that we have a clearer view on what's left in the CCK project in D7 (that is : the migration code...), I'd say the code that currently lies in cck.module (providing the 'php default value' / 'php allowed values' that didn't make it in core) would be better off in a separate project, field_php_values or something.

I gave this a test spin and it seems fine to me. Thanks for doing this!

Yep, if anyone would like to take over that code, it's all yours :) Initially there were a number of things that didn't make it into core that needed to be handled, but we're down to just that one thing, so it really does make more sense to move it out into its own project.

Related: #1003976: Option to populate select list with php lost in change from cck to fields