Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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?
Comment | File | Size | Author |
---|---|---|---|
#36 | webform_name_length-342722.patch | 1.39 KB | quicksketch |
#2 | webform_components.patch | 636 bytes | robertgarrigos |
#2 | webform_install.patch | 482 bytes | robertgarrigos |
Comments
Comment #1
armyofda12mnkeys CreditAttribution: armyofda12mnkeys commentedgonna 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,
);
Comment #2
robertgarrigos CreditAttribution: robertgarrigos commentedI created the patches for those changes. It seems to work for me.
Comment #3
robertgarrigos CreditAttribution: robertgarrigos commentedforgot to change the status
Comment #4
robertgarrigos CreditAttribution: robertgarrigos commentedComment #5
robertgarrigos CreditAttribution: robertgarrigos commentedIn fact, the .install file should be patched with this patch. This one has the update hook which I forgot before.
Comment #6
quicksketchThis 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.
Comment #7
micmuir CreditAttribution: micmuir commentedsubscribing - option for longer questions would be really useful.
Comment #8
arx-e CreditAttribution: arx-e commentedsubscribing - I have bumped into this problem, too
Wouldn't it be better to change only #maxlength and set it to something higher?
Comment #9
quicksketchThat'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.
Comment #10
cwithout CreditAttribution: cwithout commentedsubscribing. having same issue
Comment #11
phoenix CreditAttribution: phoenix commentedHaving 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.
Comment #12
jonskulski CreditAttribution: jonskulski commentedThirding the change in the database + removal of maxlength.
Comment #13
mariomaric CreditAttribution: mariomaric commented+1 from me too.
Comment #14
canucked CreditAttribution: canucked commentedObviously 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.
Comment #15
wrightnow CreditAttribution: wrightnow commented@quicksketch & #6
Nothing drastic to add here, though we have several use-cases that benefit from an increased limit.
Comment #16
quicksketchIf 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.
Comment #17
sharplesa CreditAttribution: sharplesa commentedI 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:
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!
#maxlength
attribute to the definition of the form's add/name field as shown below:webform_component
table:ALTER TABLE webform_component CHANGE name name text;
Comment #18
DrupalDan CreditAttribution: DrupalDan commentedHi,
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!
Comment #19
quicksketchComment #20
chaloum CreditAttribution: chaloum commentedThe 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.
Comment #21
ChuckZ CreditAttribution: ChuckZ commentedLike 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.
Comment #22
ChuckZ CreditAttribution: ChuckZ commentedActually, I thought up an easier
hacksolution that does not require webform module changes.Assuming you have a module, you need to put something like this in your hook_form_alter:
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.
Comment #23
Simon Georges CreditAttribution: Simon Georges commentedFor those looking for this, a patch for the 4.x-alpha6 version of Webform.
Comment #24
quicksketchThanks! This should have been marked needs review. I'll give this a look next time I'm going through the queue.
Comment #25
maritimefist CreditAttribution: maritimefist commentedThe patch #23 seems to fail for 4.x-alpha10. Bummer.
Comment #26
quicksketchHm, 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.
Comment #27
thekevinday CreditAttribution: thekevinday commentedThen 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.
Comment #28
quicksketchHi @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).
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.
Hm, probably, but considering form_key and type should also be not null, maybe it's not worth changing at this time.
Comment #29
thekevinday CreditAttribution: thekevinday commentedThe 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.
Comment #30
quicksketchThanks @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.
Comment #31
quicksketchComment #32
pauln60 CreditAttribution: pauln60 commentedWow, 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.
Comment #33
quicksketchI'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.
Comment #34
pauln60 CreditAttribution: pauln60 commentedWell, 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.
Comment #35
quicksketch@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.
Comment #36
quicksketchHere's a patch that removes this limitation. With so little change, I've gone ahead and committed it to 7.x-4.x.
Comment #38
fenstratNeeds porting to 8.x-4.x.
Comment #39
fenstratCommitted and pushed 324e5ab to 8.x-4.x. Thanks!
Comment #42
jsheffers CreditAttribution: jsheffers commentedCreating a separate issue since it's a related bug that's actually causing the issue.
Comment #43
colinstillwell CreditAttribution: colinstillwell commentedI have found a bug with this patch, please see https://www.drupal.org/node/2462801