Problem/Motivation

Devel generate fails when generating data for a field that satisfies the following conditions:

  • the field is of type text
  • the field uses a widget other than text_textfield but still has a max_length (ex. the widgets provided by html5_tools like urlwidget or emailwidget)

In this case you will see a PDO exception like this:
PDOException: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'field_url_value' at row 1: .... because generate is assuming this field is a textarea can can handle lots and lots of text even though (in reality) it should max out at 255.

Proposed resolution

There are a couple choices here on how to solve this:

  • OPTION A

    First check if the widget's module provides a $module.devel_generate.inc file before using the one provided by the field's module.
    Currently line 41 of devel_geenrate_fields.inc is
    $module = $field_types[$field['type']]['module'];
    this would need to change to first look if there is a devel_generate.inc file $instance['widget']['module'] and if it doesnt exist then use $field_types[$field['type']]['module'] instead. This option would give hml5_tools (and other modules) the opportunity to create its own devel_generate file.

  • OPTION B

    Be more specific when checking if we are generating content for a textarea or a single-line input field. Currently we have this in _text_devel_generate():

      if ($instance['widget']['type'] != 'text_textfield') {
        // Textarea handling
        $object_field['value'] = devel_create_content($format);
        if ($instance['widget']['type'] == 'text_textarea_with_summary' && !empty($instance['display_summary'])) {
          $object_field['summary'] = devel_create_content($format);
        }
      }
      else {
        // Textfield handling.
        // Generate a value that respects max_length.
        if (empty($field['settings']['max_length'])) {
          $field['settings']['max_length'] = 12;
        }
        $object_field['value'] = user_password($field['settings']['max_length']);
      }
    

    The opening of the if statement is too general. if ($instance['widget']['type'] != 'text_textfield') is TRUE for urlwidget (etc...) but we want it to be FALSE. We could change that line to if ($instance['widget']['type'] == 'text_textarea_with_summary' || $instance['widget']['type'] == 'text_textarea){ but I fear that would be too specific for any module that creates a widget for textareas...

  • OPTION C

    This may be the best option but I cannot remember if max_length will *always* be set for "textfield" style widgets. If that is true then we can simply change this:
    if ($instance['widget']['type'] != 'text_textfield')
    to
    if ($instance['widget']['type'] != 'text_textfield' && empty($field['settings']['max_length']))
    and we're all set.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

kalabro’s picture

Status: Active » Needs review
FileSize
1.22 KB

Only core field type text has DB limitation by "max_length". So "max_length" check is more appropriate than widget type check. I prepared a patch for review.

Idea to allow widget providers implement their hook_devel_generate is also cool!

kalabro’s picture

Issue summary: View changes

adding option C

bleen’s picture

Just to be clear ... $field['settings']['max_length'] will always be set (and non-zero) for all fields that use a textfield? If that is correct, then this patch looks good to me.

kalabro’s picture

I can only say that $field['settings']['max_length'] will always be set (and non-zero) for all fields of type text.
And for any other contrib fields which has 'max_length' setting.
Widget (text_textfield, telwidget, urlwidget or any other) doesn't matter.

bleen’s picture

Status: Needs review » Reviewed & tested by the community

thats fair ... lets do it

moshe weitzman’s picture

Status: Reviewed & tested by the community » Postponed (maintainer needs more info)

Not sure about this. The current code gives a bunch of paragraphs for textareas and it looks like this patch will change that to a greeking which we currently only do for textfields. Please clarify if we get paragraphs on textareas after this patch.

kalabro’s picture

I confirm that everything OK with textarea, textarea with summary and HTML5 Tools. See screenshots.

But we see that Email widget really needs own devel_generate implementation.

moshe weitzman’s picture

Status: Postponed (maintainer needs more info) » Fixed

Committed to 8.x and 7.x. Thanks.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

Updated issue summary. Fixing mis-named poperty