Back End

PHP will follow the WordPress PHP best practices https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/. Code will be expected to pass the PHPCS “WordPress-Core” ruleset.

Single and Double Quotes

  • Use single and double quotes when appropriate. If you’re not evaluating anything in the string, use single quotes. You should almost never have to escape quotes in a string because you can just alternate your quoting style.
  • Text that goes into attributes should be run through esc_attr() so that single or double quotes do not end the attribute value, invalidate the HTML and cause a security issue

Indentation

  • Use real tabs and not spaces, as this allows the most flexibility across clients.
  • For associative arrays, values should start on a new line. Use a comma after the last array item because it makes it easier to change the order of the array, and makes for cleaner diffs when new items are added.
  • Tabs should be used at the beginning of the line for indentation, spaces should be used mid-line for alignment.

Brace Style

  • Opening braces shall be at the end of the statement that creates them.
  • Closing braces shall be on a fresh line.
  • On a long block of code, put a short comment at the end so people can tell at glance what that ending brace ends.
  • Braces should always be used, even when they are not required – eg single statement logic blocks.

Space Usage

  • Always put spaces after commas, and on both sides of logical, comparison, string and assignment operators.
  • Put spaces on both sides of the opening and closing parenthesis of if, elseif, foreach, for, and switch blocks.
  • When referring to array items, only include a space around the index if it is a variable.

Formatting SQL statements

  • When formatting SQL statements you may break it into several lines and indent if it is sufficiently complex to warrant it.
  • Always capitalize the SQL parts of the statement – eg UPDATE or WHERE.
  • Functions that update the database should expect incoming parameters to lack SQL slash escaping when passed.
  • Escaping should be done as close to the time of the query as possible, preferably by using $wpdb->prepare()

Naming Conventions

  • Use lowercase letters in variable, action, and function names (never camelCase).
  • Separate words via underscores.
  • Don’t abbreviate variable names unnecessarily; let the code be unambiguous and self-documenting.
  • Class names should use capitalized words separated by underscores. Any acronyms should be all upper case.
  • Constants should be in all upper-case with underscores separating words.
  • Files should be named descriptively using lowercase letters. Hyphens should separate words.
  • Class file names should be based on the class name with class- prepended and the underscores in the class name replaced with hyphens, for example WP_Error becomes class-wp-error.php

Yoda Conditions

  • When doing logical comparisons, always put the variable on the right side, constants or literals on the left. This ensures that, if you omit an equals sign, you’ll get a parse error, because you can’t assign to a constant like true. If the statement were the other way around, the assignment would be perfectly valid, causing a hard-to-find bug.
  • This applies to ==, !=, ===, and !==. Yoda conditions for <, >, <= or >= are significantly more difficult to read and are best avoided.

 

Others

  • Never use shorthand PHP start tags. Always use full PHP tags.
  • ‘else if’ is not compatible with the colon syntax for if|elseif blocks. For this reason, use elseif for conditionals.
  • Perl compatible regular expressions (PCRE, preg_ functions) should be used in preference to their POSIX counterparts. Never use the /e switch, use preg_replace_callback instead.
  • Remove trailing whitespace at the end of each line of code. Do not include the closing PHP tag at the end of a file.
  • Avoid touching the database directly. If there is a defined function that can get the data you need, use it.
  • Clever code: in general, readability is more important than cleverness or brevity.
  • Do not use extract(). extract() is a terrible function that makes code harder to debug and harder to understand.

 
Legacy Code

  • Much of our existing codebase doesn’t fully conform to these rules.
  • Where possible, if you’re working on a file you should attempt to clean-up that file to meet proper coding standards. This is not compulsory but makes everybody’s lives better. If doing so, be sure to submit your coding standard revisions as a separate commit to your fresh code – this makes review easier.

 

Recommended Plugins:

  • Admin Menu Editor Pro
  • Advanced Custom Fields Pro
  • Breadcrumb Trail
  • Gravity Forms
  • Duplicate Post
  • Intuitive Custom Post Order
  • Radio Buttons for Taxonomies
  • Regenerate Thumbnails

 
New plugins should be submitted for review before incorporating in any site.

ACF field groups should use acf-json (see https://www.advancedcustomfields.com/resources/local-json/) to ensure that field groups are saved as files, source-controlled and deployed to staging/live sites without the need for further configuration.