Here are some best practices to help organize your code so it works well alongside WordPress core and other WordPress plugins.<\/p>\n\n\n\n
A naming collision happens when your plugin is using the same name for a variable, function or a class as another plugin.<\/p>\n\n\n\n
Luckily, you can avoid naming collisions by using the methods below.<\/p>\n\n\n\n
By default, all variables, functions and classes are defined in the global namespace<\/strong>, which means that it is possible for your plugin to override variables, functions and classes set by another plugin and vice-versa. Variables that are defined inside<\/em> of functions or classes are not affected by this.<\/p>\n\n\n\n All globally accessible code should be prefixed with a unique<\/em> identifier. Prefixes prevent conflicts with other plugins and prevents them from overwriting your variables and accidentally calling your functions and classes.<\/p>\n\n\n\n In order to prevent conflicts with other plugins, your prefix should be at least 4 letters long, though we recommend 5. You should avoid using a common English word, and instead choose something unique to your plugin. We host tens of thousands of plugins on WordPress.org alone. There are hundreds of thousands more outside our servers. You\u2019re going<\/em> to run into conflicts.<\/p>\n\n\n\n A good way to do this is with a prefix. For example, if your plugin is called “Easy Custom Post Types” then you could use names like these:<\/p>\n\n\n\n Because you are making code as a part of the WordPress<\/strong> project, you must avoid the use of prefixes that have a high probability of conflicting with the core WordPress. This includes but is not limited to: If you are making code for a ‘sub’ plugin (such as a WooCommece extension), you would similarly need to avoid using any of their normal\/common prefixes (i.e. Woo, WooCommerce).<\/p>\n\n\n\n You can use them inside<\/em> your classes or namespace, but not as stand-alone function\/namespace\/class.<\/p>\n<\/div>\n\n\n\n If you’re using Remember: Good prefix names are unique and distinct to your plugin. This will help you and the next person in debugging, as well as prevent conflicts.<\/p>\n\n\n\n Code that must<\/strong> be prefixed includes:<\/p>\n\n\n\n PHP provides a number of functions to verify existence of variables, functions, classes and constants. All of these will return true if the entity exists.<\/p>\n\n\n\n Keep in mind that using An easier way to tackle the naming collision problem is to use a class<\/a> for the code of your plugin.<\/p>\n\n\n\n You will still need to take care of checking whether the name of the class you want is already taken but the rest will be taken care of by PHP.<\/p>\n\n\n\n The root level of your plugin directory should contain your A clear folder structure helps you and others working on your plugin keep similar files together.<\/p>\n\n\n\n Here’s a sample folder structure for reference:<\/p>\n\n\n\n The architecture, or code organization, you choose for your plugin will likely depend on the size of your plugin.<\/p>\n\n\n\n For small, single-purpose plugins that have limited interaction with WordPress core, themes or other plugins, there\u2019s little benefit in engineering complex classes; unless you know the plugin is going to expand greatly later on.<\/p>\n\n\n\n For large plugins with lots of code, start off with classes in mind. Separate style and scripts files, and even build-related files. This will help code organization and long-term maintenance of the plugin.<\/p>\n\n\n\n It’s helpful to separate your admin code from the public code. Use the conditional is_admin()<\/a>. You must still perform capability checks as this doesn’t indicate the user is authenticated or has Administrator-level access. See Checking User Capabilities<\/a>.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n As a security precaution, it’s a good practice to disallow access if the You can implement this by including this code at the top of the file:<\/p>\n\n\n\n While there are a number of possible architecture patterns, they can broadly be grouped into three variations:<\/p>\n\n\n\n Specific implementations of the more complex of the above code organizations have already been written up as tutorials and slides:<\/p>\n\n\n\n Instead of starting from scratch for each new plugin you write, you may want to start with a boilerplate<\/strong>. One advantage of using a boilerplate is to have consistency among your own plugins. Boilerplates also make it easier for other people to contribute to your code if you use a boilerplate they are already familiar with.<\/p>\n\n\n\n These also serve as further examples of different yet comparable architectures.<\/p>\n\n\n\n Of course, you could take different aspects of these and others to create your own custom boilerplate.<\/p>\n","protected":false},"author":12560283,"featured_media":0,"parent":10903,"menu_order":2,"template":"","meta":{"footnotes":""},"class_list":["post-10922","plugin-handbook","type-plugin-handbook","status-publish","hentry","type-handbook"],"revision_note":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/developer.wordpress.org\/wp-json\/wp\/v2\/plugin-handbook\/10922","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/developer.wordpress.org\/wp-json\/wp\/v2\/plugin-handbook"}],"about":[{"href":"https:\/\/developer.wordpress.org\/wp-json\/wp\/v2\/types\/plugin-handbook"}],"author":[{"embeddable":true,"href":"https:\/\/developer.wordpress.org\/wp-json\/wp\/v2\/users\/12560283"}],"version-history":[{"count":42,"href":"https:\/\/developer.wordpress.org\/wp-json\/wp\/v2\/plugin-handbook\/10922\/revisions"}],"predecessor-version":[{"id":154956,"href":"https:\/\/developer.wordpress.org\/wp-json\/wp\/v2\/plugin-handbook\/10922\/revisions\/154956"}],"up":[{"embeddable":true,"href":"https:\/\/developer.wordpress.org\/wp-json\/wp\/v2\/plugin-handbook\/10903"}],"wp:attachment":[{"href":"https:\/\/developer.wordpress.org\/wp-json\/wp\/v2\/media?parent=10922"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Prefix Everything<\/h4>\n\n\n\n
\n
function ecpt_save_post()<\/code><\/li>\n\n\n\ndefine( \u2018ECPT_LICENSE\u2019, true );<\/code><\/li>\n\n\n\nclass ECPT_Admin{}<\/code><\/li>\n\n\n\nnamespace EasyCustomPostTypes;<\/code><\/li>\n\n\n\nupdate_option( 'ecpt_settings', $settings );<\/code><\/li>\n<\/ul>\n\n\n\n__<\/code> (double underscores), wp_<\/code> , WordPress<\/code>, or _<\/code> (single underscore)<\/p>\n\n\n\n_n()<\/code> or __()<\/code> for translation, that’s fine. We’re only<\/strong> talking about functions you’ve created for your plugin, not the core functions from WordPress. In fact, those core features are why<\/em> you need to not use those prefixes in your own plugin! You wouldn’t want to break WordPress for your users.<\/p>\n\n\n\n\n
Check for Existing Implementations<\/h4>\n\n\n\n
\n
(!function_exists(\u2018NAME \u2018)) {<\/code> around all your functions and classes sounds like a great idea until you realize the fatal flaw. If something else has a function with the same name and their code loads first, your plugin will break. Using if-exists to replace\/override a function or class should be reserved for shared<\/em> libraries only.<\/p>\n\n\n\nExample<\/h4>\n\n\n\n
\/\/ Create a function called \"wporg_init\" if it doesn't already exist\nif ( ! function_exists( 'wporg_init' ) ) {\n function wporg_init() {\n register_setting( 'wporg_settings', 'wporg_option_foo' );\n }\n}\n\n\/\/ Create a function called \"wporg_get_foo\" if it doesn't already exist\nif ( ! function_exists( 'wporg_get_foo' ) ) {\n function wporg_get_foo() {\n return get_option( 'wporg_option_foo' );\n }\n}<\/code><\/pre>\n\n\n\nObject Oriented Programming Method<\/h3>\n\n\n\n
Example<\/h4>\n\n\n\n
if ( ! class_exists( 'WPOrg_Plugin' ) ) {\n class WPOrg_Plugin {\n public static function init() {\n register_setting( 'wporg_settings', 'wporg_option_foo' );\n }\n\n public static function get_foo() {\n return get_option( 'wporg_option_foo' );\n }\n }\n\n WPOrg_Plugin::init();\n WPOrg_Plugin::get_foo();\n}<\/code><\/pre>\n\n\n\nFile Organization<\/h2>\n\n\n\n
plugin-name.php<\/code> file and, optionally, your uninstall.php<\/a> file. All other files should be organized into sub folders whenever possible.<\/p>\n\n\n\nFolder Structure<\/h3>\n\n\n\n
\/plugin-name\n plugin-name.php\n uninstall.php\n \/languages\n \/includes\n \/admin\n \/js\n \/css\n \/images\n \/public\n \/js\n \/css\n \/images\n<\/pre>\n\n\n\n
Plugin Architecture<\/h2>\n\n\n\n
Conditional Loading<\/h3>\n\n\n\n
if ( is_admin() ) {\n \/\/ we are in admin mode\n require_once __DIR__ . '\/admin\/plugin-name-admin.php';\n}<\/code><\/pre>\n\n\n\nAvoiding Direct File Access<\/h3>\n\n\n\n
ABSPATH<\/code> global is not defined. This is only applicable to files which contain code outside of class or function definitions, such as the main plugin file.<\/p>\n\n\n\nif ( ! defined( 'ABSPATH' ) ) {\n\texit; \/\/ Exit if accessed directly\n}<\/code><\/pre>\n\n\n\nArchitecture Patterns<\/h3>\n\n\n\n
\n
Architecture Patterns Explained<\/h3>\n\n\n\n
\n
Boilerplate Starting Points<\/h2>\n\n\n\n
\n