Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

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?

share|improve this question
    
Couldn't you disable the update process for just that plugin you have created? This Thread shows how to go about it. –  josh Oct 29 '13 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. –  Denis Oct 29 '13 at 10:45

4 Answers 4

up vote 3 down vote accepted

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.

share|improve this answer
    
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? –  Denis Oct 29 '13 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 Oct 29 '13 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. –  Denis Oct 29 '13 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 Oct 29 '13 at 11:56
1  
Quite promising tickets to fine tune this process, I've added them to WPSE#56968. –  brasofilo Oct 29 '13 at 12:21

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.

share|improve this answer
1  
Thanks for the code that may help in future.+1 @brasofilo –  sun Oct 29 '13 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 Oct 29 '13 at 10:50

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
share|improve this answer

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.

share|improve this answer
    
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 –  Denis Oct 29 '13 at 14:09
    
No bug, you simply are trying to share a name with another plugin that also has a similar name. Choose a more unique name. Prefix it with the site name, that's what I do. The URI is used as a primary, but any match is considered better than no match. If you want it to not match, then it needs to not match on any level. –  Otto Oct 29 '13 at 18:51
    
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. –  Denis Oct 29 '13 at 18:55
    
You're welcome to your viewpoint, however I do not share it. If you are writing plugins and not putting them in the official repository, then you'll probably want to include code to disable the update checks for your plugin, or just name your plugins uniquely. Most plugin authors doing this have no problem with naming, as they want to add "branding" anyway. There are no plans to make a way for plugins to easily not check for updates. Quite the opposite, in fact. –  Otto Oct 29 '13 at 19:13
    
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. –  Denis Oct 29 '13 at 19:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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