Tous les éléments HTML possibles doivent être stylisés par votre thème (sauf s’il s’agit d’un thème enfant), à la fois dans le contenu de l’article / de la page et dans le co
- Tableaux, légendes, images, listes, guillemets, etc.
L’ajout de styles faciles à imprimer est fortement recommandé.
- Vous pouvez inclure une feuille de style d’impression avec media = « print » ou ajouter un bloc de support d’impression dans votre feuille de style principale.
Fichier de fonctions
Un thème peut éventuellement utiliser un fichier de fonctions, qui réside dans le sous-répertoire du thème et est nommé functions.php. Ce fichier agit essentiellement comme un plugin, et s’il est présent dans le thème que vous utilisez, il est automatiquement chargé lors de l’initialisation de WordPress (à la fois pour les pages d’administration et les pages externes). Utilisations suggérées pour ce fichier:
- Mettre en file d’attente les feuilles de style et les scripts du thème. Voir wp_enqueue_scripts.
- Activez les fonctionnalités du thème telles que les barres latérales, les menus de navigation, les miniatures de publication, les formats de publication, les en-têtes personnalisés, les arrière-plans personnalisés et autres.
- Définissez les fonctions utilisées dans plusieurs fichiers de modèle de votre thème.
- Configurez un menu d’options, donnant aux propriétaires de sites des options pour les couleurs, les styles et d’autres aspects de votre thème.
Le thème WordPress par défaut contient des fonctions. php qui définit la plupart de ces fonctionnalités, vous pouvez donc l’utiliser comme modèle. Puisque functions.php fonctionne essentiellement comme un plugin, la liste Function_Reference est le meilleur endroit où aller pour plus d’informations sur ce que vous pouvez faire avec ce fichier.
Remarque pour décider quand ajouter des fonctions à functions.php ou à un plugin spécifique: vous pouvez constater que vous avez besoin de la même fonction pour être disponible pour plus d’un thème parent. Si tel est le cas, la fonction doit être créée dans un plugin au lieu d’un functions.php pour le thème spécifique. Cela peut inclure des balises de modèle et d’autres fonctions spécifiques. Les fonctions contenues dans les plugins seront vues par tous les thèmes.
Fichiers modèles
Les modèles sont des fichiers source PHP utilisés pour générer les pages demandées par les visiteurs, et sont générés au format HTML. Les fichiers de modèle sont constitués de balises de modèle HTML, PHP et WordPress.
Examinons les différents modèles qui peuvent être définis dans le cadre d’un thème.
WordPress vous permet de définir des modèles séparés pour les différents aspects de votre site. Ce n’est pas cependant, il est essentiel d’avoir tous ces différents fichiers modèles pour que votre site fonctionne pleinement. Les modèles sont choisis et générés en fonction de la hiérarchie des modèles, en fonction des modèles disponibles dans un thème particulier.
En tant que thème développeur, vous pouvez choisir le niveau de personnalisation que vous souhaitez mettre en œuvre à l’aide de modèles. Par exemple, dans un cas extrême, vous ne pouvez utiliser qu’un seul fichier modèle, appelé index.php, comme modèle pour toutes les pages générées et affichées par le site. l’utilisation plus courante consiste à faire en sorte que différents fichiers modèles génèrent des résultats différents, pour permettre une personnalisation maximale.
Liste des fichiers modèles
Voici la liste des fichiers thèmes reconnus par WordPress. Bien sûr, votre thème peut contenir d’autres feuilles de style, images ou fichiers. N’oubliez pas que le suivants ont une signification particulière pour WordPress – voir Hiérarchie des modèles pour plus d’informations.
style.css La feuille de style principale. Cela doit être inclus avec votre thème et il doit contenir l’en-tête d’information de votre thème. rtl.css La feuille de style rtl. Ceci sera inclus automatiquement si la direction du texte du site Web est de droite à gauche. Cela peut être généré en utilisant le plugin RTLer. Index.php Le modèle principal. Si votre thème fournit ses propres modèles, index.php doit être présent. comments.php Le modèle de commentaires front-page.php Le modèle de page d’accueil home.php Le modèle de page d’accueil, qui est la page d’accueil par défaut.Si vous utilisez une page d’accueil statique, il s’agit du modèle de page contenant les derniers articles. single.php Le modèle de publication unique. Utilisé lorsqu’un seul article est interrogé. Pour cela et tous les autres modèles de requête, index.php est utilisé si le modèle de requête n’est pas présent. single- {post-type} .php Le modèle de publication unique utilisé lorsqu’un seul message d’un type de publication personnalisé est interrogé. Par exemple, single-book.php serait utilisé pour afficher des messages uniques du type de publication personnalisé nommé « livre ». index.php est utilisé si le modèle de requête pour le type de publication personnalisé n’est pas présent. page.php Le modèle de page. Utilisé lorsqu’une page individuelle est interrogée. category.php Le modèle de catégorie. Utilisé lorsqu’une catégorie est interrogée. tag.php Le modèle de balise. Utilisé lorsqu’une balise est interrogée. taxonomy.php Le terme modèle. Utilisé lorsqu’un terme d’une taxonomie personnalisée est interrogé. author.php Le modèle de l’auteur. Utilisé lorsqu’un auteur est interrogé. date.php Le modèle de date / heure. Utilisé lorsqu’une date ou une heure est demandée. Année, mois, jour, heure, minute, seconde. archive.php Le modèle d’archive. Utilisé lorsqu’une catégorie, un auteur ou une date est interrogé. Notez que ce modèle sera remplacé par category.php, author.php et date.php pour leurs types de requêtes respectifs. search.php Le modèle de résultats de recherche. Utilisé lorsqu’une recherche est effectuée. attachment.php Modèle de pièce jointe. Utilisé lors de l’affichage d’une seule pièce jointe. image.php Modèle de pièce jointe d’image. Utilisé lors de la visualisation d’une seule image en pièce jointe. S’il n’est pas présent, attachment.php sera utilisé. 404.php Le modèle 404 introuvable. Utilisé lorsque WordPress ne peut pas trouver un article ou une page correspondant à la requête.
Ces fichiers ont une signification particulière par rapport à WordPress car ils sont utilisés en remplacement de index.php, lorsqu’ils sont disponibles, selon la hiérarchie des modèles, et lorsque la balise conditionnelle correspondante renvoie true. Par exemple, si un seul article est affiché, la fonction is_single () renvoie « true », et, s’il y a un seul fichier.php dans le thème actif, ce modèle est utilisé pour générer la page.
Modèles de base
Au minimum, un thème WordPress se compose de deux fichiers:
Ces deux fichiers vont dans le répertoire Theme. Le fichier modèle index.php est très flexible. Il peut être utilisé pour inclure toutes les références à l’en-tête, à la barre latérale, au pied de page, au contenu, aux catégories, aux archives, à la recherche, aux erreurs et à toute autre page créée dans WordPress.
Ou, il peut être divisé en modèle modulaire fichiers, chacun prenant en charge une partie de la charge de travail. Si vous ne fournissez pas d’autres fichiers de modèle, WordPress peut avoir des fichiers ou des fonctions par défaut pour effectuer leurs tâches. Par exemple, si vous ne fournissez pas de fichier modèle searchform.php, WordPress a une fonction par défaut pour afficher le formulaire de recherche.
Les fichiers modèles typiques incluent:
- commentaires. php
- comments-popup.php
- footer.php
- header.php
- sidebar.php
En utilisant ces fichiers de modèle, vous pouvez placer des balises de modèle dans le fichier maître index.php pour inclure ces autres fichiers là où vous voulez qu’ils apparaissent dans la page finale générée.
Voici un exemple de include usage:
<?php get_sidebar(); ?><?php get_footer(); ?>
Les fichiers par défaut de certaines fonctions de modèle peuvent être obsolètes ou absents, et vous devez fournir ces fichiers dans votre thème. Depuis la version 3.0, les fichiers par défaut obsolètes se trouvent dans wp-includes/theme-compat
. Par exemple, vous devez fournir header.php pour que la fonction get_header () fonctionne en toute sécurité, et comments.php pour la fonction comments_template ().
Pour en savoir plus sur le fonctionnement de ces différents modèles et comment générer différents informations qu’ils contiennent, lisez la documentation des modèles.
Modèles de page personnalisés
Les fichiers définissant chaque modèle de page se trouvent dans votre répertoire Thèmes. Pour créer un nouveau modèle de page personnalisé pour une page, vous devez créer un fichier. Appelons notre premier modèle de page pour notre page snarfer.php. En haut du fichier snarfer.php, mettez ce qui suit:
<?php/*Template Name: Snarfer*/?>
Ce qui précède code définit ce fichier snarfer.php comme le modèle « Snarfer ». Naturellement, « Snarfer » peut être remplacé par la plupart des textes pour changer le nom du modèle de page. Ce nom de modèle apparaîtra dans l’éditeur de thème comme lien pour le modifier file.
Le fichier peut être nommé presque n’importe quoi avec une extension .php (voir les noms de fichiers de thème réservés pour les noms de fichiers que vous ne devriez pas utiliser; ce sont des noms de fichiers spéciaux que WordPress réserve à des fins spécifiques).
Ce qui suit les cinq lignes de code ci-dessus dépend de vous. Le reste du code que vous écrivez contrôlera la façon dont les pages qui utilisent le modèle de page Snarfer s’afficheront. Voir Balises de modèle pour une description des différentes fonctions du modèle WordPress vous pouvez utiliser à cette fin. Vous trouverez peut-être plus pratique de copier un autre modèle (par exemple page.php ou index.php) dans snarfer.php, puis ajoutez les cinq lignes de code ci-dessus au début du fichier.De cette façon, vous n’aurez qu’à modifier le code HTML et PHP, au lieu de tout créer à partir de zéro. Des exemples sont présentés ci-dessous. Une fois que vous avez créé un modèle de page et l’avez placé dans le répertoire de votre thème, il sera disponible comme choix lorsque vous créez ou modifiez une page. (Remarque: lors de la création ou de l’édition d’une page, l’option Modèle de page n’apparaît que si au moins un modèle est défini de la manière ci-dessus.)
Fichiers de modèle basés sur des requêtes
WordPress peut charger différents modèles pour différents types de requêtes. Il existe deux façons de procéder: dans le cadre de la hiérarchie de modèles intégrée, et grâce à l’utilisation de balises conditionnelles dans la boucle d’un fichier de modèle.
Pour utiliser la hiérarchie de modèles, vous devez essentiellement fournir des fichiers de modèle à usage spécial, qui sera automatiquement utilisé pour remplacer index.php. Par exemple, si votre thème fournit un modèle appelé category.php et qu’une catégorie est interrogée, category.php sera chargé à la place de index.php. Si category.php n’est pas présent, index.php est utilisé comme d’habitude.
Vous pouvez être encore plus précis dans la hiérarchie des modèles en fournissant af ile appelé, par exemple, category-6.php – ce fichier sera utilisé à la place de category.php lors de la génération de la page pour la catégorie dont le numéro d’identification est 6. (Vous pouvez trouver les numéros d’identification de catégorie dans Manage > Catégories si vous êtes connecté en tant qu’administrateur du site dans WordPress version 2.3 et inférieure. Dans WordPress 2.5, la colonne ID a été supprimée des panneaux d’administration. Vous pouvez localiser l’identifiant de la catégorie en cliquant sur « Modifier la catégorie » et en recherchant dans la barre d’adresse URL la valeur cat_ID. Il ressemblera à « … categories.php? Action = edit & cat_ID = 3 » où « 3 » est l’identifiant de la catégorie). Pour un aperçu plus détaillé du fonctionnement de ce processus, consultez Modèles de catégories.
Si votre thème doit avoir encore plus de contrôle sur les fichiers modèles utilisés que ce qui est fourni dans la hiérarchie des modèles, vous pouvez utiliser Conditionnel Mots clés. La balise conditionnelle vérifie essentiellement si une condition particulière est vraie, dans la boucle WordPress, puis vous pouvez charger un modèle particulier, ou mettre un texte particulier sur l’écran, en fonction de cette condition.
Pour exemple, pour générer une feuille de style distincte dans un article trouvé uniquement dans une catégorie spécifique, le code pourrait ressembler à ceci:
Ou, en utilisant une requête, cela pourrait ressembler à ceci:
<?php$post = $wp_query->post;if ( in_category( "9" ) ) { get_template_part( "single2" );} else { get_template_part( "single1" );}?>
Dans les deux cas, cet exemple de code entraînera l’utilisation de différents modèles en fonction de la catégorie du message particulier affiché. Les conditions de requête ne sont pas limitées aux catégories, cependant, consultez l’article Balises conditionnelles pour voir toutes les options.
Définition de modèles personnalisés
Il est possible d’utiliser le système de plugins WordPress pour définir des modèles supplémentaires qui sont affichés en fonction de vos propres critères personnalisés. Cette fonctionnalité avancée peut être accomplie en utilisant le hook d’action « template_include ». Vous trouverez plus d’informations sur la création de plugins dans la référence de l’API Plugin.
Incluant des fichiers de modèle
Pour charger un autre modèle (autre que l’en-tête, la barre latérale, le pied de page, qui ont des commandes incluses prédéfinies telles que get_header ()) dans un modèle, vous pouvez utiliser get_template_part (). Cela permet à un thème de réutiliser facilement des sections de code.
Référencement de fichiers à partir d’un modèle
Lorsque vous référencez d’autres fichiers dans le même thème, évitez les URI et les chemins de fichiers codés en dur. Faites plutôt référence aux URI et aux chemins de fichiers avec bloginfo (): voir Référencer des fichiers à partir d’un modèle.
Notez que les URI qui sont utilisés dans la feuille de style sont relatifs à la feuille de style, pas à la page qui fait référence à la feuille de style. Par exemple, si vous incluez un répertoire images / dans votre thème, il vous suffit de spécifier ce répertoire relatif dans le CSS, comme ceci:
h1 { background-image: url(images/my-background.jpg);}
Plugin API Hooks
Lors du développement de thèmes, il est bon de garder à l’esprit que votre thème doit être configuré pour pouvoir fonctionner correctement avec tous les plugins WordPress que les utilisateurs pourraient décider d’installer. Les plugins ajoutent des fonctionnalités à WordPress via « Action Hooks « (voir Plugin API pour plus d’informations).
La plupart des Action Hooks sont dans le code PHP de base de WordPress, donc votre thème n’a pas besoin de balises spéciales pour fonctionner. Mais quelques Action Les hooks doivent être présents dans votre thème, pour que les plugins affichent des informations directement dans votre en-tête, pied de page, barre latérale ou dans le corps de la page. Voici une liste des balises spéciales de modèle de hook d’action que vous devez inclure:
wp_enqueue_scripts Utilisé dans le fichier des fonctions de thème. Utilisé pour charger des scripts externes et des feuilles de style. wp_head () Va dans le < head > élément d’un thème, dans header.php. Exemple d’utilisation du plugin: ajoutez du code JavaScript. wp_footer () Va dans footer.php, juste avant la balise de fermeture < / body >. Exemple d’utilisation du plugin: insérez du code PHP qui doit s’exécuter après tout le reste, en bas du pied de page.Très couramment utilisé pour insérer du code de statistiques Web, tel que Google Analytics. wp_meta () Va généralement dans le < li > Meta < / li > section du menu ou de la barre latérale d’un thème; modèle sidebar.php. Exemple d’utilisation du plugin: inclure une publicité rotative ou un nuage de tags. Comment_form () Va dans comments.php directement avant le fichier » s balise de fermeture (< / div >). Exemple d’utilisation du plugin: afficher un aperçu des commentaires.
Pour un exemple d’utilisation du monde réel, vous trouverez ces hooks de plug-in inclus dans les modèles de thème par défaut.
API de personnalisation de thème
À partir de WordPress 3.4, un nouveau La fonction de personnalisation de thème est disponible par défaut pour presque tous les thèmes WordPress. La page d’administration de la personnalisation du thème est automatiquement remplie avec des options qu’un thème déclare prendre en charge avec add_theme_support () ou en utilisant l’API Settings, et permet aux administrateurs de voir des aperçus non permanents des modifications qu’ils apportent en temps réel.
Les développeurs de thèmes et d’extensions souhaitant ajouter de nouvelles options à la page de personnalisation de thème d’un thème devraient consulter la documentation sur l’API de personnalisation de thème. Des didacticiels supplémentaires sur l’API de personnalisation de thème sont disponibles sur le site Web Ottopress.com.
Données non fiables
Vous devez échapper au contenu généré dynamiquement dans votre thème, en particulier le contenu qui est généré vers des attributs HTML. Comme indiqué dans les normes de codage WordPress, le texte qui entre dans les attributs doit être exécuté via esc_attr () afin que ou les guillemets doubles ne terminent pas la valeur de l’attribut et invalident le XHTML et causent un problème de sécurité. Les endroits communs à vérifier sont les attributs title, alt et value.
Il existe peu de balises de modèle spéciales pour les cas courants où Une sortie sûre est nécessaire. Un tel cas implique la sortie d’un titre d’article dans un attribut title en utilisant the_title_attribute () au lieu de the_title () pour éviter une faille de sécurité. Voici un exemple d’échappement correct pour l’attribut title d’un lien de titre de publication lors de l’utilisation de texte traduisible:
<a href="<?php the_permalink(); ?>" title="<?php sprintf( __( "Permanent Link to %s", "theme-name" ), the_title_attribute( "echo=0" ) ); ?>"><?php the_title(); ?></a>
Translation Support / I18n
Pour assurer une transition en douceur pour la localisation de la langue, utilisez les fonctions i18n basées sur WordPress gettext pour envelopper tout le texte traduisible dans les fichiers de modèle. Cela permet aux fichiers de traduction de s’accrocher et de traduire les étiquettes, les titres et tout autre texte de modèle en la langue actuelle du site. Pour en savoir plus, consultez la section Localisation de WordPress et I18n pour les développeurs WordPress.
Classes de thème
Implémentez les balises de modèle suivantes pour ajouter des attributs de classe générés par WordPress aux éléments de corps, de publication et de commentaire. Pour les classes de publication, appliquez uniquement aux éléments de The Loop.
- body_class ()
- post_class ()
- comment_class ()
Liste de contrôle des fichiers modèles
Lors du développement d’un thème, vérifiez vos fichiers modèles par rapport aux normes de fichier modèle suivantes.
Document Head (header.php)
- Utilisez le bon DOCTYPE.
- La balise d’ouverture < html > doit inclure language_attributes ( ).
- L’élément charset < meta > charset doit être placé avant tout le reste, y compris le < title > élément.
- Utilisez bloginfo () pour définir la méta < > éléments de jeu de caractères et de description.
- Utilisez wp_title () pour définir le < title > élément. Découvrez pourquoi.
- Utilisez des liens de flux automatiques pour ajouter des liens de flux.
- Ajoutez un appel à wp_head () avant la fermeture < / head Balise >. Les plugins utilisent ce hook d’action pour ajouter leurs propres scripts, feuilles de style et autres fonctionnalités.
- Ne liez pas les feuilles de style de thème dans le modèle d’en-tête. Utilisez plutôt le crochet d’action wp_enqueue_scripts dans une fonction de thème.
Voici un exemple de zone d’en-tête compatible HTML5 correctement formatée:
Menus de navigation (header.php )
- La navigation principale du thème doit prendre en charge un menu personnalisé avec wp_nav_menu ().
- Les menus doivent prendre en charge de longs titres de liens et une grande quantité d’éléments de liste. Ces éléments ne doivent pas casser la conception ou la mise en page.
- Les éléments du sous-menu doivent s’afficher correctement. Si possible, prenez en charge les styles de menu déroulant pour les éléments de sous-menu. Des menus déroulants permettant d’afficher la profondeur du menu au lieu de simplement afficher le niveau supérieur.
- Le thème doit être widgetisé aussi complètement que possible. Toute zone de la mise en page fonctionnant comme un widget (nuage de tags, blogroll, liste de catégories) ou pouvant accepter des widgets (barre latérale) doit autoriser les widgets.
- Contenu qui apparaît par défaut dans les zones widgetisées (codé en dur dans la barre latérale, par exemple) devrait disparaître lorsque les widgets sont activés depuis les widgets Apparence >.
Footer (footer.php)
- Utilisez l’appel wp_footer (), pour apparaître juste avant de fermer la balise body.
<?php wp_footer();
read more