Comment personnaliser un plugin tout en conservant la possibilité de mise à niveau

Je travaille actuellement sur une mise à jour majeure d'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 ce skin ne soit supprimé lors de la mise à niveau, je dois utiliser un hook WordPress pour désactiver les mises à jour automatiques du plugin. Ce n'est évidemment pas idéal car je voudrais qu'ils puissent toujours mettre à jour le plugin. Le problème est la façon dont WordPress gère 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, la seule façon de me déplacer est d'avoir deux dossiers de skins - un dans le dossier des plugins et un dans le dossier des téléchargements - est-ce vraiment la seule façon de proposer cela à mes utilisateurs?

De nombreux plugins utilisent /wp-content/custom-plugin-folder/pour stocker des données de plugins personnalisées (WPTouch me vient à l'esprit).

Utilisez simplement les constantes WP_CONTENT_URLet les WP_CONTENT_DIR ^documents pour vérifier l'existence de votre dossier et récupérer tous les skins disponibles.

L'article suivant, bien qu'il ne soit pas directement lié à cette question, explique l'importance pour les plugins / thèmes de rechercher les traductions d' abord dans le wp-content/languagesdossier avant de charger ses propres .mofichiers empaquetés . C'est une lecture intéressante et j'espère que vous appliquerez le concept dans votre prochaine version :)

Charger les fichiers de langue WordPress de la bonne manière Je voudrais 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 secours pour les chaînes non traduites par l'utilisateur.
^{http://www.geertdedeckere.be/}

L'autre façon est de demander aux gens d'ajouter leur propre sous-plugin. Par exemple, le code de votre plugin principal qui obtient les skins pourrait être quelque chose comme:

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 plugin personnalisé qui se trouve à côté du vôtre (activé séparément afin qu'il n'interfère pas avec votre mise à jour) qui effectue 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 de la même manière que WordPress utilise des 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é, ou comment vous avez codé les choses, vous devrez donc utiliser le code ci-dessus simplement comme modèle pour savoir comment refactoriser votre propre code.)}