Two dealbreakers that prevent me from using GF exclusively for my forms and instead forcing me to use paid version of Contact Form 7:
The inability to remove the entire word “Required” on required fields. We don’t want this, or at least want the option to remove it without having to create a child theme and adding code to the functions.php. The reason we don’t want it is simple: It extends the length of the field name, which causes the text top drop to a second line, which pushes the form field down, which screws up the design. An asterisk would be better, the ability to change required field labels to a custom color would be just as good of an option. Adding 8 characters to a text string just doesn’t work for us.
The inability to stack fields and call them only when needed, making them hidden otherwise. For example, let’s say I’m running a travel agency. On the first line, I have 4 text fields across but only the first 3 fields show by default b/c the 4th depends on the selection from one of the first 3 fields. Field 3 asks “What store do you use?” and, based on their selection, field 4 appears showing a Group 1 Travel Date. That’s possible if there’s only 1 travel group, but when there’s more than 1, GF doesn’t allow us to stack fields so that the Group X Travel Dates appear in that same location regardless of what store/travel group they select. With GF’s current abilities, we’d have to do this on a whole other line.
CF7 Pro does this. Caldera used to have this feature, too. It would be nice if GF could add this in a future update.
Hi ppe29. The Required field indicator can be configured on the Form Settings of every form, and there is a filter if you want to remove it completely or otherwise modify it:
The best way to get additional feedback to the product development team is to submit it to them via our product roadmap. Click the blue plus in the lower left on this page to add a note for our product team:
With respect, this is exactly what I said is the case when I said the only way to remove or change the required text (assuming a required field is needed) is to go into the functions.php of a child theme.
So, in other words, the ONLY reason I would need to go through the extra step of creating a child theme is to be able to remove that text, b/c the limitations of Gravity Forms to handle this on the front-end is the only reason I ever need to create a child theme. Maybe others need to create child themes for more complex websites, but that’s not the case for everyone. It would be much more efficient if Gravity Forms could handle this on the front end admin side rather than forcing us to create child themes simply to remove unwanted text.
And let’s look at the suggested code we need to add to a child theme’s functions.php: add_filter( ‘gform_required_legend’, ‘your_function_name’, 10, 2 );… So now we need to create functions to call out, too? Am I understanding that correctly? Hard to tell b/c the reference you provided provides absolutely no explanation of that or where to place it in the functions.php file… top, bottom, middle… specificity is very helpful.
So, the fact remains that this inability to remove that text without all of this craziness is one of two dealbreakers as to why I can’t use GF exclusively for my form needs.
#%@^!!! I just found this and came back here to say I was wrong and he was right, but you beat me to it. Thanks for helping out with that, both Chris and Phil.
Do you know of any solutions for my other issue? The one about being able to stack multiple fields in the same section and only appearing based on conditional logic selections?
For the record, I’m very familiar with conditional logic, so knowing how that works isn’t the issue. This is just about, for example, having 4 fields across one line and being able to put multiple fields in slot 4 that only appear based on conditional logic choices made in fields 1-3.
Regarding conditional logic and columns, note that when a field is hidden by conditional logic, other fields being displayed will fall back into the previous row to take up that space – provided their columnar width does not exceed the space needing filled. The front-end display will not be precisely reflect in the editor, but the fields will behave as expected. You’ll want to ensure that each field which should drop back to that fourth column has been resized to a width that is small enough to drop back. If you encounter any issues putting something like that in place, drop a link to a form on which you have this setup and I can look more directly to what may be needed.
