PHP Coding Standards for WordPress: A Guide

WordPress requires a lot of source code for its plugins and themes to keep functioning — in multiple coding languages. Of course, this means a fair amount of reading is necessary to understand them. So, devs need to learn about WordPress’ Best Practices for PHP Coding Standards.

Coding Standards are rules that standardize codes, especially since WordPress has multiple contributors. Naturally, such contributors have their own coding styles. Still, with WordPress Coding Standards, developers can create code anyone can understand. It’s beneficial for the community, even if a contributor sees a block of code for the first time.

The PHP Scripting Language is an excellent example of a coding language used by WordPress. Thus, Web Developers must know about the best PHP Coding Standards and Best Practices for WordPress!

Coding Standards for PHP: Best Practices

PHP or Hypertext Preprocessor is a server-side coding language used for Web Development. Of the websites that have revealed the programming language of their server-side, 77.5% use PHP!

Of course, when it comes to adding PHP code to WordPress, you must follow several conventions. So, much like CSS and HTML, WordPress’s PHP Coding Standards and Best Practices make code more uniform.

The following standards can boost readability and collaboration for the WordPress community. Thus, even if different developers create code, everyone can follow along. But before you get started, check out for signs that you need to update your PHP version.

Single and Double Quotes

Source: WordPress.

As with HTML Coding Standards, it’s crucial to ‘“”’ and ‘‘’’ whenever necessary with PHP. For instance, contributors must use ‘‘’’ if nothing is being evaluated in the string. The great thing about coding is that you can alternate the quote usage! Thus, there are few chances for you to escape the quotes of a string.

Additionally, WordPress Contributors must escape text in HTML or XML attributes. As a result, the quotes don’t end the attribute value, invalidating the HTML. Otherwise, you’ll have a security issue on your hands.

Indentation

As with CSS Coding Standards, code indents should always be logical and use tabs to indent a line. 

Source: WordPress.

• WordPress Developers should use spaces for mid-line alignment. It allows a given code block to become more readable.

Source: WordPress.

• Each associative array with more than one item must start on a new line. Thus, add a comma after the last associative array item. As a result, it’s easy to change array order and results in cleaner diffs if you add more items.

Source: WordPress.

• Devs must indent case statements for switch control structures one tab from the switch statement. Also, indent the case’s content from the case condition statement.

Brace Style

Source: WordPress.

Devs must utilize braces for all blocks, even when they’re not necessary. But, if you have a lengthy block, you must decide whether to break it into two or more.

Source: WordPress.

As a result, this makes it easier to parse through, especially for testing and readability. 

Source: WordPress.

But, devs are prohibited from using single statement inline control structures since braces are required. If PHP code is embedded in the HTML, you can use the alternative syntax for control structures. The alternative syntax includes ‘if/endif’ and ‘while/endwhile.’

Use elseif, not else if

When coding, ‘else if’ must be avoided because it isn’t compatible with colon syntax for if|elseif blocks. Thus, it’s vital to use ‘elseif’ for conditionals.

Declaring Arrays

Long array syntax is the way to go if contributors want to declare arrays. After all, they’re more readable and descriptive than short array syntax.

Closures (Anonymous Functions)

Source: WordPress.

Closures are an alternative method for creating new functions to pass as callbacks. But, devs mustn’t pass them as filter or action callbacks because the process of removing them is challenging.

Multi-line Function Calls

Source: WordPress.

One parameter should have its own line. However, developers should assign multi-line parameter values to a specific variable first. So it’s only after doing this that they can be passed to the Function Call.

To split a Function Call over several lines, each parameter must have its own line. But, single-line inline comments have a line of their own. 

Regular Expressions

Contributors should prioritize the use of Perl Compatible Regular Expressions (PCRE). Thus, the use of preg_replace_callback is welcome. In addition, the use of single-quoted strings is better for regular expressions. After all, you can escape its two metasequences, ‘\’ and ‘\\,’ without much issue.

Opening and Closing PHP Tags

Source: WordPress.

To embed multi-line snippets in an HTML block, PHP open and close tags should be on their own line.

No Shorthand PHP Tags

Source: WordPress.

This WordPress PHP Coding Standard is exactly as it states. So, contributors must avoid shorthand PHP tags and opt to use the full ones.

Remove Trailing Spaces

Of course, removing the trailing whitespaces at the end of code lines is vital. Also, developers should omit the closing PHP tag at the end. However, if you’re using this tag, remove the trailing spaces.

Space Usage

Spaces are essential for naming PHP files, so:

Source: WordPress.

• WordPress Developers must remember to add spaces after commas. Additionally, they should be added before and after operators, particularly the assignment, comparison, logical, and string ones.

Source: WordPress.

• Also, contributors should add spaces before and after the ‘(‘and ‘)’ of control structure blocks.

Source: WordPress.

• On the subject of type casts, they must be lowercase and shortened.

Source: WordPress.

• If an array item is a variable, it should only have a space around the index.

Source: WordPress.

• As a result, switch blocks shouldn’t have spaces separating case condition and ‘:.

Source: WordPress.

• Also, on return type declarations, there are no spaces before ‘:.’

Source: WordPress.

• Finally, ‘( )’ must always have spaces unless otherwise specified.

Formatting SQL statements

• If you’re formatting SQL statements, you can keep them to one line. But, you can make things easier by giving each statement its own indented lines if needed.
• SQL parts in the statement should be in uppercase always.

Source: WordPress.

• If you have functions that can update the database, their parameters will not have SQL slash escaping once passed. As a result, you need to escape as close as possible to the query’s time. You may apply ‘$wpdb->prepare()’ to achieve this.
• For string placeholders, you utilize ‘%s.’ Then, for integer placeholders, ‘%d.’ However, these shouldn’t be quoted in the stylesheets, as ‘$wpdb->prepare()’ can handle it for you.

Database Queries

While working on the code, you mustn’t directly touch the database. Instead, you can get necessary data from a defined function as needed with Database Abstraction. With it, you use functions to keep code forward-compatible. Plus, the abstraction method is speedy when it comes to situations where results are cached!

However, if you must interact with the database, you’ll want to create a Trac ticket. This way, you can suggest new functionality for future WordPress versions.

Naming Conventions

The most critical Naming Conventions are: to name everything with lowercase letters and avoid camelcase. Also, WordPress Developers must use underscores to separate words. Here are more practices:

Source: WordPress.

Source: WordPress.

• Developers must name their files as clearly and descriptively as possible. Thus, they must avoid unnecessary abbreviations. By discouraging such things, code becomes clear with its specifications.

Source: WordPress.

• WordPress Contributors must capitalize class names properly and separate them with hyphens.
• Also, contributors must type acronyms in uppercase letters.
• Constants must be in all uppercase letters, separated by underscores.

Source: WordPress.

• Class file names must start with ‘class-’ underscores must be switched out for hyphens.

Of course, this is the standard for all files, except for three specific ones: 

• class.wp-dependencies.php
• class.wp-scripts.php
• class.wp-styles.php.

Finally, for the wp-includes directory, files with template tags should have ‘-template’ at the end of the name.

Only one object structure (class/interface/trait) per file

Source: WordPress.

This Coding Standard states that focus is a top priority for your files. That is, you must focus on a single object structure. Additionally, you can also label files according to the sole object structure of each!

Self-Explanatory Flag Values for Function Arguments

Source: WordPress.

• Contributors should favor string values when calling functions. Because they’re descriptive, code becomes more legible. After all, without named arguments, flag values are meaningless.

Source: WordPress.

• In addition, PHP 8.0 will only support named arguments. But since WordPress utilizes the older versions of the coding language, you can’t use them yet.

Source: WordPress.

• Apply an $args array if you need to be descriptive with function parameters.

Interpolation for Naming Dynamic Hooks

Source: WordPress.

To improve readability, utilize interpolation and name Dynamic Hooks.

• Also, the variables in hook tags must utilize ‘{ },’ and the outer tag name should utilize ‘“”.’ With these, PHP can understand the variables in the interpolated string.
• Additionally, dynamic values within tag names must be as clear and straightforward as possible.

Ternary Operator

Source: WordPress.

Contributors should constantly test Ternary Operators to ensure the statement is true. If not, then Ternary Operators might cause some confusion. But WordPress Developers have an exception to this Coding Standard, which is using ‘! empty().’ Lastly, WordPress Contributors shouldn’t use the short ternary operator.

Yoda Conditions

Source: WordPress.

Let’s say you’re handling logical comparisons with variables. First, you need to write your conditions the Yoda way.

• Keep variables to the right and everything else — constants, function calls, and literals — to the left.
• So, if neither has a variable, you can order them however you want.
• WordPress Developers can’t assign to a constant such as true, otherwise, you’ll get a parse error. However, in the sample code above, you might get an error if you forget a ‘=’ sign.
• However, if you reverse the statement, it becomes valid, but the if statement will become true. This could cause you a bit of a hassle. 
• Thus, WordPress Contributors must remember that these conditions apply to ‘!=,  ==, !==, and ===.’ But it’s vital to avoid using ‘<, >, <= or >=,’ as much as possible, as they’re more difficult to understand.

Clever Code

Source: WordPress.

It’s critical to write code that people can read. Therefore, WordPress Contributors must create readable rather than crafty or concise code. After all, contributors should create code familiar to the entire WordPress community.

Source: WordPress.

• It’s good practice to avoid loose comparisons because their behavior can mislead. However, they are necessary for certain situations.

Source: WordPress.

• But, you must avoid placing assignments in conditionals.

Source: WordPress.

• If you’re handling a switch statement, you may allow more than one empty case to fall through. Of course, this results in them falling onto a common block. Thus, if a case contains a block but falls to the next one, you must comment on it.
• Also, according to Coding Standards and Best Practices, you must never use the goto statement.
• In addition, avoid utilizing the eval() construct, as it’s impossible to secure. An equally dangerous function to avoid using is create_function() function. Not only does it internally perform an eval(), but it’s also deprecated as of PHP 7.2. Additionally, create_function() was removed from PHP 8.0 entirely.

Error Control Operator @

PHP’s sole Error Control Operator is ‘@.’ Thus when added to the start of any expression, it suppresses the expression’s possible diagnostic errors. But, instead of actual error checking, some use the Error Control Operator carelessly. So, its use is not recommended according to WordPress PHP Coding Standards and Best Practices. 

Don’t use extract()

When coding according to PHP standards, the use of ‘extract()’ is discouraged. After all, it causes great difficulties in understanding and debugging code. 

Follow the Standards and Create Readable Codes Today!

And that’s it for PHP Coding Standards’ Best Practices for WordPress. Coding Standards, of course, aren’t directions for creating code from scratch. Instead, Coding Standards are regulations for how to write WordPress code or files.

Of course, there can be exceptions for each standard. But in general, contributors must follow them to increase readability across various files. For example, a WordPress Developer from the Philippines is sure to be familiar with such standards.