Closed (fixed)
Project:
Webform
Version:
7.x-4.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
26 Jun 2013 at 21:34 UTC
Updated:
12 Sep 2014 at 21:20 UTC
Jump to comment: Most recent, Most recent file

Comments
Comment #1
hass commentedComment #2
hass commentedComment #3
quicksketchThanks, yeah this element is kind of weird. It's not really worth making a real element via hook_element_info(), but it in itself is not an element by itself. Maybe we just make up a #type name? That seems like it might cause other problems. Maybe just setting #type = NULL would be the easiest fix, at least it would eliminate notices if checking #type.
Comment #4
hass commentedNo, we need to set a proper
#type. For being able to inject classes via preprocess functions to the fields I need to know what form field type this is. At least this is the only reliable context that I have for adding classes to form fields.e.g.
#type = webform_file_extensionsComment #5
hass commentedA code example may be of interest. Same type of code exist for core theme_form_element and tons of other form theme functions.
Comment #6
sonicthoughts commented+1 for this error with artisteer generated theme.
Comment #6.0
sonicthoughts commenteda
Comment #7
danchadwick commentedI am going to close this for lack of activity. If there is still an issue with file components not having a #type, then please post a patch that you would like to see committed. Otherwise, I suggest you use isset to test before accessing it.
Comment #8
hass commentedThe bug seems not fixed and every element need to have a type with no exception.
Comment #9
danchadwick commentedSee #3. Quicksketch is aware of this and won't be changing the design. Your isset workaround will have to do.
Comment #10
hass commentedNope, the bug need to be fixed in the module.
Comment #11
danchadwick commentedPatches welcome.
Comment #12
hass commentedComment #14
danchadwick commentedCommitted to 7.x-4.x and 8.x.