Je suis un programmeur expérimenté, mais un développeur WordPress complètement inexpérimenté. J'essaie de comprendre comment créer un en-tête qui s'affiche uniquement pour les appareils mobiles et comment modifier les propriétés de cet en-tête à partir de la zone des paramètres du tableau de bord.
Je suppose que je devrais utiliser la fonction wp_is_mobile();
pour tester mobile. Je suis juste un peu vert sur la façon de mettre en œuvre cela dans WordPress. Mes principales questions sont les suivantes:
Dernière question, où devrais-je mettre ce code? Je suis sûr que cela dépend de quelques réponses précédentes, c'est pourquoi j'ai posé la dernière question!
Dernier point à souligner, je sais que je pourrais le faire en modifiant directement l’appel de la fonction get_header()
, mais du peu de lecture que j’ai faite, je ne pense pas que je veuille faire cela. Corrige moi si je me trompe!
Merci pour l'aide. Je ne cherche pas pour que cela soit écrit pour moi. Je suis juste perdu dans une mer de WordPress en ce moment et je cherche une boussole!
Je sais donc maintenant que j’ai besoin de cela en tant que plug-in. Par conséquent, pour la révision rapide de ma question, comment puis-je écrire un plug-in capable de modifier la tête du modèle sans la possibilité qu'il soit écrasé par une nouvelle version de wordpress ou un nouveau thème ou un thème enfant?
Je ne répondrai pas à vos questions dans l'ordre, mais d'une manière qui me permette de suivre facilement un chemin logique.
Je suppose que je devrais utiliser wp_is_mobile ();
wp_is_mobile()
est un bon choix. D'après mon expérience, il reconnaît la majorité des appareils mobiles, et si vous ne vous souciez pas d'un pourcentage d'ipotétique et que très peu d'appareils ne sont pas reconnus, vous pouvez le prendre et continuer.
Dernier point à souligner, je sais que je pourrais le faire en modifiant directement l’appel de la fonction get_header (), mais je ne pense pas que je veuille faire cela. Corrige moi si je me trompe!
Tu as parfaitement raison. Si vous modifiez get_header()
, la prochaine fois que WordPress sera mis à jour, votre modification sera perdue. Et je parie que tu n'en veux pas.
Je crois que je dois accrocher le crochet d'action
'wp_head'
ou'activate_wp_head'
, est-ce correct?
Et bien non. Ce dernier est complètement indépendant, car il se déclenche dans la page d'activation du site. Le premier se déclenche sur les pages frontales classiques, mais à l'intérieur de la balise <head>
(généralement juste avant sa fermeture), mais vous souhaitez générer un résultat, de sorte qu'il passe à l'intérieur de <body>
, de sorte que hook ne puisse pas vous aider.
Malheureusement, il n’existe pas de méthode standard pour implémenter des éléments dans le corps de modèles, c’est complètement le territoire du thème.
Cependant, la grande majorité des thèmes WordPress utilisent une get_header()
et, d'après OP, votre thème ne fait pas exception.
La possibilité d’agir sur ces fonctions est multiple, le premier et le plus simple est de modifier directement le fichier modèle et, là où il y a get_header()
, changez-le en:
if ( wp_is_mobile() ) {
get_header( 'mobile' );
} else {
get_header();
}
comme vous pouvez le voir dans docs , get_header()
accepte un argument optionnel modifiant le fichier requis. En fait, get_header()
appelée sans argument nécessite un fichier nommé header.php
à la racine du thème, mais si vous transmettez une chaîne, un fichier nommé header-{$name}.php
est nécessaire.
En passant une chaîne, vous pouvez lui faire charger un fichier personnalisé et y mettre tout ce que vous voulez générer (probablement en copiant principalement à partir de header.php
); et vous avez terminé.
Cette approche nécessite que vous agissiez directement sur le fichier de modèle. Si vous êtes le développeur du thème, vous pouvez envisager cette approche, mais si votre thème provient de quelque part (téléchargé, acheté ..), je suggère de ne pas le faire, parce que le thème peut être mis à jour par le développeur, et si vous avez édité les fichiers d'origine, c'est un gros problème.
Outre le problème de mise à jour nécessitant cette approche, vous devez modifier tous les modèles qui appellent get_header()
, par exemple. index.php
, single.php
... et tous les autres modèles fournis par votre thème.
En tant que programmeur expérimenté, vous savez sûrement que répéter des choses n’est pas une bonne chose.
Le thème de l’enfant est certainement meilleur.
Quelques lignes ci-dessus, j'ai dit que get_header()
requiert header.php
du dossier racine du thème.
Ce n'est pas complètement vrai.
Si le thème actuel est un thème enfant, cette fonction recherche tout d'abord un fichier header.php
dans le dossier du thème enfant. S'il n'y figure pas, chargez celui du thème parent (et s'il ne le contient pas, chargez un fichier fourni avec core).
Cela signifie que si vous construisez un thème enfant, vous pouvez créer un header.php
personnalisé et, grâce à une condition if ( wp_is_mobile() )
, vous pouvez faire différentes choses pour les appareils mobiles: de cette manière, tout modèle appellera get_header()
nécessitera votre fichier au lieu de l'original. un.
De plus, si le thème parent est mis à jour, vous pouvez obtenir la mise à jour sans problème. La page liée du Codex devrait contenir suffisamment d’informations pour vous permettre de créer un thème enfant: c’est très simple, en effet.
Cela semble une solution parfaite, mais il existe une possibilité: vous utilisez déjà un thème enfant et vous ne pouvez pas le modifier car il est développé par une tierce partie et vous ne voulez pas perdre (pour de bonnes raisons) la possibilité de toute mise à jour.
Malheureusement, dans WordPress, vous ne pouvez pas créer un thème enfant d'un thème enfant, votre seule option est donc de créer un plugin .
Ce ne sera pas facile, pas parce que construire un plugin est difficile, mais plutôt facile, le problème est que get_header()
n’est pas filtrable, et que votre seule chance est de créer une sorte de "faux" thème mettant tous les modèles dans le dossier du plugin et utilisez 'template_include'
filter hook pour créer des modèles de chargement WordPress à partir de votre plug-in au lieu d'un thème.
J'ai été obligé de faire quelque chose comme ça pour un travail de client, et c'était frustrant.
Quelque chose à propos de la construction d'un plugin pour le scope.
Normalement, un plugin doit être indépendant du thème actuel, car si le thème de changement d'utilisateur est activé, les plugins sont toujours actifs et continuent de fonctionner. Mais si un plugin, comme dans votre cas, doit contenir des fichiers de gabarit, considérez-le comme indépendant du thème, ce qui est assez trompeur.
La meilleure solution consiste à examiner tous les fichiers de modèles de vos thèmes (comme indiqué précédemment, ce plugin est connecté au thème), mais vous n'avez pas besoin de consulter tous les fichiers , mais seulement aux modèles de premier niveau .
Les modèles de premier niveau sont ceux qui sont directement chargés par WordPress.
Regardez hiérarchie modèle, les modèles de premier niveau sont ceux qui y sont mentionnés.
Il est très rare qu'un thème les ait tous. Notez donc les modèles utilisés par votre thème.
Grâce au filtre 'template_include'
mentionné quelques lignes ci-dessus, vous pouvez forcer WordPress à charger un autre fichier au lieu de celui qu’il charge normalement.
Juste un exemple approximatif. Supposons que vous visitez l'URL pour un message singulier. WordPress charge normalement le fichier single.php
dans votre thème pour afficher le contenu.
Si votre plugin contient:
add_action( 'template_include', function( $template ) {
if ( is_single() ) {
$template = plugin_dir_path( __FILE__ ) . 'single.php';
}
return $template;
} );
Les fonctions accrochées 'template_include' (une fonction anonyme, ci-dessus) reçoit en argument le fichier modèle que WordPress va charger, et quoi qu’il retourne, il sera chargé par WordPress.
Dans l'extrait de code ci-dessus, j'ai vérifié si la requête en cours concernait une publication unique et, dans ce cas, chargez le fichier 'single.php'
à partir du dossier du plug-in.
Si vous devez répéter pour tous les types de requêtes (is_page()
, is_archive()
, is_search()
et ainsi de suite), c'est écrasant, mais si dans votre dossier de plug-ins vous avez une version de all la 1ère modèles de niveau utilisés par votre thème, vous pouvez faire quelque chose comme:
add_action( 'template_include', function( $template ) {
$template = plugin_dir_path( __FILE__ ) . basename( $template );
return $template;
} );
Ces quelques lignes de code remplacent complètement les fichiers de thème et obligent WordPress à toujours charger les modèles, nommés de la même manière, mais dans votre dossier de plug-in, au lieu du premier thème.
Maintenant, que doivent contenir les fichiers de votre dossier de plug-in? Là, vous devriez essayer d’écrire le moins possible, mais cela dépend vraiment de votre thème.
Supposons que le single.php
de votre thème ne contienne que:
get_header();
get_template_part( 'navigation' );
get_template_part( 'content', get_post_type() );
get_sidebar();
get_footer();
C'est une très bonne chose pour vous, car vous pouvez le copier dans votre dossier plug-in et le modifier comme suit:
if ( wp_is_mobile() ) {
require_once . plugin_dir_path( __FILE__ ) . 'mobile-header.php';
} else {
get_header();
}
get_template_part( 'navigation' );
get_template_part( 'content', get_post_type() );
get_sidebar();
get_footer();
Ainsi, presque tout le contenu est encore chargé depuis le thème car get_header()
get_template_part()
, get_sidebar()
et get_footer()
chargez les modèles de dossier de thème de formulaire et vous ne remplacez l'en-tête que pour les appareils mobiles.
Mais si les fichiers de modèles de votre thème contiennent beaucoup de balises HTML, la seule solution est de copier et coller ces balises dans les modèles de plug-in.
Les mauvaises choses sont:
lorsque vous changez de thème, vous devez réécrire complètement votre plugin, ou si le nouveau thème que vous installez n'est pas un thème enfant, il vaut mieux supprimer votre plugin et opter pour façon thème enfant .
si le thème est mis à jour, votre plugin ne sera pas touché de quelque manière que ce soit, mais probablement, si la mise à jour a modifié le balisage des modèles de thème (ce n'est pas certain, souvent, les mises à jour de thème sont destinées à des bogues dans functions.php
) dont vous aurez probablement besoin pour mettre à jour le balisage dans vos modèles de plugin aussi.
Oui, c'est annulant, et maintenant vous connaissez la raison de ma frustration que j'ai mentionnée ci-dessus.
Dernière question, où devrais-je mettre ce code? Je suis sûr que cela dépend de quelques réponses précédentes, c'est pourquoi j'ai posé la dernière question!
Comme indiqué ci-dessus, si votre thème actuel n'est pas un thème enfant ou un thème enfant que vous avez développé par vous-même, le simple ajout ou la modification de header.php
fera l'essentiel du travail.
En ce qui concerne la partie qui visualise et enregistre les options, cela peut être fait dans un ou plusieurs fichiers requis du thème enfant functions.php
si vous pouvez opter pour le thème enfant, sinon il ne peut s'agir que d'un ou de plusieurs fichiers du plugin.
Je souhaite définir des couleurs pour les couleurs d'arrière-plan et de police dans la zone des paramètres du tableau de bord. Comment puis-je faire cela?
Je ne peux que suggérer Paramètres WordPress API . Dans la page liée du Codex, vous devez trouver suffisamment d’informations pour pouvoir commencer à le coder. Consultez également les liens dans la "Références externes" paragraphe, vous y trouverez des exemples et clarifications.
Une fois que vous avez réussi à faire fonctionner votre page de paramétrage, vous pourrez obtenir tous les paramètres de votre en-tête avec un seul appel get_option()
et les utiliser pour créer votre en-tête personnalisé.