Contribuer au core de WordPress

Contributor day

Aujourd’hui c’était l’ouverture du Wordcamp Europe 2017 et, en ce premier jour, avait lieu le « contributor day ». Un jour spécial où on t’apprend à participer a WordPress.

Mon objectif du jour été d’apprendre à participer au core et si possible soumettre un patch qui, pourquoi pas, soit mergé ( on peut rêver non ? ). J’avais trouvé il n’y a pas longtemps une fonction dont la documentation était incomplète et donc j’avais noté ça au cas où.

L’événement avait lieu dans un des bâtiments des Docks de Paris. Il y avait beaucoup de salles et un domaine de contribution été attribué a chacune. Il y en avait bien plus que ce que je pensais. Je me suis donc installé directement dans la salle réservée au core de WordPress, ça tombe bien c’était la plus grande et également celle où le petit speech d’ouverture avait lieu. On nous a rapidement expliqué comment allait se dérouler la journée et les différents domaines auxquels on pourrait participer.

Core

Enfin on est entré dans le vif du sujet. La salle a été séparée en deux, ceux qui voulaient découvrir et participer au projet Gutenberg, qui est un peu le composant principal de la prochaine version, et ceux qui voulaient juste une introduction sur comment participer. Moi j’étais dans la deuxième moitié. On nous a rapidement expliqué qu’il y avait un workshop pour installer VVV ce qui est un moyen vraiment rapide d’avoir tout ce qu’il faut pour contribuer. Je travaille déjà avec VVV  je suis donc resté et j’ai pu commencer directement. Et voici ce que j’ai appris et ce j’ai pu faire dans la matinée :

  • Découverte du trac et surtout comment chercher et créer un ticket
  • Comment créer et uploader un patch sur un ticket existant
  • Comment télécharger un patch pour pouvoir le tester

C’est exactement ce que voulais apprendre. J’ai pu le faire avec le problème de documentation que j’avais repéré précédemment et le plus beau c’est que mon patch a été mergé au core ! Je suis ravi d’avoir rempli tous mes objectifs de la journée.

Maintenant mes notes et découvertes technique de la journée.

Créer un patch

VVV installe par défaut une version pour pouvoir participer au développement de WordPress. Installer VVV est donc tout ce qu’il faut faire pour avoir un environnement de développement prêt.

VVV utilise une machine virtuelle. Pour commencer on ce connecte donc à la machine virtuel avec la commande :

vagrant ssh

L’installation de WordPress qui nous intéresse est wordpress-develop : on se positionne donc dans le bon dossier :
cd srv/www/wordpress-develop/public_html

svn up Pour être sûr d’avoir la dernière version de WordPress.

Ensuite on fait les changements dans le core de WordPress que l’on souhaite.

svn status Pour vérifier les changements qu’on a fait

Attention si on a créé des fichiers il faut les ajouter au futur patch avec la commande svn add

grunt upload_patch:{tiket_number} C’est la commande magique. Elle appelle une tâche grunt qui crée et upload le patch directement sur le trac et l’attache au bon ticket

Il est préférable après avoir lancé cette commande d’ajouter un commentaire au ticket concerné sur trac pour expliquer ce que fait le patch. C’est également utile car attacher un patch à un ticket ne déclenche aucune notification.

On peut maintenant attendre de voir ce que vont devenir le ticket et le patch.

Sur l’environnement de développement on peut tout remettre à zéro pour pouvoir créer d’autres patchs avec la commande :
svn revert -R *

Tester un patch

Pour tester un patch c’est assez simple. Comme pour créer un patch le mieux est de revenir à la version de développement actuelle de WordPress. Ça se fait facilement avec les deux commandes vu précédemment svn revert -R * et svn up

Ensuite voici la commande magique qui va permettre de télécharger un patch et l’appliquer en local :
grunt patch:{tiket_number}

On peut alors tester le pâtch. C’est vraiment facile avec les taches grunt.

Conclusion

Je suis ravi d’avoir atteint tous mes objectifs ! Un grand merci a Felix Arntz qui a animé notre table.

Merci aussi à l’équipe de savvii avec qui j’ai mangé le midi. Une rencontre très sympathique.

Widget embed latest tweets version 0.5

Une nouvelle version de mon plugin vient d’être poussée sur le dépôt officiel de WordPress. Ce plugin je le rappelle permet d’afficher de façon sympa ses derniers Tweets.

Internationalisation

Une  chose que j’avais envie de faire depuis longtemps. Ca y est le plugin fonctionne correctement pour la traduction. J’en ai profité pour le traduire en français.

Les scripts que si nécéssaire

En revoyant un peu mon code je me suis rendu compte que j’ajoutais mon fichier js sur toutes les pages du site. Horreur. J’ai donc repris tout ça et maintenant le fichier js n’est ajouté que si le widget s’affiche sur la page en question.

Un lien en plus vers la page de réglages

Petit hook cool que j’ai trouvé ici. Cela ajoute un lien vers la page d’option du plugin (ou vers ce que vous voulez) sur la page qui liste vos plugins, à côté du lien « activé/désactivé ».

Pages protégées par mot de passe, modèle de page et personnalisation

Pour un projet j’ai dû jouer un peu avec la fonction bien pratique, native dans WordPress, des pages protégées par un mot de passe.

Comment activer la protection

Lock iconCa se passe dans la partie Publier des pages et articles. C’est une option de Visibilité. Cliquez sur Modifier et vous pouvez alors choisir trois visibilités : Public, protégé par un mot de passe et privé. Si vous choisissez protégé par un mot de passe il vous est demandé de choisir un mot de passe. Une fois celui ci choisi, il ne reste plus qu’à cliquer sur Ok et mettre à jour votre article ou page.

Modèle de page

Ma page était une page un peu particulière car elle affichait une liste de produits. Les produits étant des custom post type. En fait, si je n’avais pas eu besoin de protéger cette page par un mot de passe j’aurais utilisé le template d’archive de mon custom post type. Tout ça pour dire qu’après avoir créé mon modèle de page et l’avoir assigné à ma page protégée, la protection ne marchait plus. Bizarre.
J’ai donc entrepris quelques recherches sur comment marche cette protection et comment je pourrais la faire marcher dans mon modèle de page.
Il s’avère que cette protection filtre la fonction get_the_content(). Si le mot de passe n’a pas été rentré elle change le contenu par un formulaire, sinon la fonction renvoie bien le contenu de la page.
Mon problème c’est que je n’utilise pas cette fonction car j’affiche tout autre chose dans sur cette page. Heureusement, j’ai trouvé la fonction qui me permet de faire ce que je veux post_password_required() c’est cette fonction qui fait la vérification que le mot de passe a bien été renseigné par le visiteur. Je l’utilise donc comme suit :

if( post_password_required() ){
    the_content();
} else {
  //Mon super affichage personalisé
}
Capture du formulaire par défaut pour les pages protégé par mot de passe
Formulaire par défaut pour les pages protégé par mot de passe

Filtrer le titre pour enlever le « Protégé »:

Comme toujours avec WordPress il s’agit de trouver le bon filtre, voilà celui qui marche et comment l’utiliser

function remove_private_title( $title ) {
    // Return only the title portion as defined by %s, 
    // not the additional
    // 'Private: ' as added in core
    return "%s";
}
add_filter( 'protected_title_format', 'remove_private_title' );

Modifier le formulaire

Encore une fois il s’agit de jouer avec un filtre WordPress

function custom_password_prompt($content) {
  $output = $content . 'Et oui je suis protégé et personnalisé'; 
  return $output; 
} 
add_filter('the_password_form', 'custom_password_prompt');

L’idée ici est de créer une chaine de caractère à retourner contenant le code HTML. IL ne faut pas faire d’affichage. Si vous ne voulez pas du tout utliser le contenu créé par WordPress vous devez juste créer au minimum un formulaire comme ceci pour que l’enregistrement du mot de passe fonctionne.

$output = '<form action="' . esc_url( site_url( 'wp-login.php?action=postpass', 'login_post' ) ) . '" method="post">
    <input name="post_password" type="password" />
    <input type="submit" name="Submit" value="ok" />
</form> ';

Vous pouvez y ajouter ce que vous voulez mais il faut garder les « name » des inputs et les réglages du form

Sources

WordPress tinyMCE – Ajout du bouton « next-page »

J’ai trouvé un bout de code pour ajouter simplement le bouton « next-page » dans l’éditeur visuel de WordPress. Je dois confesser que j’ai découvert cette fonction récemment. Le fait d’ajouter la balise « next-page » dans une page permet de créer une pagination au sein de celle-ci. On peut ainsi avoir le contenu de sa page sur plusieurs pages, autant que de balise ajoutée.

Continuer la lecture de « WordPress tinyMCE – Ajout du bouton « next-page » »