5

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?

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?

2
  • Couldn't you disable the update process for just that plugin you have created? This Thread shows how to go about it.
    – josh
    Commented Oct 29, 2013 at 10:32
  • @josh: naturally, but I was hoping there was some kind of flag I wasn't aware of nowadays. My WP-fu is a bit rusty. Commented Oct 29, 2013 at 10:45

4 Answers 4

5

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.

8
  • Just to confirm: they've yet to add some kind of flag or repo information or something that I could toss in the plugin's description to avoid the problem altogether? Commented Oct 29, 2013 at 11:26
  • I don't get your doubt... IIRC, what Otto said is that there are a number of factors that weight when checking for updates, not only the name (but Description is not one of them). . . . I'll update the A.
    – brasofilo
    Commented Oct 29, 2013 at 11:28
  • My doubt is so: 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). My WP-fu is a bit rusty, but I was kind of hoping that, by now, WP would 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. Commented Oct 29, 2013 at 11:53
  • Not that I'm aware of. As your example demonstrates, simply a different slug is not enough. What if you set your version to 9999 or yyyy.mm.dd which is more logical and not so used? Oh, would be nice if you added this explanation to the Q.
    – brasofilo
    Commented Oct 29, 2013 at 11:56
  • 1
    Quite promising tickets to fine tune this process, I've added them to WPSE#56968.
    – brasofilo
    Commented Oct 29, 2013 at 12:21
1

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
  • 1
    Thanks for the code that may help in future.+1 @brasofilo
    – sun
    Commented Oct 29, 2013 at 10:40
  • Yep, it's a simple step, but effective. The matter is when it's a plugin to use in our own sites, we want that specific name for us. So, please, WP, bug me not, this one is mine ;)
    – brasofilo
    Commented Oct 29, 2013 at 10:50
  • I don't think that's an adequate solution, because there's no way to guarantee that there won't be a conflicting plugin in the future. In fact, an attacker could intentionally create a matching plugin in order to install arbitrary code on your server.
    – Ian Dunn
    Commented Jul 11, 2016 at 18:07
1

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.

14
  • 1
    You're in charge of maintaining that script, or at least partially authored it, correct? If so, there might be a bug in it, because the Plugin URI is most definitely filled in: pastebin.com/NXTHWxQs - WP confuses it with wordpress.org/plugins/googleanalytics Commented Oct 29, 2013 at 14:09
  • 2
    That is a bug from my view point. How about adding some kind of "Private: True" plugin header, or at least making sure that the slug and/or authors match before assuming A is in fact B? I mean, heck, I've been hacking into the WP API ever since it's been around, and the only thing I've ever needed to hack into it for was to disable false positives — of which there are way, way, way too many when you're dealing with custom-designed plugins. Commented Oct 29, 2013 at 18:55
  • 2
    So, in other words, you're saying that: if we don't know of a plugin in the wp.org repo, and some other plugin by some random coder with a random other slug has the same name (which is increasingly likely) and a higher version, we just toss in an update notice to make end-users upgrade to some random thing they never asked for and lose functionality in the process. Bravo. *Clap! Clap!* Great service for end-users. Commented Oct 29, 2013 at 19:33
  • 1
    The ticket being referred to is core.trac.wordpress.org/ticket/10814, if anyone is interested.
    – Ian Dunn
    Commented Jul 11, 2016 at 18:13
  • 1
    Also, core.trac.wordpress.org/ticket/32101
    – Ian Dunn
    Commented Jul 12, 2016 at 6:50
0

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.