web-dev-qa-db-fra.com

Quels thèmes utilisez-vous pour tester la compatibilité avec votre plugin?

Lors du développement d'un plugin, je le teste habituellement avec les thèmes suivants avant la publication:

  • TwentyTen par Automattic
  • TwentyEleven par Automattic
  • Coraline par Automattic
  • Duster de Automattic
  • Hybrid par Justin Tadlock
  • Nouvelles de Justin Tadlock
  • Prototype de Justin Tadlock
  • Rénové par Justin Tadlock
  • Responsive par ThemeID
  • PageLines par PageLines
  • Crème au beurre par Caroline Moore
  • Catch Box par Catch Themes Team
  • Suffusion de Sayontan Sinha

Existe-t-il d'autres recommandations sur lesquelles vous devriez tester votre plugin pour vérifier la compatibilité?

plugin-developmentthemescompatibility
1
onokazu

Des thèmes, n'importe qui?

Je ne teste pas "contre" ou "avec" des thèmes. Juste avec quelques autres plugins qui pourraient entrer en conflit (mais je le laisse normalement ouvert jusqu'à ce que quelque chose se passe - vous ne saurez jamais tous les cas Edge).

Au moins, vous interceptez/prolongez/modifiez des éléments via des filtres. Alors pourquoi tester sur des thèmes, lorsque vous modifiez les fonctions principales ?

Si vous interceptez le filtre the_content par exemple, pourquoi devriez-vous jeter un coup d'œil aux thèmes? S'ils sautent à la priorité 99999999, alors vous êtes de toute façon trop tard et la possibilité qu'ils le changent dans une autre version est si élevée que vous ne pourrez pas le suivre de toute façon.

Imaginez que vous vérifiiez chaque filtre - avec par exemple la variable all- - sautez dedans et déplacez vos priorités jusqu'à ce qu'il n'y ait plus aucune chance de le manquer, puis vous mettriez le système à terre. C'est possible . Mais cela ne fonctionne pas en direct.

Déboguer

WordPress , ainsi que PHP a eu un tas de choses sur la gestion des erreurs sur planche. Cela signifie que tout ce qui échoue sera affiché - tant qu'il est activé. Faites cela dans tous les cas dans votre copie locale ... et abandonnez en code live !

Dump sortie

Mon meilleur conseil est de vous créer simplement un environnement de débogage très soigné et facile. Lorsque j'écris mes classes, j'ajoute normalement une sortie de débogage à toute méthode contenant. Cela me permet de voir ce qui se passe et quand cela se produit.

Pourquoi est-ce que je fais cela?

Simple: Des erreurs se produiront à une étape . Donc, normalement, vous commenceriez à ajouter des points à arrêter, à regarder les données en sortie/renvoyées, puis à avancer jusqu'à ce que l'erreur soit détectée. Je me simplifie simplement la vie avec un simple commutateur qui me permet de sortir ces données échelonnées: un onglet de ma méta-boîte dans le crochet d'arrêt à la fois. Si le résultat n'est pas ce que j'attendais, alors une erreur/un mauvais morceau de code se produit juste avant.

Vérifier la sortie/retour

debug output

Cela me permet d’intervenir chaque fois que quelque chose échoue. Cela me permet également de reproduire des installations à la erreur et de voir ce qui se passe sans effort supplémentaire.

Crochets de contrôle

L’autre chose que j’utilise souvent var_dump( $GLOBALS['wp_filter'][ current_filter() ]; pour voir ce qui est attaché au crochet, là où je saute actuellement.

Jamais jamais les erreurs de sortie dans les installations en direct

Quand vous regardez comment je l’ai fait avec le plugin "Dynamic image redimensionner" - un plugin qui est un meilleur TimThumb (remplacement) - vois comment j'évite la sortie pour

  • Utilisateurs qui n'ont pas les bons privilèges
  • Propriétaires qui ont oublié de désactiver le débogage par accident
  • Invités

Comme vous pouvez le lire dans le commentaire ci-dessus: Je suppose que personne n’a activé la fonction DEBUG lors de l’utilisation d’un plugin de mise en cache. Dans ce cas: personne ne pourra vous aider.

Conclusion

Au moins c'est Open Source. Et s'il y a vraiment un homme des cavernes qui le fait ... alors ce n'est pas de votre faute si les choses échouent. Vous ne pouvez pas attraper un cas Edge. :)

Un dernier mot

Pourquoi ne pas tester les hameçons manquants, etc.?

Il y a "Normes de développement de thèmes" que chaque thème valide doit suivre. S'ils ne le font pas, ils ne sont tout simplement pas sur mon radar. Imaginez que je donnerais une note avec, par exemple, _doing_it_wrong() pour chaque cas, quelque chose échoue. Cela gonflerait mon code à env. 10 fois la taille d'origine - sans attraper tout ce qui pourrait être mal écrit.

Maintenant, imaginez que quelqu'un ait un thème vraiment merdique et que je lui envoie 10 messages avec un plugin. Que se passerait-il si nous nous préoccupions tous de cela? 1 000 messages?

3
kaiser

Je teste avec:

  • Vingt dix
  • Vingt onze
  • Crème au beurre
  • PageLines
  • Un thème de la genèse
  • Un thème Wootheme

  • Quelques thèmes personnalisés que j'ai créés (et que je publierai à un moment donné) ont été délibérément conçus pour tester les plugins en faisant les choses de la mauvaise façon. Certaines des choses que je teste parce qu'il y a trop de mauvais auteurs de thèmes:

    • Espace blanc/contenu avant get_header
    • Pas de get_header
    • Pas de wp_head
    • Remplacez la version fournie avec jQuery par une ancienne version de fu *** up dans le panneau d'administration
    • Bannières ridiculement grandes insérées automatiquement après le titre de la page du plugin - oui, je vous regarde, JetPack
    • Activer error_reporting (E_ALL)

Je teste également tous les plugins de mise en cache populaires (ils aiment tout gâcher)

EDIT: Oh et les plugins qui fournissent une version mobile du site.

0
Daniel Chatfield