How to avoid plugin name conflicts from the upgrade notifier?

1 Views

I’ve wrapped a quick hack as a plugin to add Google Analytics to my site. Named it “Google Analytics” and, sure enough, WP offered me to upgrade my v0.1 plugin to some random plugin from the plugin repo.

I vaguely recall it getting raised a few times around WP 2.7 to 3.0. Is there a new API available somewhere to disable this, or is the only way to avoid it still is to prefix plugin names (not their file name, but their actual name as shown in the Plugins screen) to make them unique?

Read More

In my specific use case, the plugin is in mc-ga/mc-ga.php and is named “Google Analytics”, along with a few other meta fields at the beginning of the plugin file header. WP yields an update notice based on “Google Analytics” (I couldn’t locate a mc-ga.php plugin file in the repo).

Does WP allow to add an extra field I’m not aware of, e.g. a repo URL or something truly unique, so as to avoid such conflicts?

Post Views: 1

Related posts

4 comments

  1. You can remove you plugin from the updateble list with:

    add_action( 'plugins_loaded', function(){
    add_filter( 'site_transient_update_plugins', function ( $value ) 
    {
        if( isset( $value->response['google-analytics/google-analytics.php'] ) )
            unset( $value->response['google-analytics/google-analytics.php'] );
        return $value;
    });
});

    Adding this filter will eliminate our homonymous plugin altogether from update checks. And it supposes that we are doing the updates manually via simple FPT uploads -or similar. But there are many factors, as discussed in If I rename a plugin (in its main php file) do I still get update notifications?. As per the OP description (same name, different slug), without using a filter, maybe the best is to set the plugin Version header to a greater number or using a less conventional number like yyyy.mm.dd.

    If we are setting our own Repo, I believe there won’t be any conflicts.

  2. What I suggest is: before making your plugin, first check whether the name you are going to give already exists in WordPress plugin repository. If not, then you can move forward and develop the plugin.

    Case it exists, give a different name to your plugin. Because the upgrade is based on the name, you can’t manage two different plugins with same name. WordPress does this upgrade option automatically from the official repository.

  3. If you have a plugin that’s custom for a site, then give its name the site’s name as a prefix.

    We’re certainly not going to allow a plugin named “Example.com – Google Analytics” into the WordPress.org directory.

    Additionally, add a “Plugin URI” field to the plugin header. The Plugin URI is used as part of the matching process, and provides something more unique than the name to match against as well.

  4. Adding this one for posterity, in case anyone else needs it:

    if (!defined('STRICTER_PLUGIN_UPDATES')) define('STRICTER_PLUGIN_UPDATES', false);

# ============
# WP Updates
# ============

if (STRICTER_PLUGIN_UPDATES) :

# - Drop plugin upgrades when the slugs don't match

add_filter('site_transient_update_plugins', function($updates) {
    if (!$updates->response) return $updates;

    foreach ($updates->response as $key => $response) {
        $slug = strpos($key, '/') !== false ? dirname($key) : basename($key, '.php');
        if ($slug != $response->slug) {
            unset($updates->response[$key]);
        }
    }

    return $updates;
});

endif; # STRICTER_PLUGIN_UPDATES

Comments are closed.