Plugin Coding Standard – PSR-12

evonox
(@evonox)

2 weeks, 4 days ago

I am working on a plugin for WordPress powered by my own PHP framework for WordPress plugin. Is it acceptable to use PSR-12 coding standards instead of WPCS? Is it acceptable later for submission into the WordPress Plugin Repository?

Viewing 4 replies - 1 through 4 (of 4 total)

Patrick Lumumba
(@lumiblog)

2 weeks, 4 days ago
Hello @evonox

That’s a good question.

You can use PSR-12 for your own framework’s internal code, but for WordPress Plugin Repository submission, WordPress Coding Standards compliance is expected for the plugin’s WordPress-facing code.

So, you may want to consider this.

Also, be sure to make use of the Plugin Check (PCP) to help you with coming up with a plugin free of issues and ready for w.org submission.
- This reply was modified 2 weeks, 4 days ago by Patrick Lumumba.
Thread Starter evonox
(@evonox)

2 weeks, 4 days ago
Thank you @lumiblog for your answer.

So, if I understand it right, the primary goal of WPCS is to guarantee that one plugin does not conflict with others.

The strong encapsulation of all the plugin application code is the primary goal of the framework I am creating. You will specify the namespace prefix for the all the plugin application code and the plugin prefix in one place. The framework will use this prefix everywhere in the WordPress Core APIs automatically without the need for the plugin author even to care. All of that using DI container with OOP programming.

The main plugin file will look like this.
```
<?php

/*
 * Plugin Name:       WordPress Plugin Framework Demo
 * Plugin URI:        https://github.com/evonox/wordpress-plugin-framework.git
 * Description:       WordPress Plugin Framework Demo
 * Version:           1.0.0
 * Author:            Viktor Prehnal
 * Author URI:        https://www.viktorprehnal.cz/
 * License:           MIT
 * License URI:       https://opensource.org/license/mit
 */

if (! defined("ABSPATH")) {
    exit;
}

const __PLUGIN___MAIN_FILE_PATH = __FILE__;

require_once __DIR__ . "/vendor/autoload.php";
require_once __DIR__ . "/Framework/bootstrap.php";
```
Basically the framework will work with WordPress in the Inversion of Control fashion. The plugin application code will communicate with most WP Core APIs through the framework.

I would need a help to figure out then deeper, what might be allowed for compliance and what not.

Would it be possible to request someone from WP Core Team as supervisor of what is allowed and what not? The framework will be FOSS available upon possibly Apache 2.0 license.
- This reply was modified 2 weeks, 4 days ago by evonox.
Moderator Jan Dembowski
(@jdembowski)

Forum Moderator and Brute Squad

2 weeks, 4 days ago

Would it be possible to request someone from WP Core Team as supervisor of what is allowed and what not?

No, not at all. 😉

But you can email them via plugins[at]wordpress.org yourself or as in the #pluginreview WordPress Slack channel.

To get access to that Slack instance follow the instructions here:

https://make.wordpress.org/chat/

Moderator threadi
(@threadi)

2 weeks, 4 days ago

No, the WordPress Coding Standards are not intended to prevent conflicts with other plugins. This is the goal:

The purpose of the WordPress Coding Standards is to create a baseline for collaboration and review within various aspects of the WordPress open source project and community, from core code to themes to plugins.
https://developer.wordpress.org/coding-standards/wordpress-coding-standards/

The plugin team also checks plugins for this and points out any anomalies that may occur. It is therefore in your interest to comply with the WCS if you want to make your plugin available to WordPress users in the WordPress repository without them encountering a plugin that has been blocked for security reasons. Writing easily readable code also helps other developers to read and understand your code, especially since your code is also subject to the GPL (or Apache 2.0 in your case) if you want to upload the plugin to the repository.

Nevertheless, you can still write source code that deviates from this as long as it complies with recognized standards and is not highly complex and self-developed. My urgent recommendation would be to document it well.

In my own plugins (and I now have quite a few in use), I usually use PSR-4 for a certain range of functions. For example, there are deviations in class names and their file names, which must be written differently from WCS. You just have to document this in your own code, and then it’s no problem in my opinion.

If you need help with this, I would recommend contacting other developers who also develop WordPress plugins. Take a look at how other plugins write their code. You can learn a lot from this (unfortunately, there are also a few poorly written plugins, but I think you’ll recognize them quickly).

If you have further questions about the necessary code quality, you can also contact the plugin team. See the top right corner: https://make.wordpress.org/plugins/