Comment déprécier une fonction utilisée dans un plugin?

17

L'une des fonctions que j'utilise dans mon plugin pollue la portée globale avec un nom qui pourrait entrer en collision avec une autre fonction (utilisée dans un autre plugin). Donc, je suppose que je devrais le déprécier. Mais comment dois-je procéder?

function foo() {
    echo 'bar';
}

Je suis au courant, _deprecate_function()mais je serais reconnaissant pour un exemple montrant toutes les étapes à suivre pour supprimer la fonction du cœur de mon plugin.

Réf: https://developer.wordpress.org/reference/functions/_deprecated_function/

Henrywright
la source
Bonne question, mais est-il peut-être temps de nommer votre plugin? Vous pouvez toujours appeler le nouvel espace de noms à partir de votre fonction obsolète ...
brianlmerritt
L'espace de noms est une option que je veux explorer mais pas tout à fait décidée si je dois encore abandonner le support de PHP 5.2.
henrywright
Charger l'alternative obsolète si la version de php est trop faible mais que l'espace de noms pourrait autrement vous donner un chemin de transition. Votre message obsolète peut alors être "votre hébergeur ne prend pas en charge PHP 5.3+ blah blah etc"
brianlmerritt

Réponses:

11

En plus de la réponse de @Welcher:

Il y a quelques bons exemples de " cimetière " dans le noyau, où "les fonctions viennent à mourir ".

Vous pouvez les utiliser comme lignes directrices, par exemple en ce qui concerne la documentation.

Voici un exemple pour le permalink_link()sous lewp-includes/deprecated.php

/**
 * Print the permalink of the current post in the loop.
 *
 * @since 0.71
 * @deprecated 1.2.0 Use the_permalink()
 * @see the_permalink()
 */
function permalink_link() {
        _deprecated_function( __FUNCTION__, '1.2', 'the_permalink()' );
        the_permalink();
}

Voici la documentation en ligne de la _deprecated_functionfonction qui explique les arguments d'entrée:

/**
 * Mark a function as deprecated and inform when it has been used.
 *
 * There is a hook deprecated_function_run that will be called that can be used
 * to get the backtrace up to what file and function called the deprecated
 * function.
 *
 * The current behavior is to trigger a user error if WP_DEBUG is true.
 *
 * This function is to be used in every function that is deprecated.
 *
 * @since 2.5.0
 * @access private
 *
 * @param string $function    The function that was called.
 * @param string $version     The version of WordPress that deprecated the function.
 * @param string $replacement Optional. The function that should have been called. 
 *                            Default null.
 */
Birgire
la source
1
Merci pour cela. Je n'ai pas pensé à regarder l'approche adoptée par core! Je suppose donc que ce sont les étapes que je devrais prendre? 1) supprimer tout le contenu d'origine de ma fonction 2) ajouter un appel à _deprecated_function()3) ajouter un appel à ma nouvelle fonction qui remplace l'ancienne
henrywright
1
Cela ressemble à un problème bilatéral discuté ici - dépréciation et possible collision de noms. Je n'ai abordé la première partie ici qu'en fonction du titre de la question.
birgire
1
@MarkKaplun Je suis d'accord qu'il y a 2 problèmes en cours. La question était de savoir comment déprécier la fonction et c'est sur quoi ma réponse était basée. L'avis __doing_it_wrong est destiné aux développeurs qui appellent cette méthode dans leurs thèmes, etc. pour leur permettre de réagir aux modifications de l'API plutôt que de simplement filtrer le site en blanc. Log Deprecated Notices est un excellent plugin de développement qui vous permet de rester à jour avec les modifications de base et aiderait également dans ce cas.
Welcher
1
@MarkKaplun Je vois votre point. Je dirais cependant qu'une partie de la dépréciation consiste à maintenir la compatibilité descendante jusqu'à ce que l'élément soit supprimé de l'API. Le but de l'avis (quelle que soit la méthode utilisée pour le générer) est d'informer les développeurs utilisant la méthode qu'elle sera supprimée et de leur donner le temps d'agir en conséquence. La façon de déprécier quelque chose est de le mettre en évidence et de le supprimer, la bonne façon est de donner d'abord la tête aux utilisateurs :)
Welcher
2
@MarkKaplun Je ne sais pas trop contre quoi vous vous opposez (ou pour quoi?). La question était de savoir comment déprécier une méthode et c'est clair du fait que l'OP dit "mon plugin" sait ce que la dépréciation signifie qu'il est développeur. L'utilisateur imaginaire dont vous parlez n'a rien à voir avec cette question spécifique. Si vous craignez d'obtenir un million d'avis dans le journal, les méthodes en question ne sortent que si WP_DEBUG est activé et, à votre avis, cela ne serait pas activé par des non-développeurs et certainement pas en production. Je vais respectueusement juste accepter de ne pas être d'accord pour passer à autre chose :)
Welcher
7

La dépréciation n'est pas toujours égale à la suppression, cela signifie généralement que l'élément est marqué pour une suppression EVENTUELLE de l'API. Est-ce une méthode qui sera appelée en externe - comme par d'autres plugins ou développeurs? Si cette méthode n'est utilisée que par le plugin en interne, vous pouvez probablement le supprimer en toute sécurité en le remplaçant par une meilleure fonction de nom.

Sinon, je créerais la fonction la mieux nommée et je demanderais à celle qui est mal nommée de l'appeler avec un __doing_it_wrongappel - lisez-la dans le codex Cela donnera aux autres développeurs le temps de mettre à jour leurs références à la méthode et vous pouvez supprimer la méthode en toute sécurité dans une version ultérieure.

function badly_named() {

    __doing_it_wrong( 'badly_named', 'This method has been deprecated in favor of better_named_function' );

    /**
     * Call the better named method
     */
     better_named_function();
}

J'espère que cela t'aides!

Welcher
la source
Merci pour cela, mais je pense que je devrais copier comment le faire. Jetez un œil à la réponse de @birgire pour un exemple
henrywright
Ça me semble bien :)
Welcher
1

Vous créez un nouveau plugin et conseillez à vos utilisateurs de migrer vers celui-ci car celui-ci est EOL.

Il n'y a rien de plus ennuyeux que les auteurs de plugins et de thèmes changeant leurs API publiques et essayant de les traiter comme "juste une autre petite mise à jour". Il n'y a aucune raison de casser des sites en raison d'un problème qui n'affecte pas réellement vos utilisateurs.

Mark Kaplun
la source
Mes utilisateurs seraient totalement affectés par cela si un autre plugin avait une fonction avec exactement le même nom (et n'utilisait pas d'espaces de noms).
henrywright
Non, l'activation du plugin échouera et ils se plaindront à vous ou à l'auteur de l'autre plugin. Temps de perturbation total d'environ zéro. S'ils ont besoin des deux plugins, la mise à niveau vers un nouveau ne devrait pas prendre plus de 15 minutes sans interruption du fonctionnement du site. Ce que vous voulez, c'est que certains de vos utilisateurs mettent à niveau et découvrent que certaines fonctionnalités ne fonctionnent plus sans préavis. Il est temps de réparer? pensez-vous qu'ils ont une sauvegarde du tout et peuvent la réparer?
Mark Kaplun
Une fois que vous avez créé une API, vous devez continuer à la prendre en charge pour toujours ou du moins jusqu'à ce qu'elle soit totalement hors de propos, WordPress par exemple n'a en fait supprimé aucune des API obsolètes depuis la 3.4, et l'ajout d'un avis ne vous fera aucun bien.
Mark Kaplun
1
+1 parce que je respecte votre opinion et ce que j'aime sur ce site sont les différentes vues, approches et solutions aux problèmes, car il n'y a généralement pas de taille unique qui convient à tous.
birgire
1

Je suggérerais quelque chose comme:

/**
 * @deprecated Please use good_function_name() instead
 * @since x.y.z Marked deprecated in favor of good_function_name()
 * @see good_function_name()
 */
function bad_function_name() {
    trigger_error(
        'The ' . __FUNCTION__ . ' function is deprecated. ' .
        'Please use good_function_name() instead.',
        defined( 'E_USER_DEPRECATED' ) ? E_USER_DEPRECATED : E_USER_WARNING
    );

    return good_function_name();
}

Cela a pour effet d'afficher un avertissement de dépréciation dans les journaux avec une trace de pile. Naturellement, cela ne fonctionnera que si la journalisation est activée dans WordPress.

L'opérateur ternaire est là car la constante E_USER_DEPRECATED n'a été introduite qu'en PHP 5.3.0. Dans les anciennes versions, nous pouvons plutôt recourir à un simple avertissement utilisateur.

Du manuel PHP sur les constantes d'erreur :

E_DEPRECATED Avis d'exécution . Activez cette option pour recevoir des avertissements sur le code qui ne fonctionnera pas dans les futures versions.

La raison pour laquelle je n'aime pas utiliser _doing_it_wrong ou __deprecated_function est que ces fonctions sont destinées uniquement au noyau WordPress. De la référence de code sur ces fonctions:

L'accès à cette fonction est marqué comme privé. Cela signifie qu'il n'est pas destiné à être utilisé par les développeurs de plugins ou de thèmes, uniquement dans d'autres fonctions de base. Il est répertorié ici pour être complet.

alexg
la source
1
C'est un point +1 totalement valide - nous pouvons cependant voir que des plugins comme Woocommerce utilisent les deux fonctions . indépendamment.
birgire