Some of my questions in my webform are over 255 chars which I think the database re-enforces for the label (as well as the label's html field restricts the size as well) ...
Anyway to easily make this bigger for more longer questions?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

armyofda12mnkeys’s picture

gonna guess change db field to TEXT type (with maybe a larger restriction on size) and change maxlength here:
$form['name'] = array(
'#type' => 'textfield',
'#default_value' => $component['name'],
'#title' => t("Label"),
'#description' => t('This is used as a descriptive label when displaying this form element.'),
'#required' => TRUE,
'#weight' => -2,
'#maxlength' => 255,
);

robertgarrigos’s picture

FileSize
482 bytes
636 bytes

I created the patches for those changes. It seems to work for me.

robertgarrigos’s picture

Status: Active » Needs review

forgot to change the status

robertgarrigos’s picture

Version: 6.x-2.1.3 » 6.x-2.6
robertgarrigos’s picture

FileSize
869 bytes

In fact, the .install file should be patched with this patch. This one has the update hook which I forgot before.

quicksketch’s picture

Version: 6.x-2.6 » 6.x-3.x-dev

This issue has been open for a really long time because I'm not sure how I feel about it. I definitely don't want to turn the label field into a textarea, that's taking a hammer to a screw. I might be willing to extend the "name" column in the database to a "text" column and remove the #maxlength property (essentially allowing really long labels), but the field in the UI should remain a textfield. It's interesting to note however that nodes and fields are limited to 255 characters right now also, indicating that this entire situation is a bit of an edge case. Not to mention in the 18 months this issue has been open (and the 4 years of Webform's existence), only two people (here in this issue) have reported it being a problem.

micmuir’s picture

subscribing - option for longer questions would be really useful.

arx-e’s picture

subscribing - I have bumped into this problem, too

Wouldn't it be better to change only #maxlength and set it to something higher?

quicksketch’s picture

That's what I've suggested (rather than using a textarea), but the database also needs to be updated to allow for text strings instead of varchars with the 255 character limit.

cwithout’s picture

subscribing. having same issue

phoenix’s picture

Having the same problem. It would be good to allow longer labels.
I'm also pro quicksketch's solution to make maxlength variable and update the field on the db to a long text field instead of varchar 255.

jonskulski’s picture

Thirding the change in the database + removal of maxlength.

mariomaric’s picture

+1 from me too.

canucked’s picture

Obviously with D7 release around the corner it may be a bad time for a change like this.

Would it make more sense to make the fields like...
1) Label
2) Description (new column of type "text")
3) Default Value
4) Help text (a new name for the old description field)

Then give the option on the field to display the label or not.

wrightnow’s picture

@quicksketch & #6

Nothing drastic to add here, though we have several use-cases that benefit from an increased limit.

quicksketch’s picture

Status: Needs review » Active

If someone would like to submit D6/7 patches with an update function for both and setting a high max limit (like 1024) I'll take a look at this. Moving back to active as the current patches are not usable.

sharplesa’s picture

I was in the process of figuring out how to do this when a work-around was found, so I don't have to create the patch. Below I show the (codeless) work-around as well as the specific things that patch would need to do if you don't like the work-around.

The workaround

If you have really long questions, you can put each question into a fieldset and then use the fieldset description to hold the lengthy question. Each fieldset would contain only one question. Here's the process:

  1. Create a new webform (node/add/webform) and specify a title.
  2. On the "Webform"/"Form components" tab, create a new component with the label "Question 1" and type "Fieldset". Click "Add". This will take you to the "Edit component" page for "Question 1".
  3. Use the "Description" area to state your question. You can even use HTML.
  4. Accept the default fieldset settings and click "Save component".
  5. Create a new component with label '1' and type 'Textfield' (or whatever). Click "Add", which will take you to this question's "Edit component" page.
  6. Edit the component as usual. Click "Save component".
  7. Back on the Webform page, drag the position icon for '1' to the right until the '1' is indented under 'Question 1'.
  8. Click "Save", otherwise your change won't stick.

The result of this work-around example is shown in the attached screen shot.

What the patch needs to do

If you don't want to use the work-around, this would be a very easy patch to create, so if you're new to Drupal development, give it a try!

  1. Modify the file sites/all/modules/webform/includes/webform.components.inc, adding a #maxlength attribute to the definition of the form's add/name field as shown below:
    
      $form['add']['name'] = array(
        '#type' => 'textfield',
        '#size' => 24,
        '#maxlength' => 512, // or whatever you want that max length to be.
      );
    
  2. Modify the table definition of the webform_component table:
    ALTER TABLE webform_component CHANGE name name text;
DrupalDan’s picture

Version: 6.x-3.x-dev » 7.x-3.17
Category: feature » support

Hi,

Can you please tell me how to do this when it comes to port 7? I already modified the file as posted, and I made the change to the database by changing the length/values of the Column "name" to 512, too. But I can't enter more characters in the label 'title' fields.

I tried to remove the maxlength and make the change in the database so that the type of name is now set to "text", but it doesn't seem to work, either.

I'm completely lost. Can anyone tell me where I went wrong?

Thanks in advance!

quicksketch’s picture

Category: support » feature
chaloum’s picture

The limitation for the questions is the biggest limitation to webforms. It's not just the length but that there can't be any markup which limits the us, there is no way to use this for asking question that may require images in the question like which electrical diragran is correct or which formula does this.

I've been using the discription to get around this by splitting a part of the question in the label and the rest in the discription but it's painful as there is no wysiwyg editor on that field and make the prodded labourious and something you can give a client.

The way in which options in the responses area work is also limited

It's a shame as the product is very good is other respects. But the reality is questions aren't just simple one liners.

ChuckZ’s picture

Like others, I have a need for something like this feature. My clients are university research MDs and PhDs who want me to support surveys for them. I am not the experts on surveys. They are. So I don't want to (and should not be) telling them to change their surveys.

I have tried various hooks to get what I need without modifying the core module code. But they are all too complicated. I am going to have to modify the module code.

Alternate Proposal - Preamble Fields
I will add a new field per each survey question which I will call #preamble. It will be similar to the #description field, but it will be placed before the question (#title) and use the same formatting style as the question. It will also allow for full HTML so I can do things like show diagrams and bulleted lists. Because the field will not be cleaned up (allow raw HTML) its use should be only available for sites with trusted users.

I'll let you know how it goes.

ChuckZ’s picture

Actually, I thought up an easier hack solution that does not require webform module changes.
Assuming you have a module, you need to put something like this in your hook_form_alter:

function mymodule_form_alter(&$form, &$form_state, $form_id) {
  $form_prefix = substr($form_id, 0, 20);
  if ($form_prefix === 'webform_client_form_') {
    foreach ($form_state['webform']['component_tree']['children'] as $child) {
      $form['submitted'][$child['form_key']]['#title'] = $child['extra']['description'] . '<br>' . $child['name'];
      $form['submitted'][$child['form_key']]['#description'] = '';
    }
  }
}

Now your question gets prefixed with whatever you used for your description. Both are unfiltered versions of your question so you can put in whatever HTML you want (you better trust your survey authors). Both get the same CSS style as the question itself. It is a brute-force approach that solves most of my customer's needs.

Simon Georges’s picture

For those looking for this, a patch for the 4.x-alpha6 version of Webform.

quicksketch’s picture

Status: Active » Needs review

Thanks! This should have been marked needs review. I'll give this a look next time I'm going through the queue.

maritimefist’s picture

The patch #23 seems to fail for 4.x-alpha10. Bummer.

quicksketch’s picture

Status: Needs review » Needs work

Hm, actually looking at this patch this is quite a bit more obtrusive than what I had planned. All that needs to be done here is extend the length of the name column in the database and remove the length restriction on the form. We don't need to add another field. Webform already allows certain HTML tag in its labels via the webform_allowed_tags variable.

thekevinday’s picture

Version: 7.x-3.17 » 7.x-4.x-dev
FileSize
2.35 KB

Then lets get this moving in the preferred direction.

The issue was originally for 7.x-3.x, but I see later talks about 7.x-4.x, so I will assume that this should be set to 7.x-4.x-dev?
Please put back if I am wrong.

The solution as mentioned in #26 is just to change it to allow for long text.

The attached patch does the following:
- Changes the 'name' 'textfield' to a 'textarea'.
- Changes the schema type for 'name' from 'varchar' to 'text'.
- Provides a an update function that migrates the data over.

Now, this patch needs more work to be considered complete:
1) It should be in a batch, but I do not know enough about the update batch jobs.
- Do batches conflict with transactions? I prefer to wrap the schema in a transaction so that it can rollback on errors, thus preserving data.
2) Should the 'textarea' have 'not null' = TRUE?

So, this patch really needs work to be committed, but it should give you something to play with and get some testing/reviewing done.

quicksketch’s picture

Hi @thekevinday, thanks for the new patch. As I mentioned above, I don't want to change the label field into a textarea. It should remain a textfield, but with a longer maxlength (or maybe explicitly set to NULL).

1) It should be in a batch, but I do not know enough about the update batch jobs.

I think you can just use db_change_field() here rather than manually doing the work of converting the data. Internally each database system will do pretty much the same thing you've done here, only in single queries instead of looping through each row.

2) Should the 'textarea' have 'not null' = TRUE?

Hm, probably, but considering form_key and type should also be not null, maybe it's not worth changing at this time.

thekevinday’s picture

Status: Needs work » Needs review
FileSize
4.9 KB

The simple approach as done by the patch in #27 had way too many problems because of the way labels were being used everywhere.
(Especially with download as csv).

The patch from #23 seems to be the best solution.

So, I remade the patch from #23, with some minor changes.
Please review.

quicksketch’s picture

Thanks @thekevinday for the updated patch. I know that using a single field means we'll need to do extra work in places (the CSV example is a good one), but I think that's preferable to adding two fields for label on every component. That's introducing an advanced option on every component that probably won't be used 90%+ of the time. It'd be preferable to me to just have HTML supported in the labels and strip out the markup in places where we have plain-text. That adds support for the option for users who need it without adding an additional field for all the users who wouldn't even know what it was for.

quicksketch’s picture

Status: Needs review » Needs work
pauln60’s picture

Issue summary: View changes

Wow, this issue has been kicked around for an awfully long time. Any prospect of a fix finding its way into a release anytime soon?

P.N.

quicksketch’s picture

I'm still totally open to including this, but the current patches need work. We recently did almost the exact change over in #1736982: Increase redirect_url length; that could easily be adapted to work on the name column of the webform_component table. Although it used a 2048 varchar field instead of text. My understanding is that a varchar over 255 characters in MySQL basically is stored the same way as text. I don't really have a preference on text vs. long varchar.

pauln60’s picture

Well, with all due respect, at this point wouldn't it be best to choose a solution (e.g., #29) and go with it, rather than having the problem perpetually unresolved? It's starting to look like a permanent limitation of the module, which is really too bad, as it's pretty significant.

P.N.

quicksketch’s picture

@pauln60: I don't think it'd be a good idea to implement a solution that causes unnecessary complexity for 90% of the use-cases, as I wrote in #30. The approach I'm recommending is simpler and easier to implement, it just hasn't been done yet without over-complicating things. I've had the same complaint with every patch submitted since 2010. This is a super-minor problem to fix. However, no submitted patch seems to be able to implement this ridiculously simple adjustment:

- Set #maxlength = NULL.
- Change the schema to be a text column.
- Add an update hook to convert to a text column.
- Do NOT make a new textarea or make the title field a textarea.

I've been saying the same thing since 4 years ago. This hasn't been a high priority for me, but I've been willing to make these changes as long as a patch is submitted that does exactly this.

quicksketch’s picture

Here's a patch that removes this limitation. With so little change, I've gone ahead and committed it to 7.x-4.x.

  • Commit 324e5ab on 7.x-4.x by quicksketch:
    Issue #342722: Increase length of the name column to allow for longer...
fenstrat’s picture

Version: 7.x-4.x-dev » 8.x-4.x-dev
Assigned: Unassigned » fenstrat
Status: Fixed » Patch (to be ported)

Needs porting to 8.x-4.x.

fenstrat’s picture

Version: 8.x-4.x-dev » 7.x-4.x-dev
Assigned: fenstrat » Unassigned
Status: Patch (to be ported) » Fixed

Committed and pushed 324e5ab to 8.x-4.x. Thanks!

  • Commit ad81cec on 8.x-4.x by fenstrat:
    Issue #342722 by quicksketch, robertgarrigos, thekevinday, Simon Georges...

Status: Fixed » Closed (fixed)

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

jsheffers’s picture

Creating a separate issue since it's a related bug that's actually causing the issue.

colinstillwell’s picture

I have found a bug with this patch, please see https://www.drupal.org/node/2462801