Hi there, I have been setting up my first form (really easy, thank you!) and have run into a problem.
The date field is inserted with a very generic “date” CSS class. Formidable’s styling doesn’t seem to require it, but it’s causing the WordPress theme I’m using (Graphene) to display a calendar background image inside the field. Not what I want!
What’s the best solution here? Can I stop Formidable from inserting the “date” class?
September 7, 2012 at 10:50 am
This was added for the jQuery validation script, but we didn't finish implementing it. Can you try commenting out a couple of lines? I don't think those classes are used anywhere, but I'm not positive.
So, please open formidable/classes/controllers/FrmFieldsController.php and go to line 400 and comment out these two lines:
//if(isset($field['input_class']) and !empty($field['input_class']))
// $class .= ' '. $field['input_class'];
We'll do something different so these classes won't be needed. Let us know if you run into any issues with this.
September 7, 2012 at 5:39 pm
Thanks Stephanie. I've commented out those lines, but it didn't seem to change anything at all.
For the sake of the experiment, I tried the following:
//if(isset($field['input_class']) and !empty($field['input_class']))
$class .= ' qwerty'. $field['input_class'];
Theoretically what I should have seen was a new class of "qwertydate". Instead, I got this:
class="date auto_width required qwerty frm_date hasDatepicker"
So it appears that section of code wasn't inserting anything anyway, and the date class was coming from somewhere else. Any thoughts?
September 7, 2012 at 6:07 pm
Ahah! Found it! Replace line 362 with the following...
//$class = $field['type'];
$class = '';
This fix seems to be working fine now, but is it likely to break with the next version upgrade?
September 10, 2012 at 9:24 am
Yep, that's it. Sorry... I didn't check it. We'll change this for the next release to avoid css conflicts like this.
Topic closed.