Modern WP Dev

PSR in WP development

What are PSR standards and how to apply them in WP development.
Josanu Andrei Site Author
3 min read

Q1: What are PSR standards and why are they important in PHP development?
A1: PSR (PHP Standards Recommendations) are coding standards created by the PHP-FIG group. They help developers write consistent and clean code. For example, PSR-1 and PSR-12 define how to format code, PSR-4 defines autoloading, and PSR-7 is for HTTP messages. Following them makes code easier to read, maintain, and integrate with third-party libraries.

Q2: Do we need to strictly follow PSR standards when writing WordPress plugins or themes?
A2: WordPress has its own coding standards, which are a bit different from PSR (like using snake_case for functions instead of camelCase). But it’s good to mix both worlds: follow WP standards for compatibility and readability inside the WP ecosystem, and PSR standards when building OOP code or integrating with modern PHP libraries. Clean code is about balance, not dogma.

Q3: What are some best practices when writing WordPress plugins or themes?
A3:

  • Always escape output (esc_html, esc_url, etc.).
  • Sanitize user input with functions like sanitize_text_field.
  • Use nonces (wp_nonce_field) to protect forms.
  • Never load scripts/styles directly; use wp_enqueue_script and wp_enqueue_style.
  • Follow WP coding standards for naming and indentation.
  • Use hooks and filters instead of editing core code.
  • Keep classes and functions small and single-responsibility.

Q4: How do you apply PSR-4 autoloading in a custom WordPress plugin?
A4: I organize my plugin files using namespaces and a src/ folder. Then I define the autoloading rules in composer.json. Example:

"autoload": {
  "psr-4": {
    "MyPlugin\\": "src/"
  }
}

After running composer dump-autoload, I can use use MyPlugin\Services\ClassName; anywhere. This keeps code modular and avoids require_once spaghetti.

Q5: How do you ensure your plugin code remains maintainable?
A5: I use OOP principles (Single Responsibility, Dependency Injection, Interfaces). I keep logic separated (Admin vs Frontend). I write comments and follow naming conventions. I use Composer for dependencies and PHPUnit for unit tests. Clean architecture makes it easier for another developer to jump in without getting lost.

Q6: Can you give an example of clean vs bad practice in WordPress development?
A6:
Bad practice:

function myplugin() {
   $user = $_POST['user'];  
   update_option('user', $user);  
}

Clean practice:

function myplugin_save_user() {
   if ( ! isset($_POST['myplugin_nonce']) || ! wp_verify_nonce($_POST['myplugin_nonce'], 'myplugin_action') ) {
      return;
   }
   $user = sanitize_text_field($_POST['user'] ?? '');
   update_option('myplugin_user', $user);
}

This version uses nonces, sanitization, and clear naming.

Q7: How do you balance WordPress coding standards with modern PHP practices?
A7: I follow WordPress standards for compatibility (naming, escaping, hooks), but I also apply modern PHP ideas like namespaces, autoloading, and type hints in my classes. For example, service classes use PSR-4 autoloading, but template files follow WordPress guidelines. This way, I get the best of both: readable for WP devs, robust for advanced PHP.

Tags: