WordPress, I will own you.  One day not far from now, I will bend your CSS, PHP, and plugins to my will.  Until then, I will tweak, use classes and ids, and read the codex as needed.

If it feels like a hack, and looks like a hack, it probably is.  I’m still trying to figure out when not being a hack outweighs getting stuff to work.  At this point, I am working on custom styles for one form on the site.  Create a short contact form that emails the input to two email addresses. Custom styling and text necessary.  Sounds easy enough.  I’ve created forms that wrote data to files and databases – this should be an a breeze. And the custom styling will add a nice creative touch, right?

If at first…
The first problem I run into is that the page the form is destined for shares a template with multiple other pages.  Therefore, I cannot go in and just add/change ids and classes willy nilly to the html.  Oh, no.  Plus, the contact form is created in something called “short code” in the Word Press editor, so some sneaky stuff is presumably going on behind the scenes.  Why did I bother learning “real” code when I could have just used “short code” the whole time?  Yes, that was sarcasm.

I did figure out how to change the “short code” so that it sends to multiple email addresses, so that was a big win there.  However, without disabling the CSS for ALL forms on the site, I was still stuck about how to change the CSS on just this one form.  Soooo, I used “inspect element” and went rogue.

Going Rogue
So, I go to the form (default styling) and inspect the element, finding that the form for the page has a unique id that is always the same, even when I delete and re-add the form.  Interesting. So one possibility is to override all the Jetpack form CSS with custom CSS related to #contact-form-7234. However, that feels weird, jenky, and hack-y to me.  Why should this tiny form load fifty million redundant styles?

Next up, let’s bypass the plugin and make our own gosh darn form.  That would be impressive and fun. The only issue with adding my own form “by hand” (as opposed to using the plugin’s custom contact form) is that it may no longer be filtered through “askimet” in which case we might open ourselves up to all sorts of naughty spam (no pun intended). Not to mention that I would have to create a whole new template.  Better safe than sorry, so we should stick with the “short code” provided by the plugin.  However, this means that all classes and ids (and associated CSS) will remain unaltered, which brings us back to square one.  This is starting to feel like a lot of work for one teeny tiny four-field form.

Saved By The Troll
So, back to using Jetpack’s form and simply changing the CSS.  But this time, change the custom CSS to all .contact-form items.  But what about all the other forms on the site?  Won’t they get wonky?  The good news here is that the other forms are email and comment forms, which are completely different in Word Press World than contact forms.  Upon more element inspection, the Jetpack contact form uses something named grunion.css.  Whoa.  Did the Fremont Troll used to work for Automattic?  And write a lot of style sheets?  Who else would be named “Grunion”?

By inserting some quick code into functions.php (finally found the right one – under “includes” in the specific theme folder), grunion.css met his untimely demise.  There were still some default styles being applied to the form, but I could re-write .contact-form as I saw fit, making for less redundant styling and form styles that are applicable to all the Jetpack contact forms of the future.

And with a quick plugin update, I was able to change the text in the submit button.  Viola!

The moral of the story?  It’s good to explore your options, but sometimes you just have to take the troll out of the way.