Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Names in the global namespace should be prefixed #627

Closed
matiasbenedetto opened this issue May 10, 2024 · 0 comments · Fixed by #628
Closed

Names in the global namespace should be prefixed #627

matiasbenedetto opened this issue May 10, 2024 · 0 comments · Fixed by #628
Assignees

Comments

@matiasbenedetto
Copy link
Contributor

What?

Names in the global namespace should be prefixed.

Why?

This seems to be a requirement enforced on new plugins submitted to the wporg directory.

Reference of the requirement: https://developer.wordpress.org/plugins/plugin-basics/best-practices/

Avoid Naming Collisions

A naming collision happens when your plugin is using the same name for a variable, function or a class as another plugin.

Luckily, you can avoid naming collisions by using the methods below.
Procedural Coding Method

By default, all variables, functions and classes are defined in the global namespace, 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 of functions or classes are not affected by this.
Prefix Everything

All globally accessible code should be prefixed with a unique identifier. Prefixes prevent conflicts with other plugins and prevents them from overwriting your variables and accidentally calling your functions and classes.

In order to prevent conflicts with other plugins, your prefix should be at least 3 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’re going to run into conflicts.

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:

function ecpt_save_post()
define( ‘ECPT_LICENSE’, true );
class ECPT_Admin{}
namespace EasyCustomPostTypes;
update_option( 'ecpt_settings', $settings );

Because you are making code as a part of the WordPress 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: __ (double underscores), wp_ , WordPress, or _ (single underscore)

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).

You can use them inside your classes or namespace, but not as stand-alone function/namespace/class.

If you’re using _n() or __() for translation, that’s fine. We’re only talking about functions you’ve created for your plugin, not the core functions from WordPress. In fact, those core features are why you need to not use those prefixes in your own plugin! You wouldn’t want to break WordPress for your users.

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.

Code that must be prefixed includes:

Functions (unless namespaced)
Classes, interfaces, and traits (unless namespaced)
Namespaces
Global variables
Options and transients
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging a pull request may close this issue.

1 participant