The idea is to collaborate on what objective best practices might be so that we can potentially eventually use them in some community collaboration review process.

UPDATE: After seeing the first few responses it becomes clear that we need to have only one idea/suggestion/best-practice per answer and people should review the list to ensure there are no duplicates before posting.

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

37 Answers
37

If you think people would like to add or alter some data: provide apply_filters() before returning.

P.S. One thing I find a bit disappointing and that your question addresses is the percentage of plugins that are designed only for end-users, i.e. that have no hooks of their own. Imagine if WordPress were designed like most plugins? It would be inflexible and a very niche solution.

Maybe things would be different if WordPress were to have the ability to auto-install plugins on which other plugins depended? As it is I typically have to write a lot of the functionality I need from scratch because clients want things a certain way and the available plugins, while 90% there, don't allow me the flexibility to update the remaining 10%.

I really do wish those leading the WordPress community would identify a way to ensure that plugins are rewarded for following best practices (such as adding in hooks for other developers) much like good answers are rewarded on a StackExchange site.

Example: I want to do something in my plugin when someone retweets an article. If there was a custom hook in whatever the popular retweet plugin is that I could hook in to and fire off of, that would be great. There isn't, so I can modify their plugin to include it, but that only works for my copy, and I don't want to try to redistribute that.

[...]
Finally, I would like to point out that is important to load custom user language files from WP_LANG_DIR before you load the language files that ship with the plugin. When multiple mo-files are loaded for the same domain, the first found translation will be used. This way the language files provided by the plugin will serve as a fallback for strings not translated by the user.

Ensure Plugins Generate No Errors with WP_DEBUG

Always test your plugins with WP_DEBUG turned on and ideally have it turned on throughout your development process. A plugin should not throw ANY errors with WP_DEBUG on. This includes deprecated notices and unchecked indexes.

To turn debugging on, edit your wp-config.php file so that the WP_DEBUG constant is set to true. See the Codex on Debug for more details.

If I could upvote this answer twice, I would. It's so frustrating when I'm working on a dev site and have to turn WP_DEBUG off because a plugin I need to use is spewing warnings and notices all over the place.
–
Ian DunnAug 28 '12 at 16:04

First Use Existing Functions in WordPress Core

If you can: use existing functions included in WordPress core instead of writing your own. Only develop custom PHP functions when there is not an appropriate pre-existing function in WordPress core.

One benefit is you can use "log deprecated notices" to easily monitor functions that should be replaced. Another benefit is users can view the function documentation in the Codex and better understand what the plugin does even if they are not an experienced PHP developer.

Related

A problem with that is that a lot of core isn't really structurally designed for reusability. I just had to copy and slightly modify half the image manipulation/metadata functions to create my own attachment-like behaving post-type, just because a function like downsize() calls some function that includes a hardcoded check for post-type='attachment'. There's lots of that like the inflexible wp_count_posts() being another example. Before you can really reuse core WP needs a complete refactoring.
–
wyrfelFeb 16 '11 at 10:04

Related

This should be the default behavior, yes, but it should also prompt the user to keep some data ... like when uninstalling a video game asks you if you want to remove saved games and downloaded material. A user might only be deactivating the plug-in for testing purposes and wouldn't want to go back through setting up their options when they reactivate it.
–
EAMann♦Aug 23 '10 at 14:24

1

I'm only talking about when a plugin is completely removed, not when it is deactivated.
–
tnorthcuttAug 23 '10 at 16:33

2

I understand that ... but sometimes I'll delete plug-ins so I can manually re-add them from a backup or beta version that's not yet hosted in the repository ...
–
EAMann♦Aug 23 '10 at 18:29

4

@EAMann: For that and for migrating plugins to another server, a plugin should provide a mechanism to export and import settings.
–
hakreAug 24 '10 at 9:18

2

I've seen a few plugins offer an "Uninstall" button in their settings with big red warnings it will delete all data. This is separate from de-activation, and I think a great way to handle it. Not everyone uses the "Delete" button to remove a plugin.
–
gabrielkJun 21 '11 at 16:20

Use a class and object orientated PHP5 code

There's no reason not to write clean, object-orientated PHP5 code. PHP4 support will phase out after the next release (WP 3.1). Of course, you can prefix all your function names to end up with endlessly_long_function_names_with_lots_of_underscores, but it's much easier to just write a simple class and bundle everything in that. Also, put your class in a seperate file and name it accordingly so you can easily extend and maintain it:

// in functions.php
require 'inc/class-my-cool-plugin.php';
new MyCoolPlugin();
// in inc/class-my-cool-plugin.php
class MyCoolPlugin {
function __construct() {
// add filter hooks, wp_enqueue_script, etc.
// To assign a method from your class to a WP
// function do something like this
add_action('admin_menu', array($this, "admin"));
}
public function admin() {
// public methods, for use outside of the class
// Note that methods used in other WP functions
// (such as add_action) should be public
}
private function somethingelse() {
// methods you only use inside this class
}
}

Prefix All Global Namespace Items

A plugin should properly prefix ALL global namespace items (constants, functions, classes, variables, even things like custom taxonomies, post types, widgets, etc.). For example, do not create a function called init(); instead, name it something like jpb_init().

Announce Data-Loss on Plugin Uninstallation

Upon uninstallation a plugin shouldprompt a user that it will be deleting it's data and receive a confirmation that the user is okay with deleting the data before doing so and a plugin should also allow the user the option to keep the data upon uninstallation. (This idea from @EAMann.)

You can find further information at this Q. A related ticket to fix the "working together" of WP_Error and wp_die() is linked from there and another ticket will follow. Comments, critics & such is appreciated.

Related:

Protect Plugin Users Privacy

(Previously: Anonymous API Communication)

If a plug-in communicates with an external system or API (e.g. some Webservice), it should do so anonymously or provide the user with an anonymous option that ensures that no data related to the user of the plugin leaks to a second party uncontrolled.

Host Plugins on WordPress.org

Use the SVN repository provided on WordPress.org for hosting plugins. It makes for an easier update user-experience and if you've never used SVN before, it gets you to actually understand by using it in a context that justifies it.

Comment using PhpDoc

Best practice is close to the PhpDoc style.
If you don't use an IDE like "Eclipse", you can just take a look at the PhpDoc Manual.

You don't have to know exactly how this works. Professional Developers can read the code anyway and just need this as a summary. Hobby coders and users might appreciate the way you explain it on the same knowledge level.

And furthermore, use update_option and never add_option, the update function will create the option when it does not exist.. :)
–
t31osFeb 17 '11 at 18:32

3

I wouldn't say never use add_option. There is a good use case for add_option where if the option is already set, it isn't changed, so I use it in activation to preserve possibly already existing user preferences.
–
ProfKOct 28 '11 at 5:47

1

Another use case for add_option is when you want to explicitly disable auto loading. update_option will force autoload to true, so you want to disable autoload, use add_option when initially creating the option.
–
goto10Jul 26 '12 at 5:24

Provide Access Control by Using Permissions

In many instances, users may not want everyone to have access to areas created by your plugin especially with plugins that do multiple complex operations, a single hardcoded capability check may not be enough.

At the very least, have appropriate capability checks for all of the different kind of procedures your plugin can be used for.

Import / Export Plugin Settings

It's not that common across plugins, but if your plugin has (some) settings, it shouldprovide Import / Export of data like configuration and user input.

Import/Export improves the usability of a plugin.

An example-plugin that has such an import and export functionality (and as well an undo mechanism) is Breadcrumb NavXT (Wordpress Plugin) (full disclosure: some little code by me in there, most has been done by mtekk).

Related

Organize your code

It's alway hard to read code that's not written in the order it get's executed. First include/require, define, wp_enqueue_style & _script, etc., then the functions that the plugin/theme needs and at last the builder (ex. admin screen, stuff that integrates in the theme, etc.).

Try to separate things like css and js in their own folders. Also try to do this with functions that are only helpers, like array flatteners and similar. Keeping the "main" file as clean and easy to read as possible is a way that helps users, developers and you, when you try to update in a year and haven't seen the code for a longer time.

It's also good to have a structure you repeat often, so you always find your way through. Developing in a known structure on different projects will give you time to make it better and even if your client switches to another developer, you will never hear "he left a chaos". This builds your reputation and should be a long term goal.

Die with style

die in a decent manner
All of a plugins (and even themes) functions should use wp_die() in critical places to offer the user a little information on what had happened. Php errors are annoying and wp_die can give the user a nice styled message on what the plugin (or they) did wrong. Plus, if the user has debugging deactivated the plugin will just break.

Using wp_die() also helps that your plugins / themes are compatible with the wordpress testsuite.

Offer Extensible Forms

When a plugin offers the possiblity to input data, it should always have a hook at the end, right before the "submit" and/or "reset" button, so developers can easily extend the form with not only fields, but buttons too.

License Plugins under a GPL Compatible License

Plug-ins and themes should be licensed under a WordPress-compatible license. This enables them to be re-distributed with WordPress as a "program." A recommended license is the GPL. Take care that all code libraries included with the plug-in are compatible with the same license.

Your plugin description should accurately detail the functions of your plugin. There are 10 featured post plugins. All of them display featured posts, yet many have different features. It should be easy to compare your plugin to similar plugins by reading the description.

You should avoid bragging about how simple your plugin is unless it really is very basic. You should include useful links in the description like the link to the settings.

But covering the smallest first is basic, so that you can reach the functional testing with WordPress as the answer says, isn't that right?
–
Fernando BrianoFeb 17 '11 at 3:55

1

This is a plugin not an application, can you test a Java application without Java Runtime? Yes, by writing Java as a mockup and then test your plugin. Chances are the bugs are in your mockup. *) disclaimer or compiling it to native code.
–
edelwaterFeb 18 '11 at 1:18