web-dev-qa-db-fra.com

Comment personnaliser un plugin tout en maintenant la capacité de mise à jour

Je travaille actuellement sur une mise à jour majeure de l'un de mes plugins WordPress.

Le plugin permet à l'utilisateur de choisir parmi plusieurs skins disponibles. Très souvent, on me demande de créer un skin personnalisé. Pour éviter que cet habillage ne soit supprimé lors de la mise à niveau, je dois utiliser un hook WordPress pour désactiver les mises à jour automatiques du plug-in. Ce n'est évidemment pas idéal car je voudrais qu'ils puissent toujours mettre à jour le plugin. Le problème est la manière dont WordPress traite les mises à jour - il supprime simplement le dossier du plugin et installe la nouvelle version. Supprimant ainsi les fichiers qui ne faisaient pas réellement partie de l'ancienne version.

Actuellement, le seul moyen de contourner ce problème est d'avoir deux dossiers de skins - un dans le dossier du plugin et un dans le dossier des téléchargements - est-ce vraiment le seul moyen de l'offrir à mes utilisateurs?

pluginsupgrade
8
Daniel Chatfield

De nombreux plugins utilisent /wp-content/custom-plugin-folder/ pour stocker des données de plugin personnalisées (on pense à WPTouch).

Il suffit d'utiliser les constantes WP_CONTENT_URL et WP_CONTENT_DIR Docs pour vérifier l’existence de votre dossier et récupérer tous les skins disponibles.

L'article suivant, bien que n'étant pas directement lié à cette Question, explique l'importance pour les plugins/thèmes de rechercher des traductions en premier dans le dossier wp-content/languages avant en chargeant ses propres fichiers .mo empaquetés. Cela vaut la peine d'être lu et j'espère que vous appliquerez le concept dans votre prochaine version :)

Chargement correct des fichiers de langue WordPress
http://www.geertdedeckere.be/
J'aimerais souligner qu'il est important de charger des fichiers de langue utilisateur personnalisés à partir de WP_LANG_DIR avant de charger les fichiers de langue fournis avec le plugin . Lorsque plusieurs fichiers mo sont chargés pour le même domaine, la première traduction trouvée sera utilisée. De cette façon, les fichiers de langue fournis par le plugin serviront de solution de secours pour les chaînes non traduites par l'utilisateur.

4
brasofilo

L'autre façon est de demander aux gens d'ajouter leur propre sous-plugin. Par exemple, le code de votre plug-in principal qui récupère les skins pourrait ressembler à ceci:

function get_available_skins() {
    $skins[] = '/includes/default-skin.css';
    $skins[] = '/includes/2012-skin.css';

    return apply_filters( 'get_available_skins', $skins );
}

Ensuite, les utilisateurs peuvent créer un plug-in personnalisé à côté du vôtre (activé séparément pour ne pas nuire à votre mise à jour) et effectuer les opérations suivantes:

add_filter( 'get_available_skins', 'my_custom_skin' );
function my_custom_skin( $skins ) {
    $skins[] = '/my-custom-skin.css';

    return $skins;
}

C’est exactement la même manière dont WordPress utilise les crochets pour se rendre extensible. Ne réinventez pas la roue.

(Évidemment, je ne sais pas avec quel plugin vous travaillez, à quoi ressemble un skin personnalisé, ni comment vous avez codé les choses, vous devrez donc utiliser le code ci-dessus simplement comme modèle de refactorisation de votre propre code.)

7
EAMann