UPA Org Issues

[RHSRSK]

Internationalization: Don't use variables or defines as text, context or text domain parameters.

In order to make a string translatable in your plugin you are using a set of special functions. These functions collectively are known as "gettext".

There is a dedicated team in the WordPress community to translate and help other translating strings of WordPress core, plugins and themes to other languages.

To make them be able to translate this plugin, please do not use variables or function calls for the text, context or text domain parameters of any gettext function, all of them NEED to be strings. Note that the translation parser reads the code without executing it, so it won't be able to read anything that is not a string within these functions.

For example, if your gettext function looks like this... esc_html__( $greetings , 'plugin-slug' ); ...the translator won't be able to see anything to be translated as $greetings is not a string, it is not something that can be translated. You need to give them the string to be translated, so they can see it in the translation system and can translate it, the correct would be as follows... esc_html__( 'Hello, how are you?' , 'plugin-slug' );

This also applies to the translation domain, this is a bad call: esc_html( 'Hello, how are you?' , $plugin_slug ); The fix here would be like this esc_html( 'Hello, how are you?' , 'plugin-slug' ); Also note that the translation domain needs to be the same as your plugin slug.

What if we want to include a dynamic value inside the translation? Easy, you need to add a placeholder which will be part of the string and change it after the gettext function does its magic, you can use printf to do so, like this: printf( / translators: %s: First name of the user / esc_html__( 'Hello %s, how are you?', 'plugin-slug' ), esc_html( $user_firstname ) );

You can read https://developer.wordpress.org/plugins/internationalization/how-to-internationalize-your-plugin/#text-domains for more information.

Example(s) from your plugin:

wp-user-profile-avatar/templates/wp-display-user-avatar-list.php:57 esc_html__('No avatars available');

Generic function/class/define/namespace/option names

All plugins must have unique function names, namespaces, defines, class and option names. This prevents your plugin from conflicting with other plugins or themes. We need you to update your plugin to use more unique and distinct names.

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() class ECPT_Admin{} namespace ECPT; update_option( 'ecpt_settings', $settings ); define( 'ECPT_LICENSE', true ); global $ecpt_options;

Don't try to use two (2) or three (3) letter prefixes anymore. We host nearly 100-thousand plugins on WordPress.org alone. There are tens of thousands more outside our servers. Believe us, you’re going to run into conflicts.

You also need to avoid the use of _ (double underscores), wp , or _ (single underscore) as a prefix. Those are reserved for WordPress itself. You can use them inside your classes, but not as stand-alone function.

Please remember, 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 don't want to break WordPress for your users.

Related to this, using if (!function_exists('NAME')) { 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 should be reserved for shared libraries only.

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.

Analysis result:

Looks like there are elements not using common prefixes.

wp-user-profile-avatar/wp-user-profile-avatar-functions.php:469 function delete_comments_everywhere wp-user-profile-avatar/wp-user-profile-avatar-functions.php:487 function delete_comments_by_post_types

[RHSRSK]

This is already done in https://github.com/wpeventmanager/wp-user-profile-avatar/issues/133

[mistry-jignesh]

This issue is covered in the #133 .So I am closed the issue.