Title: Plugin Coding Standard – PSR-12 Last modified: March 9, 2026 --- # Plugin Coding Standard – PSR-12 * [evonox](https://wordpress.org/support/users/evonox/) * (@evonox) * [2 months, 3 weeks ago](https://wordpress.org/support/topic/plugin-coding-standard-psr-12/) * 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](https://wordpress.org/support/users/lumiblog/) * (@lumiblog) * [2 months, 3 weeks ago](https://wordpress.org/support/topic/plugin-coding-standard-psr-12/#post-18845783) * Hello [@evonox](https://wordpress.org/support/users/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)](https://wordpress.org/plugins/plugin-check/) to help you with coming up with a plugin free of issues and ready for w.org submission. - This reply was modified 2 months, 3 weeks ago by [Patrick Lumumba](https://wordpress.org/support/users/lumiblog/). * Thread Starter [evonox](https://wordpress.org/support/users/evonox/) * (@evonox) * [2 months, 3 weeks ago](https://wordpress.org/support/topic/plugin-coding-standard-psr-12/#post-18845895) * Thank you [@lumiblog](https://wordpress.org/support/users/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. * ```wp-block-code 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/](https://make.wordpress.org/chat/) * Moderator [threadi](https://wordpress.org/support/users/threadi/) * (@threadi) * [2 months, 3 weeks ago](https://wordpress.org/support/topic/plugin-coding-standard-psr-12/#post-18845919) * 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/](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/](https://make.wordpress.org/plugins/) Viewing 4 replies - 1 through 4 (of 4 total) You must be [logged in](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fsupport%2Ftopic%2Fplugin-coding-standard-psr-12%2F%3Foutput_format%3Dmd&locale=en_US) to reply to this topic. * In: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/) * 5 replies * 4 participants * Last reply from: [threadi](https://wordpress.org/support/users/threadi/) * Last activity: [2 months, 3 weeks ago](https://wordpress.org/support/topic/plugin-coding-standard-psr-12/#post-18845919) * Status: not resolved ## Topics ### Topics with no replies ### Non-support topics ### Resolved topics ### Unresolved topics ### All topics