When it comes to your WordPress site, updates are one of the single most important aspects of the site to ensure it continues to operate smoothly and that it is not vulnerable to security flaws. This is a small code snippet that completely disables all update checks:
I have seen a lot of ways to load custom versions of jQuery, but this is probably the most “robust”, though I don’t mean that in a good way.
WordPress makes it really easy to load jQuery by simply doing:
wp_enqueue_script( 'jquery' )
Some developers believe it is better to force WordPress to use other versions of jQuery from google (or elsewhere). This is a practice I strongly disagree with. You can read about why I feel this practice is really irresponsible on Pippin’s Plugins.
Anyhow this particular developer went really far and decided to build an overly complex system for loading a custom version of jQuery, and all for a really simple tabs / accordion plugin. Here it is:
Now, I really do not like talking badly of others, so please note that I am NOT criticizing this developer personally. It is very likely that this was developed due to his or her own experiences and frustrations with the all-to-common jQuery conflict. I’m posting this not as a insult to whoever wrote this, but as an example of why theme and plugin developers should almost never load their own jQuery. The practice of loading jQuery from Google has resulted in developers needing to find elaborate solutions like this, when really it’s way simpler: if everyone did it correctly by just allowing WordPress to handle the version of jQuery loaded, we’d never have these problems.
Submitted by Josh Feck.
I had to chuckle a bit when Eric Mann sent this snippet to me. I’ll let his words do the explaining for you:
This snippet is a perfect case of a developer not considering what plugins might be doing with post meta. The snippet grabs all of the post meta attached to the current post and displays it, all of it. The only time meta isn’t displayed is if the meta key starts with an underscore (_), which means it is a hidden field, or if the key is “enclosure”.
This one had me pulling my hair our for a while. I found it while helping a user of one of my plugins out with a support request. The theme author included some custom post types and added some custom meta fields to those post types, all of which is perfectly fine. The problem, however, comes in with how the theme developer decided to process the saving of the meta fields.
This is a bit of a head scratcher. It’s one of those that makes you wonder what the original developer was thinking, and not because it does something really poorly but because it does something that is completely pointless.
Loading custom jQuery is the single cause for a huge number of the support tickets I handle. Sometimes developers decide to load jQuery from Google, sometimes they include a version with their plugin files, sometimes they enqueue it semi-properly, and sometimes they don’t even enqueue it. This snippet is an example of all the bad ways to load jQuery in a plugin.