Upgrading optionwidgets_select' type:text do not work

I have a problem with "optionwidgets_select" too. The values of the field are converted but the choosen value is not set. No answer either.

Would you please point me to it. I clicked your name and scrolled to your first posts but could not find it.

I have the same issue. Now I can't filter field_language using views. I posted this issue at http://drupal.org/node/1367522.

After migration in view mode of the node, I see the system value (for example 2) and not the text associated.
In edit mode, it's OK.
Migration is therefore not possible.

Seems migration is OK for list(text), now. There is perhaps still a problem with list(integer), because the problem exists with that core type of field.

I decided to change all list values like "1|NameOfTeam" to "NameOfTeam". That way values are set again. So I choose to make the value|label pair to have the same values.

I'm still running into problems with all my Option Widget Text fields from D6 loosing all their values after upgrade to D7.

Here's my Drupal 6 content type export: http://drupalbin.com/20673
(It looks like there's no way to export content types in D7? If someone can tell me how to get a content type out of D7, I'll provide that too. )

Here are the ALlowed values for the field:

0|no
1|yes

It looks like in D6 it was the values (and not the keys) that were getting saved into the database. But in D7 it expects the keys to be saved, and uses those to populate the widget. You can see in the data values for D7, below, that the one value I saved has saved the key in the database.

Here are 10 data values for D6

+-----+-----+------------------+
| vid | nid | field_sold_value |
+-----+-----+------------------+
|  13 |  13 | yes              |
|  14 |  14 | yes              |
|  15 |  15 | yes              |
|  16 |  16 | yes              |
|  49 |  49 | yes              |
| 216 | 216 | yes              |
|  47 |  47 | yes              |
|  59 |  59 | no               |
|  60 |  60 | yes              |
|  61 |  61 | yes              |
+-----+-----+------------------+
10 rows in set (0.00 sec)

Here are 10 data values for D7

+-----------+-------------+------------------+
| entity_id | revision_id | field_sold_value |
+-----------+-------------+------------------+
|       908 |         908 | no               |
|       877 |         877 | no               |
|       876 |         876 | 1                |
|       874 |         874 | no               |
|       873 |         873 | no               |
|       872 |         872 | no               |
|       871 |         871 | no               |
|       869 |         869 | no               |
|       862 |         862 | no               |
|       857 |         857 | no               |
+-----------+-------------+------------------+
10 rows in set (0.00 sec)

Perhaps as part of the upgrade, all the values saved in the DB should be replaced with keys.

I believe I am experiencing the same, or at least a related issue. Here's what's happening for me:

I've got several custom content types in Drupal 6 with type "Text" and "Check boxes/radio buttons" for the widget type. This allows you to create a radio button list of options, and the user selects the appropriate option.

Upon upgrading to Drupal 7, these fields were converted to type "List (text)". This seems to have worked fine for all the existing content, but I tried creating some new content that uses the new "List (text)" fields, and on the node display page, instead of the label for the option selected, I get the numeric value. My "List (text)" options are setup something like this:

0|Support
1|Neutral
2|Oppose

The number is the value, and the word after the pipe is the label. What is supposed to happen (and happens for all previous content) is that the selected label appears.

But what is happening for all new content is that the value, the number 0, 1, or 2, is displayed.

I tried creating a new content type, with a new "List (text)" field, and it works fine. On the node display page, the value seen by the end user is the label, not the value.

I compared my new field (that shows the value, as expected) and my old field (that shows the value, not the label) side by side. They are completely identical.

So something happened during the migration of the field from a D6 CCK "Text" field to a D7 "List (text)" field that appears to have messed it up, but not in a way that is apparent through the Drupal Fields UI.

As some others have suggested, I tried getting rid of the value by changing my list options to:

Support
Neutral
Oppose

Via the Fields UI. This failed with the error Allowed values list: some values are being removed while currently in use.

The error message itself is somewhat misleading, it should say "Allowed values list: you cannot remove values currently in use." The way it's worded it means that the values "are being removed" when in fact, nothing is happening. At least, as far as I can tell, nothing is happening.

-Josh

Here's a pseudo fix that I've discovered. Note that this only fixes the issue after the fields have been mangled during the migration process. A true fix would be to fix the migration process, but I haven't been able to figure that out.

I used a debugger to step through the Drupal Field code and compared the logic flow between my migrated list_text fields, which are not working, and my newly created list_text field, which are working.

What I discovered was that when you reach the function field_default_view in field.default.inc, it tries to dynamically compose a function name to format the output of your field. For a list field, this should be list_field_formatter_view. For a text field, it should be text_field_formatter_view. Here's the code:

function field_default_view($entity_type, $entity, $field, $instance, $langcode, $items, $display) {
  list($id, $vid, $bundle) = entity_extract_ids($entity_type, $entity);

  $addition = array();

  // Prepare incoming display specifications.
  if (is_string($display)) {
    $view_mode = $display;
    $display = field_get_display($instance, $view_mode, $entity);
  }
  else {
    $view_mode = '_custom_display';
  }

  if ($display['type'] !== 'hidden') {
    // Calling the formatter function through module_invoke() can have a
    // performance impact on pages with many fields and values.
    $function = $display['module'] . '_field_formatter_view';
    if (function_exists($function)) {
      $elements = $function($entity_type, $entity, $field, $instance, $langcode, $items, $display);
    // Snipped rest of function

What's happening is that $display['module'] is set to "text" for the migrated list_text fields. For my new list_text field, it is "list". Based on this, I went digging to try and figure out why my migrated fields have different $display['module'] values than my new, working list_text field.

What I found is that $display['module'] is set (indirectly) by the data in the database field field_config_instance.data. This is a blob of serialized data. Here's what it looked like for my working, new list_text field (deserialized and passed to print_r):

Array
(
    [label] => List (text)
    [widget] => Array
        (
            [weight] => 32
            [type] => options_buttons
            [module] => options
            [active] => 1
            [settings] => Array
                (
                )

        )

    [settings] => Array
        (
            [user_register_form] => 
        )

    [display] => Array
        (
            [default] => Array
                (
                    [label] => above
                    [type] => list_default
                    [settings] => Array
                        (
                        )

                    [module] => list
                    [weight] => 1
                )

        )

    [required] => 0
    [description] => 
    [default_value] => 
)

And here's what it looked like for my migrated list_text field--which was not working:

Array
(
    [weight] => 1
    [label] => Position
    [widget_type] => optionwidgets_buttons
    [description] => If you chose "Use text field", you <strong>must</strong> enter the position information in the "Position Text" field.
    [default_value] => Array
        (
            [0] => Array
                (
                    [value] => 
                )

        )

    [widget] => Array
        (
            [type] => options_buttons
            [weight] => 1
            [module] => options
            [active] => 0
            [settings] => Array
                (
                    [default_value_php] => 
                )

        )

    [display] => Array
        (
            [teaser] => Array
                (
                    [label] => above
                    [type] => text_default
                    [settings] => Array
                        (
                        )

                    [weight] => 1
                    [module] => text
                )

            [full] => Array
                (
                    [label] => above
                    [type] => text_default
                    [settings] => Array
                        (
                        )

                    [weight] => 1
                    [module] => text
                )

            [rss] => Array
                (
                    [label] => above
                    [type] => text_default
                    [settings] => Array
                        (
                        )

                    [weight] => 1
                    [module] => text
                )

            [default] => Array
                (
                    [label] => above
                    [type] => text_default
                    [settings] => Array
                        (
                        )

                    [weight] => 1
                    [module] => text
                )

        )

    [settings] => Array
        (
            [text_processing] => 0
            [user_register_form] => 
        )

    [required] => 
)

When I compared these, I noticed that several places that the working list_text field had "list" and "list_default", my broken, migrated field had "text" and "text_default", respectively.

I manually modified this blob and replaced each value of "text" with "list", and each value of "text_default" with "list_default". I then cleared the cache, and reloaded a content node page that uses this field. It worked! I now got the list_text label, instead of the list_text value.

The only remaining issue at this point is that when you edit an old piece of content, it will not have the list_text value preselected to what it was previously. You are forced to make a selection. I believe this is because of the issue described in comment #11. Namely, the migrated data has the list_text label, not the list_text value. This could presumably be cleared up by a few database updates, but I haven't gone down that road yet.

Caution: I have not exhaustively tested this, and don't have enough familiarity with the inner workings of Drupal's new field system to know if this is truly a fix, or is just going to lead to more pain later on.

But I'm posting here in the hopes that someone who does have that domain knowledge will read what I have written and be able to 1) tell me if this is a safe approach and 2) figure out how to fix the CCK migration process so that this whole process isn't necessary!

-Josh

Same thing here. I had paired values, such as:

0|Administration
1|Systems

etc. It was reflecting the right value on the nodes, until I edited them, then there was no values in the dropdown select box. When I reselected them and saved, it was reflecting the key (number) instead of the text value.

I tried to change the values to a single line, so key and value were the same, ie

Administration
Systems

and yes, got the same error message: Allowed values list: some values are being removed while currently in use.

I remembered a trick I did because I had a similar problem with migrating checkboxes that were text, and changed to boolean. So what I did. In this case it was a field called "field_data_field_library_dept" -- Is I went into my phpMyAdmin (or whatever your preferred mysql is) -- and I exported the table. Truncated it, so it still existed, but was now empty. Went back into the field, changed it to single values (ie just 'Administration', not '0|Administration' -- saved it. Re-imported the table. Appears to be working well, and retains the values in the edit form.

I reopened #1351880: List widgets without keys not reflected in field_data_* and field_revision_* tables as I am still getting this issue. Lets set this as a duplicate, and work for a solution there.

After upgrading from Drupal 6 to 7 #15 worked for me but i did not need to change it to a single value.
1. Exported table
2. Cleared table
3. Opened up offending content field and this time i was able to just save, no changes necessary.
4. Re-imported table
5. re-submitted content and no error.

Thanks frogtown for the tips.