Make the "Field Key" column more accessible in Webform

Here's a simpler approach to this issue though I'm not sure about adding it to Webform. It certainly crowds up the interface quite a bit, even if it is useful for larger forms.

Hello all,

Tried quicksketch's patch in #2 on webform v6.x-3.17 and it failed.

Hunk #1 FAILED at 78.
Hunk #2 FAILED at 156.
Hunk #3 succeeded at 168 (offset 1 line).
Hunk #4 succeeded at 211 (offset 1 line).
2 out of 4 hunks FAILED -- saving rejects to file webform.components.inc.rej

webform.components.inc.rej is attached if that helps.

Thanks for reading,
-Tim

This would be so handy -- to name and organize field keys better, when labels for similar fields are identical...

While I can see the benefit of this on large forms, I'd have to agree with @quicksketch in that it would add unneeded clutter to the fields interface.

The original post talks about adding field keys to two different locations, and the above patches only add it to the first of these locations. I actually think the second location is far more useful.

Location 1 - The form components list: I agree with quicksketch and fenstrat that this adds clutter, and I'm not clear on the advantage of adding keys here.

Location 2 - The "INCLUDED E-MAIL VALUES" section of the email configuration screen: There is plenty of room here, and showing keys would be a huge benefit. If you use the %email[key] token to include a particular value in an email, you have to dig through several screens to locate the key. Showing the keys here would save me a lot of headache, and would make client training a lot easier.

Has anyone tried ypay's patch? I need this for D7. We are using big forms and the macro module so we really need easy access to the field_keys.

Did a manual patching of this to show field_keys for Webform 4 Beta 3, D7, since the patch was designed for Webform 3. Mine works, but after adding a new field, I get this error:

Notice: Array to string conversion in _webform_components_form_rows() (line 269 of C:\wamp\www\formbuilder\sites\all\modules\webform\includes\webform.components.inc).

It looks like a misalignment whenever I add a new row. I have to reload twice, just to correct itself.

Attached is my copy of webform.component.inc. Pardon me, as I'm not a hardcore Drupal programmer, and I don't know how to write my own patches. I can only assemble modules when available.

Hope this helps somebody.

Notice: Array to string conversion in _webform_components_form_rows() (line 269 of C:\wamp\www\formbuilder\sites\all\modules\webform\includes\webform.components.inc).

That's a bug in RC1, it's been fixed in #2242011: Add new component field disappears when you add one component.

Still not sure about this patch overall. What I'd like to see is the token browser showing context-sensitive tokens, so you wouldn't need to look up keys at all in the first place, though that's quite a bit trickier.

I read through the patch and the code it was trying to correct, and made a slight adjustment to it. Instead of correcting all 4 chunks, I took the last instruction, and simply appended the title of the component to add the field key. That way, it doesn't break the listing as opposed to the patch.

Anyway, I believe this should be included as an adjustment to the next versions, especially since--like in my case--there are scenarios wherein you have to deal with 500+ webform items and you need to standardize all of the field keys. Looking at the variables at a glance would surely help, especially if you need to review the structure of the field keys.

I think a better solution would be to add the components to the views support so that you can display a list of components with their form keys. You could keep this open in another window for reference. That way we don't clutter up the interface for the vast majority of users that don't need this detail.

Also, all new features would go into 7.x-4.x.

EDIT: I looked at adding the tokens to the token browser, and that is just not the way the token module was designed. It collects all possible tokens and then presents those that were asked for. The webform value tokens depend upon the context of the webform node. This would require a re-write of the token module.

It would be great to be able to edit labels and field keys right from the Components page itself (then have a save button at the bottom).

For me, I'm finding that I like to clone multiple fields, but have to go in and edit each one to change the label and field key slightly (because I reference my fields in emails, etc.).

The ability to make multiple changes at once would be a huge efficiency gain, at least for me.

Just wanted to add my opinion. Maybe it's an idea for a future Webform version.

Since this is "closed / wont' fix" is there another solution out there for doing this? It would save a lot of time for those of us who need to map complex webforms to PDFs using FILLPDF for example.

Re #19, at this point, I don't know what "this" is that you want. It seems several things have been discussed in this issue. You might open a fresh issue.

BTW, the token API is incapable of displaying the field keys, as suggested by quicksketch. I looked into it. They token help is not intended for context-dependent tokens.

Thanks. By "this" i meant: "add another column in the Form components list screen that shows the 'field key' for each component?" as stated by original poster.

I have two concerns:

1. It complicated the display of the components, presenting data that most users don't need to reference.
2. Some users with small or portrait screen have displays <= 1024. At that resolution, the current columns work, but they wouldn't if we added another. See http://www.hobo-web.co.uk/best-screen-size/

One thought would be to expose component definition (schema) data to views, so that a "report" of the components could be displayed. The hierarchical nature of the components with fieldsets and pages will make this somewhat difficult.

Another would be to add something that you could hover over to see the field key. For example, we could add a vestigial url query paramater, such as '&field_key=your_field_key_here' to the end of the edit/clone/delete links.

And another would be to add a span element with a title showing the field_key. I understand that this doesn't work in all browsers.

I'm not super happy with any of the three ideas above. Discussion?

I'm someone who would like to see the field_key on the form components page as well. It's not something that I'd say is needed, but it would definitely help me out a lot with my forms and would speed things up quite a bit.

I'm a bit surprised that another column couldn't be added to the table. On my end, there is a lot of space between the "Label", "Type" and "Value" columns. If needed, could the "Label" column be set to only display a certain number of characters (so that longer labels don't mess up the table if another column was added)?

If the "Form Components" page was a View, it would enable users to add or remove columns as they like. I don't know if this is possible though.

For me, the whole "Form Components" page would work better if the entries were editable from the table itself. I know this is asking a lot, but since the "Required" box can be edited from this page, why can't the other fields be set up this way as well? It would be great to edit labels or default values without leaving this page. Just my two cents and I don't know anything about the back end or whether this is a completely ridiculous idea. Apologies if it is!

I'm a bit surprised that another column couldn't be added to the table.

It can be -- as in programmatically possible -- but set your window width to 1024 (or 900) and see what the table looks like. Now consider that some field_keys and some labels are very long. It's not very pretty.

Compromise made. I added the column for field_key, but now supply default css that limits the field key and value columns to a max with of 7 em. Obviously this can be customized further in a theme.

Further, field keys are trimmed to 30 characters like values are. In addition, if trimmed, I supply the whole untruncated data as a HTML title on the cell.

Only took 4 years....

Committed to 7.x-4.x.

Needs up-port to D8.

This broke compatibility with CiviCRM Integration. See #2600878: Incompatibility with Webform -7.x-4.12?.

Whilst I can see the potential value of having this data available from the component listing, it has immediately doubled the page length of those listing pages, slowing my workflow and increasing the amount of scrolling Ihave to do to find the component I'm working on. :-(

Ideal solution would be to have a switchable setting for the display of this column in webform settings.

@upperholme -- Depends upon theme. You you use an admin theme for content editing that is fluid, you can use the entire window (or monitor if you zoom the window), width, avoiding any wordwrapping and extra length. You could also theme the page to hide the column or make it very narrow.

Appreciate all the work on this, but trimming the field length with php results in an inability select and copy it to the clipboard, which I think was the main purpose of this issue :(

A better alternative would be to use the css overflow property. CSS is, in general, a better choice for responsive design than php.

.webform-component-formkey, .webform-component-value {
    max-width: 7em;
    white-space: nowrap;
    overflow: hidden;
    text-overflow: ellipsis;
}

Happy to roll a patch for this plus the removal of the server-side trim.

@colemanw -- I hadn't thought about copy-and-paste. You can't copy out of the pop-up title. I'm not totally sure what's best here. Limiting it strictly to one line means that you can't scan the column for the form_key that you want as easily if distinguishing characters are wrapped. Currently 18-ish characters fit on a line, so the truncation to 35 characters limits it to about 3 lines.

I didn't think that copy-and-paste was the main purpose, but I could be wrong. I was more thinking that you would scan the list as a reference (what's that component whose key is my_stupid_long_key?). But you may well be right that it is used the other way (what's the form key for this component that I know is the one I want?).

Given that we've just released this (pity), I would support a change to remove the truncation at least for form_key and rely on CSS. I guess we could do the same for the default value, but the use case is different. I doubt you ever want to copy-and-paste it. It does seem like we should be consistent, no?

Marking this active pending further discussion and/or an additional patch.

And ... back to 7.x.

Funny, I hadn't thought of line wrapping. I've never seen the lines wrap before, but just now I was able to make my admin theme (Seven) wrap the keys to two lines by making the window as narrow as it would go. Maybe with an even narrower theme they would wrap to three?

CSS-based line-wrapping + ellipsis overflow seems like it would be difficult to implement, but I wonder if that isn't overcomplicating matters. This screen is only ever seen by site admins (and the cool kids won't see it at all because they're using form_builder_webform) and a single-line with ellipsis looks great on just about every device.

In 7.x-4.12, the form components listing page calls this the "Form key" instead of "Field key" used on the component edit page. I have created an issue about standardizing the names: #2644830: Standardize name for "Form key" / "Field key".

If there are elements nested inside fieldsets or grids, particularly multiple levels, it would be helpful if there was an easy way to copy-to-clipboard the entire set of field keys needed to access the field in a token, e.g. "fieldset-key:component-key".

If you don't mind the form key sharing the 'Label' column, this can be done pretty easily in a custom module with hook_form_FORM_ID_alter():

/**
 * Implements hook_form_FORM_ID_alter.
 */
function mymodule_form_webform_components_form_alter(&$form, &$form_state, $form_id) {
    $components = $form['#node']->webform['components'];
    foreach($components as $cid => $component) {
        $component['name'] = $component['name'] . ' (' . $component['form_key'] . ')';
        $form['#node']->webform['components'][$cid] = $component;
    }
}

The Label now appears as "First Name (first_name)".

I don't see putting this is webform itself, and as per #32, it can easily be done in a custom module.

Sorry, I realized after the fact that my proposed solution in #32 has the unintended side effect of permanently storing the altered 'name' string in the webform_component table if you submit the `webform_components_form` form (for example, after rearranging or changing a component's required status.) I assume it's using a hidden value somewhere that is derived from the altered component name.