Imagine this scenario, you find a really cool snippet of code on one of the many WordPress tutorial sites out there and paste it in your theme’s functions.php file.
The code snippet works as advertised, and you then release your theme for sale on a well-known theme marketplace. Let’s pick a random one out of a hat and go with… ThemeForest.
Suddenly your theme becomes really popular, may be because of the massive list of apparently useful “features” you have listed on your theme’s sales page. With your theme’s success, also comes a number of support queries, mostly to do with plugins breaking while using your theme.
How did this happen, you wonder? Maybe it’s because you blindly pasted random globs of WordPress code into your functions.php file without actually thinking about or anticipating any potential compatibility issues.
A Real Life Example
So, I was trying to find a snippet of code that would pull all the attached images from a post and then display them on that post automatically. I eventually found a piece of code on Stack Overflow, pasted it in my functions file, and it appeared to solve the problem.
The first line of code was the following:
add_filter('the_content', 'strip_shortcodes');Oh well, it worked, I didn’t think anything of it. I later tried to embed a contact form with a shortcode. Surprise, it didn’t work and I spent about an hour trying to figure out why. If I actually read through the code I was pasting, I would’ve known.
This was for a client site, not a released theme, so luckily I didn’t have to deal with a deluge of support queries due to my stupid mistake.
What Commercial Plugin Developers Think
Here’s a quote from Carl Hancock (developer of Gravity Forms) on this very topic:
Supporting the popular Gravity Forms plugin means we see more than our fair share of poorly coded themes. One of the primary support related issues we run into are themes that aren’t developed using best practices, which results in Gravity Forms styling issues and in some cases conflicts that result in Gravity Forms not functioning properly.
The biggest culprit in these situations are themes that include code snippets copy-n-pasted from tutorial sites. Theme developers seem to think that just because the code snippet was on a tutorial site, it must be good. Unfortunately that isn’t always the case and these poor decisions result in headaches and support issues for users.
Want to limit the potential for running into issues with plugins caused by a poorly developed theme? Stick to reputable theme developers such as Press75, iThemes, Headway Themes, Organic Themes, WooThemes, and StudioPress to name a few. Be weary of theme marketplaces where the experience and skill set of the author may be lacking. In most cases you get what you pay for.
Coding Best Practices
A lot of these issues can likely be avoided by following WordPress coding standards. For example, you should be prefixing your function names to avoid any potential conflicts.
In the case of styling issues with Gravity Forms, you may want to avoid certain blanket styles on form and input elements, and instead use WordPress default ID selectors for the bulk of your form stylings.
These includes #searchform, #s, #searchsubmit in the search box. Also #commentform #author, #url, #email, #comment, #submit for the comment form.
Conclusion
If you’re a theme developer, and not too well-versed at PHP, be careful when copying and pasting these code snippets into your theme. Even if you’re not that great at PHP, you can at least read through the code and try to make some sense of it before using it.
Like if you find that your shortcodes aren’t functioning properly, a line of code that mentions “strip_shortcodes” might have something to do with that.
Sometimes I get the feeling that WordPress theme developers just paste random snippets in their functions.php file, just so they can list another “feature” on their theme’s sales pages.
While I’m not a big fan of this sort of idea, it gets into a whole other argument on the role of themes and plugins on WordPress sites, which I’ll save for a future post.
Interesting..I’m a theme developer myself thank you from bringing this to my attention…
I’ve even seen people copy and paste code with copyright notices (asking that the code not be shared!) still intact.
@mkjones – is the problem that the filter was removed, or that its removal wasn’t advertised? I almost always remove the wpautop filter because it automatically destroys perfectly good HTML (of course I tell everyone that it’s gone).
What really irritates me the most is when they paste Jquery (and 20+ other scripts/plugins) directly in the header of their theme or in some hard to find. IS wp_enqueue_script that difficult?
I actually posted a quick example of a Themeforest Jquery Fiasco in my forums if anyone wants to check it out.
Just wanted to add one more thing that may be helpful to some of your readers.
Earlier this month I was helping out a client that purchased a support license for my plugin. The clients theme had around 20 different Jquery plugins loaded into the header.php. Not one of them were using wp_enque_script.
Most of these scripts were only being used for the home page slider and gallery page (that didn’t yet exist.) Since they were getting loaded across the entire site, the scripts were throwing Jquery errors on all of the rest of the pages in the site that had no need for these scripts.
Rather than rewriting the entire header.php and because I didin’t know if any of the scripts may be needed for future pages. I used a few conditional tags to solve the problem. By using conditional tags, I was able to turn off all of the arbitrary scripts, when the site loaded the registration form that was being generated by my plugin.
I actually posted a quick example of a Themeforest Jquery Fiasco in my forums, if anyone wants to check it out.
Sorry Leland, can you remove that first line in my last comment? I thought I removed it before posting.
Thanks!
Oh MAN I hate this. It causes NO end of headaches when customising themes.
I seem to recall the classic:
remove_filter(‘the_content’, ‘wpautop’);
Creeping into one a while ago. Without being properly advertised as a theme ‘feature’ 🙁
I completely agree with you here! I have been down this road and done this mistake myself, only to find myself in trouble later on.
The things you can do with your functions.php are great, but you need to be organized and careful with what you do if you don’t want to spend hours debugging later.
One of the recommandations I would give would be to carefully organize these snippets of code if you want to keep them.
Keep them in separated files, well commented, double test after implementing. In the end, documenting your work always pays off imo.
Couldn’t have said it any better myself. This isn’t just limited to random code snippets found in tutorials around the Web. Theme developers just randomly drop any and all code into functions.php without thinking about — you’d think they’d use a hook once in a while.