8 Reasons Why Your WordPress Plugin Might Bite The Big One

8 Reasons Why Your WordPress Plugin
Might Bite The Big One

1) Inconsistent Coding Standards
"Coding standards help avoid common coding errors, improve the readability of code, and simplify modification. They ensure that files within the project appear as if they were created by a single person." make.wordpress.org

Your code should clearly communicate its purpose to the casual observer
This is especially important if you were to switch developers.

Now, the coding style doesn't matter at all the the "computer", but for the developer(s) who have to work on and maintain you're plugin, it matters a whole lot!

TIP:
Coding standards and consistency will make your code look better, read better, and easier to work with!

USEFUL LINKS:
WordPress › PHP Coding Standards « Make WordPress Core
Manual :: Coding Standards


2) Generic Function Names
"Fatal error: Cannot redeclare your poorly named function" error
planetozh.com

You're plugin function names should be descriptive and unique.
There are thousands upon thousands of plugins in cyberspace so why in the world would anyone use function names like my_title() or my_function() ??

Go figure..... but people actually do this!

It would be much better to do something like wpck_custom_title() and wpck_custom_function().

These are obviously just plain-jane examples.

Keep in mind you're plugin needs to work side-by-side with other plugins and play nice. It's about future proofing and creating a robust plugin.

TIP: You can also use a class to encapsulate your functions as class methods.


3) No Uninstall Function (uninstall.php)
This is a no brainer dead drop easy thing to do, so why are there plugins that don't do this?
Yes, there are plugins that may not need to, BUT most do.

If a user uninstalls you're plugin, there should be no traces (in database) that you're plugin was there.
Don't leave a mess!

TIP: Use an uninstall.php so you're plugin does not leave a pile of option entries in the database.


4) Hardcoded Paths in The Plugin
HC! (holy crap)
This is soooooo unnecessary and there's a chance you're plugins gonna break!

WordPress allows users to move many files/directories so you CANNOT hardcode these paths.
wp-config.php can be moved.....
wp-content directory can be moved...

So.... don't do it.

TIP: Learn proper functions from WordPress.
USEFUL LINKS: Function Reference/plugin basename « WordPress Codex


5) Improper Activation
What?
Did you know there's a difference when a user does BULK activation versus single activation?

Let's say you're cool plugin does a redirect to the settings page after activation.
Ok, that's cool enough.....
But what if the user bulk activates a bunch of plugins at once?

I'll tell you...
MOST plugins do not detect the bulk activation!
This is pretty easy to do.
If a user bulk activates, you should NOT redirect, but stay on the plugin page.


6) Understand The Proper Usage of Include, Require, etc....
Depending on what the desired outcome is, will depend on what you use.

include: Includes and evaluates the specified file, throwing a warning if the file can’t be found.

include_once: Same as include, but if the file has already been included it will not be included again.

require: Includes and evaluates the specified file (same as include), but instead of a warning, throws a fatal error if the file can’t be found.

require_once: Same as require, but if the file has already been included it will not be included again.

7) Improperly loading assets (JS, CSS)
Wow! This is a real common problem.

DO NOT load assets such as JS or CSS in the head the way you would on an HTML page, use wp_enqueue_style() and wp_enqueue_script().

DO NOT do this:
<link rel='stylesheet' href='style.css' type='text/css' media='screen' />
<script type='text/javascript' src='js/mycustomjs.js'></script>

This is a poor way to load these assets.

It is much safer to register a script or style with WordPress using wp_register_script() or wp_register_style() so you can use them later on.
This function doesn’t output anything to your theme or site, it simply prepares WordPress for using them.

TIP: Let WordPress doing the heavy lifting and prevent conflicts.

USEFUL LINKS:
Function Reference/wp enqueue script « WordPress Codex
Function Reference/wp enqueue style « WordPress Codex

8) Poor Data Validation & Sanitization
You want your plugin to be as secure as possible.

When you receive data entered by a user it’s important to validate it.
Validation of data should be done as soon as it’s received and before it’s written to the database, but, avoid excessive validation that would run on every page load. (the wp_kses_* function).

Data sanitization is about making it safe.
To sanitize data, you need to know the context.
There are times when you need to store data in it's raw format.
But, make sure to always sanitize on output.

You do not want to open a user to malicious codes.

USEFUL LINKS:
Data Validation « WordPress Codex


Hope these were helpful.

Avoid these mistakes and you'll be that much closer to Awesome!

David V