web-dev-qa-db-fra.com

Comment éviter les conflits de noms de plugins de la notification de mise à niveau?

J'ai préparé un hack rapide en tant que plug-in pour ajouter Google Analytics à mon site. Le nommant "Google Analytics" et, bien sûr, WP m'a proposé de mettre à niveau mon plug-in v0.1 vers un plug-in aléatoire à partir du référentiel de plug-in.

Je me rappelle vaguement avoir été soulevé plusieurs fois autour de WP 2,7 à 3,0. Existe-t-il une nouvelle API disponible quelque part pour désactiver cela, ou la seule façon de l'éviter consiste-t-elle à préfixer les noms de plug-in (non leur nom de fichier, mais leur nom réel, comme indiqué dans l'écran Plugins) pour les rendre uniques?

Dans mon cas d'utilisation spécifique, le plug-in est dans mc-ga/mc-ga.php et s'appelle "Google Analytics", avec quelques autres champs de méta au début de l'en-tête du fichier de plug-in. WP génère un avis de mise à jour basé sur "Google Analytics" (je ne pouvais pas localiser un fichier plug-in mc-ga.php dans le référentiel).

Est-ce que WP permet d'ajouter un champ supplémentaire que je ne connais pas, par exemple. une URL de dépôt ou quelque chose de vraiment unique, afin d'éviter de tels conflits?

pluginsplugin-developmentupgrade
4
Denis de Bernardy

Vous pouvez supprimer votre plugin de la liste updateble avec:

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;
    });
});

L'ajout de ce filtre éliminera complètement notre plugin du même nom des vérifications de mise à jour. Et cela suppose que nous effectuions les mises à jour manuellement via de simples téléchargements FPT ou similaires. Mais il existe de nombreux facteurs, comme indiqué dans Si je renomme un plugin (dans son fichier php principal), ai-je toujours des notifications de mise à jour? . Selon la description de l'OP (même nom, slug différent), sans filtre, le mieux est peut-être de définir l'en-tête du plugin Version sur un nombre supérieur ou d'utiliser un nombre moins conventionnel tel que yyyy.mm.dd.

Si nous établissons notre propre repo , je pense qu’il n’y aura pas de conflit.

5
brasofilo

Ce que je suggère est la suivante: avant de créer votre plugin, vérifiez d’abord si le nom que vous allez donner existe déjà dans Référentiel de plugins WordPress . Sinon, vous pouvez avancer et développer le plugin.

Si cela existe, donnez un nom différent à votre plugin. Étant donné que la mise à niveau est basée sur le nom, vous ne pouvez pas gérer deux plug-ins différents portant le même nom. WordPress effectue cette mise à niveau automatiquement à partir du référentiel officiel.

0
sun

Ajouter celui-ci à la postérité, au cas où quelqu'un d'autre en aurait besoin:

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
0
Denis de Bernardy

Si vous avez un plugin personnalisé pour un site, donnez son nom, le nom du site comme préfixe.

Nous n'allons certainement pas autoriser un plugin nommé "Example.com - Google Analytics" dans le répertoire WordPress.org.

De plus, ajoutez un champ "Plugin URI" à l'en-tête du plugin. Le plugin URI est utilisé dans le cadre du processus de correspondance et fournit quelque chose de plus unique que le nom avec lequel faire correspondre.

0
Otto