Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
The WordPress Way - The 10 rules of WordPress development

The WordPress Way

A tongue-in-cheek look at coding standards in the WordPress core and the average WordPress plugin.

  1. # Declare variables global - in case they're going to be used again
  2. All function/method parameters should be strings (e.g. 'yes'/'no') - for clarity
  3. Functions and methods should return mixed types
  4. No need to separate PHP logic from HTML, JS or CSS
  5. Don't worry about PHP Notices - they're not important
  6. Keep compatibility with PHP 4 - it's still used
  7. If writing a class, create a non-OO function (that calls the class) for every method
  8. Combine multiple classes and functions in a single file - for performance
  9. Functions should echo instead of returning - to save having to echo later on
  10. Assume input has already been filtered through add_slashes - WordPress is pre-secured

Global variables are nearly always bad. They make writing quality, testable code much harder. Components are linked together and cannot function on their own.

Global variables are dangerous as their access (read/write) cannot be controlled. In WordPress, any plugin could decide to change $is_apache to false if it wanted.

WordPress improves slightly on using globals for its options API by using 2 functions to read / write to options but could do with a lot of improving. A quick grep of the WordPress source shows over 1000 uses of the global keyword.

Classes should be loosely coupled. Where a dependency is required it should ideally be injected, or at the very least, a singleton used instead of a global variable. Using dependency injection has a small learning curve but leads to much more manageable code.

There are many WordPress functions that are invoked similar to get_something('big', 'red', 'car', 'fast'). Usung un-named strings as parameters means developers need to look up the function signature very often. Using strings, in many cases, instead of bools or objects, means that developers have to use more logic to one-off generate these parameters.

Instead of get_foo(is_singular() ? 'home' : 'post') it would be simpler to do get_foo(is_singular()).

Slightly better is functions accepting an array of options. Though if a function accepts either a huge array of options or more than 3 or 4 parameters then they are obvious candidates for turning into a class.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment