Voilà, voilà... Fin de l'aventure...

 

Fermeture de kolossaldrupal.org dans...


Bonjour tout le monde,

Drupal évolue, les versions changent et Kolossaldrupal.org était essentiellement consacré à la version 6 de Drupal.

Autant dire que les infos présentées ici commencent à dater...

Faute de temps, je ne peux plus garder le site Kolossaldrupal à jour...

Je vous aurais bien proposé de reprendre le flambeau mais... c'est tellement simple de nos jours de se faire son propre site à soi...Pourquoi s'embêter alors ? :-)

Ce site restera donc en l'état, tel qu'il était en 2011...

Ah la la ! Cela ne nous rajeunit pas !

Manuel Vila - Avril 2016

Conversion de thèmes Drupal 6.x en thèmes Drupal 7.x

Référence en anglais sur drupal.org : Converting 6.x themes to 7.x
21 Octobre 2010


Vue d'ensemble des modifications de thèmes dans Drupal 7.x

  1. Les blocs ont de nouveaux ID CSS plus explicites
  2. Les liens Primaires et Secondaires deviennent Menu Principal et Secondaire
  3. Les liens de taxonomie non formatés (Unrendered) ne sont plus disponibles en tant que variable distincte dans les fichiers node.tpl.php
  4. RDFa nécessite des modifications au début de page.tpl.php
  5. La classe clear-block class a été renommé en clearfix
  6. Le gabarit box.tpl.php a été supprimé
  7. $help devient une région
  8. Mission statement removed, 'highlight' region suggested
  9. Footer message removed
  10. La région Content est maintenant obligatoire, le contenu de la page principale devient un bloc
  11. Deuxième cycle de fonctions de traitement de variables
  12. Classes HTML générées via une variable
  13. Attributs HTML générés via une variable
  14. Les fonctions de traitements de variable peuvent maintenant être utilisées dans tous les hooks de thème
  15. Toutes les fonctions de thèmes acceptent maintenant un seul argument, $variables
  16. Les noms de fonction doivent maintenant correspondrent au nom du thème
  17. Tous les fichiers CSS et Javascript doivent maintenant être mentionnés dans le fichier .info du thème
  18. $block->content renommé dans block.tpl.php
  19. « Granular rendering » dans les gabarits de node et user
  20. L'UI jQuery (1.7) ajoutée au core
  21. JS/CSS rattachés aux éléments
  22. $closure devient $page_bottom, création de $page_top et de régions cachées
  23. les variables $left et $right deviennent $sidebar_first et $sidebar_second; IDs CSS modifiés aussi
  24. $picture devient $user_picture, et la classe CSS 'picture' devient 'user-picture'
  25. Nouvelles classes disponibles pour cacher du contenu facilement
  26. La variable JavaScript Drupal.jsEnabled a été supprimée
  27. joker pour les « suggestions » PHPTemplate
  28. Ajout explicite de définition de thème sur un élément lors de l'utilisation de system_elements()
  29. Ajout de balises pour rendre perceptible la progression de l'installation avec le lecteur d'écran et les CSS désactivés.
  30. Entête invisible ajouté à theme_breadcrumb().
  31. Modifications sur l'attribut alt et title de l'icône RSS feed
  32. Boite de recherche déplacée de la couche de thème vers les blocs
  33. Modifications dans les fonctions de rendu de l'arborescence de menu, liens et onglets
  34. Pour l'accessibilité, theme_links() a un nouveau paramètre $heading
  35. theme_get_setting() et THEME_settings() ont été améliorés
  36. Ajout d'une fonction theme_form_required_marker()
  37. Ajout d'une fonction theme_link()
  38. Passage aux liens de contenu principal dans les thèmes du core
  39. hooks modifiés disponibles pour les thèmes
  40. Les feuilles de style du module System ont été réorganisées pour dissocier les styles « comportement » des styles de présentation
  41. Nouveau paramètre de thème pour l'affichage du lien du module Shortcut "add to shortcuts"
  42. Les surcharges spécifiques de thèmes d'un thème générique utilisent le délimiteur -- au lieu de -
  43. Les fichiers CSS sont parfois chargées avec la balise @import, parfois avec la balise LINK
  44. Les fichiers CSS ciblant des navigateurs peuvent et doivent être ajoutées en utilisant drupal_add_css()
  45. Surcharges ciblées (suggestions) disponibles pour theme_menu_link() et theme_menu_tree()
  46. theme_submenu() a été supprimé
  47. Nouvelles variables de gaabrit : $title_prefix et $title_suffix
  48. theme_node_form() a été supprimé
  49. node_get_types() renommé en node_type_get_types()
  50. Les thèmes du noyau (core) contiennent désormais de package = Core dans leurs fichiers .info
  51. Entêtes ajoutés à search-result.tpl.php
  52. L'attribut name dans les balises a et map sont invalides

Les blocs ont de nouveaux ID CSS plus explicites

La plupart des ID CSS des blocs déclarés par le core Drupal ont été modifiés afin que le but du bloc soit clairement indiqué :

Posts de blog récents
Ancien CSS ID (Drupal 6): block-blog-0
Nouvel ID CSS (Drupal 7): block-blog-recent

Navigation de Livre (Book navigation)
Ancien ID CSS (Drupal 6): block-book-0
Nouvel ID CSS (Drupal 7): block-book-navigation

Commentaires récents (Recent comments)
Ancien ID CSS (Drupal 6): block-comment-0
Nouvel ID CSS (Drupal 7): block-comment-recent

Sujets de forum actifs (Active forum topics)
Ancien ID CSS (Drupal 6): block-forum-0
Nouvel ID CSS (Drupal 7): block-forum-active

Nouveaux sujets de forum (New forum topics)
Ancien ID CSS (Drupal 6): block-forum-1
Nouvel ID CSS (Drupal 7): block-forum-new

Sélecteur de langue (Language switcher)
Ancien ID CSS (Drupal 6): block-locale-0
Nouvel ID CSS (Drupal 7): block-locale-language-switcher

Syndication (Syndicate)
Ancien ID CSS (Drupal 6): block-node-0
Nouvel ID CSS (Drupal 7): block-node-syndicate

Sondage le plus récent (Most recent poll)
Ancien ID CSS (Drupal 6): block-poll-0
Nouvel ID CSS (Drupal 7): block-poll-recent

Infos sur l'auteur (Author information)
Ancien ID CSS (Drupal 6): block-profile-0
Nouvel ID CSS (Drupal 7): block-profile-author-information

Formulaire de recherche (Search form)
Ancien ID CSS (Drupal 6): block-search-0
Nouvel ID CSS (Drupal 7): block-search-form

Contenu prisé (Popular content)
Ancien ID CSS (Drupal 6): block-statistics-0
Nouvel ID CSS (Drupal 7): block-statistics-popular

Propulsé par Drupal (Powered by Drupal)
Ancien ID CSS (Drupal 6): block-system-0
Nouvel ID CSS (Drupal 7): block-system-powered-by

Connexion utilisateur (User login)
Ancien ID CSS (Drupal 6): block-user-0
Nouvel ID CSS (Drupal 7): block-user-login

Navigation
Ancien ID CSS (Drupal 6): block-user-1
Nouvel ID CSS (Drupal 7): block-system-navigation

Who's new
Ancien ID CSS (Drupal 6): block-user-2
Nouvel ID CSS (Drupal 7): block-user-new

Qui est en ligne (Who's online)
Ancien ID CSS (Drupal 6): block-user-3
Nouvel ID CSS (Drupal 7): block-user-online

Par exemple, une déclaration CSS De Drupal 6 comme celle-ci :

/* Agrandir le texte dans le bloc de connexion Utilisateur. */
<br />
#block-user-0 {
<br />
&nbsp; font-size: 1.5em;
<br />
}
<br />

deviendra dans Drupal 7 :

/* Agrandir le texte dans le bloc de connexion Utilisateur. */<br />
#block-user-login {
<br />
&nbsp; font-size: 1.5em;<br />
}

Les liens Primaires et Secondaires ont été renommés en menu Principal et Secondaire (Main et Secondary). Les thèmes qui utilisent ces options devront être actualisés avec les nouveaux noms de variables :

6.x

  <div id="menu">
    <?php if (isset($secondary_links)) { ?><?php print theme('links', $secondary_links, array('class' => 'links', 'id' => 'subnavlist')); ?><?php } ?>
    <?php if (isset($primary_links)) { ?><?php print theme('links', $primary_links, array('class' => 'links', 'id' => 'navlist')) ?><?php } ?>
  </div>

7.x

  <div id="menu">
    <?php if (isset($secondary_menu)) { ?><?php print theme('links', $secondary_menu, array('class' => 'links', 'id' => 'subnavlist')); ?><?php } ?>
    <?php if (isset($main_menu)) { ?><?php print theme('links', $main_menu, array('class' => 'links', 'id' => 'navlist')) ?><?php } ?>
  </div>

Les liens de taxonomie non formatés (Unrendered) ne sont plus disponibles dans les fichiers node.tpl.php, en tant que variable distincte

Auparavant, les fichiers node.tpl.php pouvaient utiliser la variable $taxonomy s'ils avaient besoin d'accéder à un tableau de liens de taxonomy non formatés associés au node courant.

Dans Drupal 7, ce n'est plus le cas. A lieu de cela, tous les liens ont été déplacés dans l'objet $node. Le tableau de liens de taxonomie non formatés peut maintenant être trouvé dans $node->content['links']['terms']['#value']. (Notez que ce tableau doit être utilisé avec précautions, puisque le texte qu'il contient n'a pas été échappé pour se prémunir d'attaques XSS (traduction en français sur kolossaldrupal.org).

Les liens de taxonomy mis en forme ne sont pas affectés, les fichiers node.tpl.php peuvent toujours y accéder via la variable $terms.

Dans la plupart des cas, la variable $terms est celle que vous voulez utiliser dans votre theme, et vous pourriez être en mesure de remplacer les références à $taxonomy avec, comme dans l'exemple suivant :

6.x


    <?php if ($taxonomy): ?>
      <div class="terms"><?php print $terms ?></div>
    <?php endif;?>

7.x


    <?php if ($terms): ?>
      <div class="terms"><?php print $terms ?></div>
    <?php endif;?>

 

RDFa nécessite des modifications au début de page.tpl.php

Drupal 7 peut afficher du RDFa, ce qui implique les modifications suivantes dans page.tpl.php :

  • le DOCTYPE doit être modifié en XHTML+RDFa 1.0
  • Pour une compatibilité avec XHTML 1.1, l'ancien attribut lang doit être supprimé, seul xml:lang devrait subsister.
  • Les préfixes RDF utilisés dans le document HTML doivent être sérialisés dans la balise html et inclus dans la variable $rdf_namespaces.
  • Le profil GRDDL doit être spécifié dans la balise <head>.

6.x

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="<?php print $language->language ?>" lang="<?php print $language->language ?>" dir="<?php print $language->dir ?>">
  <head>

7.x

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN"
 "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="<?php print $language->language ?>" dir="<?php print $language->dir ?>"
  <?php print $rdf_namespaces ?>>
  <head profile="<?php print $grddl_profile ?>">

 

La classe clear-block a été renommé en clearfix

La classe clear-block était un Drupalisme pour une fonctionnalité connue dans la communauté CSS sous le nom de classe « clearfix ». De plus, l'utilisation de « block » dans l'ancien nom était source de confusion pour les utilisateurs de Drupal plus habitués au système de blocs qu'aux propriétés de directives CSS. Les nouveaux concepteurs de thème de Drupal ne devraient plus être désorientés par cet ancien nom de la classe.

Si votre thème comporte un <div class="clear-block">, modifiez-le simplement en <div class="clearfix">.

Le gabarit box.tpl.php a été supprimé

Le gabarit box.tpl.php a été supprimé. Les contenus qui utilisaient le fichier box.tpl.php disposent maintenant de leur propre fonction de thème.

Les résultats de recherches sont désormais mis en forme par la fonction de theme theme_search_results_listing() et le formulaire de commentaires est mis en forme par la fonction theme_comment_form_box() .

$help devient une région

(discussion) Dans Drupal 7, une nouvelle région appelée help a été ajoutée aux régions par défaut ( left, right, content, header, footer). Par défaut, le contenu de cette région est identique à celui de la variable $help dans page.tpl.php de Drupal 6.

Les thèmes de Drupal 7 doivent s'assurer que la variable $help figure dans page.tpl.php et que, si le thème surcharge ces régions par défaut, la ligne suivante soit ajoutée au fichier .info:

regions[help] = Help

Le texte d'aide est maintenant encadré par les balises et classes <div> du fichier gabarit block.tpl.php, les CSS utilisées pour styliser l'aide doivent donc être modifiées.

Mission statement removed, 'highlight' region suggested

(discussion). Dans Drupal 6, le gabarit de page recevait une variable spécifique appelée $mission, qui contient le paramètre objet du site affiché sur la page d'accueil du site. Les thèmes Drupal 6 peuvent également activer ou désactiver cet affichage via un paramètre dans la page de configuration des thèmes. Drupal 7 ôte ce paramètre « objet du site » et son option d'affichage et le déplace vers la gestion des blocs.

Les thèmes du core de Drupal 7 incorporent maintenant une région appelée « highlight » qui utilise la zone d'affichage réservée à l'objectif du site dans Drupal 6. Le contenu de cette région dépend maintenant des paramètres de mise en place des blocs et n'est pas restreinte à la seule page d'accueil. Le contenu de la région hightlight sera encadré par les classes et balises <div> du fichier gabarit block.tpl.php, ce qui impliquera peut-être une modification des CSS de cette zone d'affichage.

6.x

dans .info:

features[]= mission

dans page.tpl.php:

<?php
print $mission
?>

7.x

Si vousavez déclaré des regions personnalisées dans votre fichier .info, vous pourriez ajouter la région highlighted à la liste des régions existantes, comme indiqué ci-dessous.

Si votre thème ne déclare aucune région, la région highlight sera automatiquement ajoutée par le noyau, et vous n'aurez qu'à vous assurer qu'elle soit affichée dans page.tpl.php.

Dans .info:

regions[highlighted] = Highlighted

Dans page.tpl.php:

<?php
print render($page['highlighted']); 
?>

 

(discussion) Dans Drupal 6, le gabarit de page recevait une variable spécifique appelée $footer_message, qui contenait le paramètre message du pied de page du site. Ce paramètre était généralement envoyé par le gabarit avant la région footer ($footer). Drupal 7 traite le message de pied de page comme un type spécial de bloc utilisateur. Ceux qui avaient ce paramètre dans Drupal 6 auront, dans la mise à jour, un bloc déclaré par l'utilisateur, situé dans la région $footer.

Pour actualiser vos thèmes, enlevez-leur simplement la variable $footer_message.

Si vous envoyez $footer_message à votre gabarit de page et qu'il ne gère pas encore la région $footer, il est temps de le faire. Si vous ne surchargez aucune région, la région footer sera pré-déclarée. Si vous surchargez des régions, envoyez le contenu $footer à votre gabarit de page et ajoutez la région footer à votre fichier .info:

regions[footer] = Footer

La prise en charge de la région footer est simplement proposée mais n'est pas requise par Drupal. Dans le cas de mises à jour depuis Drupal 6 avec des thèmes dépourvus de région footer, il sera possible de repositionner ce bloc dans une autre région.

La région Content est maintenant obligatoire, le contenu principal de la page devient un bloc

(discussion) Dans Drupal 6 et antérieurs, la variable $content du fichier page.tpl.php contenait le contenu principal de la page auquel étaient ajoutés les blocs placés dans la région contenu (si cette région était déclarée).

Dans Drupal 7, $content devient une région à part entière et est désormais obligatoire dans tous les thèmes. Cette nouvelle caractéristique a été paramétrée pour que, lorsqu'on active des nouveaux thèmes, Drupal sache où placer le contenu principal de la page par défaut.

Dans Drupal 6, et dans cette région, il n'était seulement possible de placer des blocs qu'après le contenu principal de la page. La seule façon de placer des blocs avant le contenu principal de la page était de déclarer une région particulière à cette fin. Drupal 7 place désormais le contenu principal de la page dans son propre bloc. Cela rend possible la mise en place de blocs avant ou après le contenu principal de la page dans une région sans avoir à ajouter une nouvelle région.

Si vous comptiez sur le fait que les blocs n'étaient situés que dans les barres latérales et étaient par conséquent stylisés avec une seule classe CSS .block ou similaire, vous devrez actualiser vos fichiers CSS.

Comme le contenu principal de la page est entouré des balises provenant de block.tpl.php, le sélecteur .block lui sera également appliqué, vous aurez donc à restreindre la mise en forme des blocs à certaines regions, en créant des sélecteurs plus spécifiques, comme par exemple #left-sidebar.block.

Deuxième cycle de fonctions de traitement de variables

Il y a maintenant deux jeux de fonctions de traitement de variables. les premières sont les fonctions de pré-traitement existantes (voir traduction en français sur kolossaldrupal.org). Les secondes sont des fonction de « traitement » exécutées après les pré-traitements. Les différents préfixes et suffixes s'appliquent de la même façon à ce deuxième cycle. Cela s'avère utile lorsque certaines variables demandent à être examinées sur deux cycles.

Par exemple, ajout de classes dans un tableau lors de la phase de pré-traitement, puis les convertir en une chaîne de caractères lors de la phase de « traitement » pour qu'elle soit prête à être utilisée dans un gabarit. Voir la section suivante.

Classes HTML générées via une variable

Tous les gabarits peuvent maintenant fournir $classes à partir d'un gabarit pour mettre en forme des classes dynamiques construites dans des fonctions de traitement de variables. La méthode pour ajouter ces classes dynamiques consiste à alimenter comme ceci une clé intitulée classes_array :

<?php
function mytheme_preprocess_node(&$vars) {
  
// Add a striping class.
  
$vars['classes_array'][] = 'node-' $vars['zebra'];
}
?>

 

Le « template_process » par défaut (deuxième cycle du traitement) aplatira le tableau en une chaîne de caractères, le rendant utilisable dans votre gabarit. Les classes dynamiques sont générées par défaut pour les gabarits courants, mais étant donné la façon dont elles sont paramétrées, n'importe quel gabarit peut disposer d'une variable $classes.

Par exemple :

<div class="<?php print $classes ?>">
  ...
</div>

Attributs HTML générés via une variable

Toutes les maquettes de mise en page (maquettes de mise en page = gabarits, = templates. NdK) peuvent maintenant afficher $attributes, $title_attributes et $content_attributes depuis un gabarit pour mettre en forme les attributs dynamiques construits dans les fonctions de traitement de variables.

Le module RDF et d'autres modules ajoutent des informations importantes à ces variables, il est donc essentiel pour les thèmes que ces variables soient correctement transmises à tous les fichiers gabarits surchargés.

Ces trois variables contiennent des attributs pour l'intégralité de l'élément mis en forme par le gabarit, ainsi que son titre primaire et les éléments de contenu. Pour ajouter des attributs à ces variables, alimentez les clés de la variable intitulées « attributes_array », « title_attributes_array », et « content_attributes_array » comme ceci :

<?php
function mytheme_preprocess_node(&$vars) {
  
// Si le node a été sauvegardé avec une journalisation (log message) et que l'utilisateur connecté en cours
  // a les droits pour voir le message, l'ajouter comme attribut de titre (tooltip)
  // lors de l'affichage du node.
  
if (!empty($vars['node']->log) && user_access('view revisions')) {
    
$vars['attributes_array']['title'] = $vars['node']->log;
  }

  
// Forcer le sens des titres de node de gauche à droite, quelque soit 
  //  la langue ou d'autres paramètres.
  
$vars['title_attributes_array']['dir'] = 'ltr';
}
?>

Le « template_process » par défaut (deuxième cycle de traitement) s'occupe d'aplatir les tableaux en des chaînes prêtes à être affichées dans le fichier gabarit. Le traitement de « mise à plat » abouti à des chaînes vides (si aucun attribut dynamique n'a été initialisé) ou à des chaînes de caractères débutant par un caractère espace suivi par les noms des attributs et leurs valeurs. Pour cette raison, les variables attributs devraient être affichées dans le gabarit juste après ce qui les précède, sans espace de début.

Par exemple :

<div id="..." class="..."<?php print $attributes; ?>>
  <h2<?php print $title_attributes; ?>>...</h2>
  <div class="content"<?php print $content_attributes; ?>>...</div>
</div>

Comme montré dans l'exemple, la convention des attributs id et class est d'être explicitement affichés dans le gabarit, et pour les variables attributs d'être utilisées pour tous les autres attributs.

Par conséquent, pour s'assurer qu'il n'y aura pas d'attributs affichés deux fois dans le même élément, il faut suivre les règles suivantes :

  • les fonctions de pré-traitement des modules ne doivent pas ajouter id ou class aux tableaux d'attributs.
  • Les fonctions de pré-traitement des thèmes peuvent ajouter id et/ou class aux tableaux d'attributs, mais si elles le font, le thème doit également surcharger le fichier gabarit correspondant et s'assurer que le même attribut ne soit pas explicitement affiché.
  • Les gabarits ne doivent afficher aucun attribut excepté id ou class explicitement sur tout élément pour lequel une variable attribut est également affichée. A la place, le thème doit utiliser une fonction de pré-traitement, comme indiqué ci-dessus.

Les fonctions de traitements de variable peuvent maintenant être utilisées dans tous les hooks de thème

(discussion) Dans Drupal 6, les fonctions de pré-traitement ne pouvaient être utilisées que pour les hooks de thème mis en forme par des gabarits.

Dans Drupal 7, les pré-traitements de hooks et les fonctions de traitement peuvent être utilisés pour tous les hooks de thème, qu'ils soient « rendus » (rendered) par les gabarits ou les fonctions.

Par exemple, un thème peut faire en sorte que tous les liens de menus commençant par http: ou https: (par opposition à ceux qui se rapportent à un lien interne de Drupal) s'ouvrent dans un nouvel onglet du navigateur :

<?php
function mytheme_preprocess_menu_link(&$variables) {
  if (
    
substr($variables['element']['#href'], 05) == 'http:' ||
    
substr($variables['element']['#href'], 06) == 'https:'
  
) {
    
$variables['element']['#localized_options']['attributes']['target'] = '_blank';
  }

?>

Chaque fonction de pré-traitement augmente le délai de traitement d'un élément par le thème, aussi, concernant les fonctions de thème appelées fréquemment, surveillez les performances quand vous ajoutez des fonctions de pré-traitement.

Pour minimiser cette surcharge, les fonctions de traitement et pré-traitement qui ne sont pas spécifiques aux hooks ne sont appelées que pour les gabarits. Reportez-vous à la documentation de l'API pour theme() (en anglais) pour la liste complète des fonctions de traitement et pré-traitement spécifiques ou non aux hooks.

Toutes les fonctions de thèmes acceptent maintenant un seul argument, $variables

(discussion) Dans Drupal 6, les fonctions de thèmes répertoriaient leurs arguments de fonctions dans hook_theme(). Dans Drupal 7, toutes les fonctions de thème prennent un seul argument, $variables, un tableau de variables indicé par clés, et répertorient les clés étendues dans ce tableau dans hook-theme().

6.x

<?php
function drupal_common_theme() {
  return array(
    ...
    
'table' => array(
      
'arguments' => array('header' => NULL'rows' => NULL'attributes' => array(), 'caption' => NULL),
    ),
    ...
  );
}

function 
theme_table($header$rows$attributes = array(), $caption NULL) {
  ...
}
?>

7.x

<?php
function drupal_common_theme() {
  return array(
    ...
    
'table' => array(
      
'variables' => array('header' => NULL'rows' => NULL'attributes' => array(), 'caption' => NULL'colgroups' => array(), 'sticky' => TRUE),
    ),
    ...
  );
}

function 
theme_table($variables) {
  
$header $variables['header'];
  
$rows $variables['rows'];
  
$attributes $variables['attributes'];
  
$caption $variables['caption'];
  
$colgroups $variables['colgroups'];
  
$sticky $variables['sticky'];
  ...
}
?>

 

Les noms de fonctions doivent correspondrent au nom du thème

Dans le fichier template.php, les noms de fonctions doivent maintenant utiliser le nom du thème adéquat. Vous ne pourrez plus utiliser phptemplate_function. Cette modification a été effectuée dans le patch suivant : Die, themeEngineName_ prefix, die!.

Pour actualiser votre thème, assurez-vous qu'il n'y ait pas, dans le fichier template.php ou dans d'autres fichiers du thème, de fonction débutant par le nom du processeur de thème (phptemplate).

Tous les fichiers CSS et Javascript doivent maintenant être mentionnés dans le fichier .info du thème

Dans Drupal 6, style.css et script.js étaient automatiquement inclus dans votre thème, même s'ils n'étaient pas mentionnés dans le fichier .info du thème.

Dans Drupal 7, les thèmes doivent mentionner ces fichiers dans le fichier .info pour qu'ils soient ajoutés au thème. Vous pouvez lire plus d'informations à ce sujet à la page #351487: Remove default values for stylesheet and scripts includes from system module..

Si votre thème n'utilise pas ces fichiers, ou s'ils sont déjà mentionnés dans votre fichier .info, aucune modification n'est nécessaire.

$block->content renommé dans block.tpl.php

Voir cette discussion pour l'historique complet.

« Granular rendering » dans les gabarits de node et user

(discussion) Les concepteurs de maquettes de mises en page peuvent maintenant afficher des nodes et des profils comme ils l'entendent tout en conservant une compatibilité avec des modules nouveaux qui ajouteraient des nouveaux contenus. Pour cela, les concepteurs de gabarits doivent utiliser 2 nouvelles fonctions - render() et hide(). Exemple puisé dans node.tpl.php :

<div class="content">
  <?php
   // We hide the comments and links now so that we can render them later.
   hide($content['comments']);
   hide($content['links']);
   print render($content);
 ?>
</div>

<?php print render($content['links']); ?>

<?php print render($content['comments']); ?>.

render() renvoie tous les éléments contenus dans $content. Aussi, print render($content) est équivalent à print $content de Drupal 6.

Quand un concepteur de thème veut afficher une partie du tableau $content, il doit le faire avec quelque chose qui ressemble à print render($content['links']).

Si l'affichage des liens vient après l'affichage de tout le contenu de $content, il faudra appeler hide($content['links']) avant d'appeler print render($content). Ensuite les liens peuvent être affichés plus loin dans le gabarit avec print render($content['links']).

L'UI jQuery (1.8) ajoutée au core

(discussion) jQuery UI 1.8 a été ajouté au noyau de Drupal.

Vous trouverez les fichier jQuery UI dans misc/ui et vous pourrez ajouter des fichiers javascript et CSS à vos pages à partir de là avec les fonctions drupal_add_js() et drupal_add_css(), il n'y a pas d'appels de fonctions spéciales requis.

Si vous actualisez un thème qui dépendait du module tiers jquery_ui, consultez le guide de mise à jour, qui fournit des exemples.

JS/CSS rattachés aux éléments

(discussion) Les éléments isolés ont maintenant la possibilité de déclarer quel code Javascript et quelles feuilles de style leur sont associés. La déclaration se fait dans les propriétés #attached_js et attached_css.

Drupal 6.x :

<?php
function example_admin_settings() {
  
// Add example.admin.css
  
drupal_add_css(drupal_get_path('module''example') .'/example.admin.css');
  
// Add some inline JavaScript
  
drupal_add_js('alert("You are visiting the example form.");''inline');
  
// Add a JavaScript setting.
  
drupal_add_js(array('mymodule' => 'example'), 'setting');
  
$form['example'] = array(
    
'#type' => 'fieldset',
    
'#title' => t('Example');
  );
  return 
$form;
}
?>

Drupal 7.x :

<?php
function example_admin_settings() {
  
$form['#attached_css'] = array(
    
// Add example.admin/css.
    
drupal_get_path('module''example') . '/example.admin.css'
  
),
  
$form['#attached_js'] = array(
    
// Add some inline JavaScript.
    
'alert("You are visiting the example form.");' => 'inline',
    
// Add a JavaScript setting. Note that when the key is a number, the 'data' property will be used.
    
array(
      
'data' => array('mymodule' => array(...)),
      
'type' => 'setting'
    
),
  );
  
$form['example'] = array(
    
'#type' => 'fieldset',
    
'#title' => t('Example');
  );
  return 
$form;
}
?>

 

$closure devient $page_bottom, création de $page_top et de régions cachées

(discussion 1) (discussion 2) Drupal 6 fournit une variable spéciale appelée $closure qui doit être placée à la fin du body HTML et peut être stylisée via theme_footer() (qui appelle l'implémentation de hook_footer() dans les modules).

Pour homogénéiser la méthode d'affichage dans les différentes zones de la page, Drupal 7 a normalisé les régions et introduit la région page_bottom en remplacement de la variable $closure.

De même, page_top a été ajouté comme pendant de page_bottom. Dans Drupal 7 vous devrez afficher $page_top au début du body HTML et $page_bottom à la fin.

Drupal 6 :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
...
<body class="<?php print $body_classes; ?>">
...
    <?php print $closure; ?>
</body>
</html>

Drupal 7 :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN"
 "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
...
<body class="<?php print $classes; ?>">
  <?php print $page_top; ?>
...
  <?php print $page_bottom; ?>
</body>
</html>

Si vous déclarez vos propres régions, n'oubliez pas de mentionner les régions page_top et page_bottom dans vos déclarations.

Extrait du fichier .info du thème :

regions[content] = Content
regions[help] = Help
regions[page_top] = Page top
regions[page_bottom] = Page bottom

 

Les régions page_top et page_bottom sont cachées, ce qui veut dire qu'elles ne seront pas affichées dans les blocs de l'interface d'administration. Lorsque l'on crée des thèmes spécifiques à un site, il peut être utile d'ajouter d'autres régions cachées (pour donner aux modules davantage de zones d'affichage dans le thème, sans avoir à définir des blocs s'affichant parmi les blocs d'interface), vous pouvez le faire via le tableau regions_hidden[] du fichier .info, qui est une création de Drupal 7 :

Extrait du fichier .info du thème :

regions[content] = Content
regions[help] = Help
regions[page_top] = Page top
regions[page_bottom] = Page bottom
regions[indicators] = Indicators
regions_hidden[] = indicators

 

(discussion)

Dans Drupal 6, les variables pour les colonnes latérales s'intitulaient $left et $right.

Dans Drupal 7, elles deviennent $sidebar_first et $sidebar_second.

6.x

     <?php if (!empty($left)): ?>
        <div id="sidebar-left" class="column sidebar">
          <?php print $left; ?>
        </div> <!-- /sidebar-left -->
      <?php endif; ?>
...
      <?php if (!empty($right)): ?>
        <div id="sidebar-right" class="column sidebar">
          <?php print $right; ?>
        </div> <!-- /sidebar-right -->
      <?php endif; ?>

7.x

     <?php if ($sidebar_first): ?>
        <div id="sidebar-first" class="column sidebar"><div class="section region">
          <?php print $sidebar_first; ?>
        </div></div> <!-- /.section, /#sidebar-first -->
      <?php endif; ?>

      <?php if ($sidebar_second): ?>
        <div id="sidebar-second" class="column sidebar"><div class="section region">
          <?php print $sidebar_second; ?>
        </div></div> <!-- /.section, /#sidebar-second -->
      <?php endif; ?>

Ce qui implique une modification des ID CSS qui leur sont associés :

Ancien ID CSS (Drupal 6) Nouvel ID CSS (Drupal 7)
#sidebar-left #sidebar-first
#sidebar-right #sidebar-second

 

$picture devient $user_picture, et la classe CSS 'picture' devient 'user-picture'

La variable et la classe CSS ont été renommées pour être plus descriptives.

Drupal 6 (user-picture.tpl.php) :

<div class="picture">
  <?php print $picture; ?>
</div>

Drupal 7 :

<?php if ($user_picture): ?>
  <div class="user-picture">
    <?php print $user_picture; ?>
  </div>
<?php endif; ?>

 

Nouvelles classes disponibles pour cacher facilement du contenu

Deux nouvelles classes ont été créées dans le but de cacher des éléments, .element-hidden et .element-invisible. Chacune d'elles a un seul objet :

.element-hidden
La fonction de cette classe est de cacher des éléments à tous les utilisateurs. Elle doit être utilisée pour les éléments qui ne doivent pas être immédiatement affichés aux utilisateurs. Un exemple serait un groupe de champs repliables qui serait déplié par un clic de l'utilisateur. L'action de cette classe peut être basculée avec les fonctions jQuery show() et hide().
.element-invisible
Le but de cette classe est de cacher les éléments visuellement parlant, mais de les laisser disponibles pour les lecteurs d'écrans. Cette classe doit être utilisée pour les données utiles aux utilisateurs de lecteurs d'écrans dans leur compréhension et leur utilisation du site, lorsque un affichage n'est pas souhaitable. Les données ainsi mises à disposition doivent être concises, afin de ne pas encombrer l'utilisateur. Cette classe ne doit pas être utilisée pour les éléments susceptibles de recevoir un focus (comme les liens et les éléments de formulaire) puisque cela provoquera des problèmes avec les utilisateurs utilisant exclusivement le clavier ou de la reconnaissance vocale.

La variable JavaScript Drupal.jsEnabled a été supprimée

Dans les précédentes versions de Drupal, vous pouviez faire la chose suivante dans le code JavaScript pour vérifier que JavaScript était activé et disponible pour Drupal :

if( Drupal.jsEnabled ) {
   // something
}

Dans Drupal 7, la variable Drupal.jsEnabled n'existe plus et il n'y a pas de façon de contourner cela. L'idée est que jQuery ne fonctionnant pas, s'il ne fonctionne pas, il est inutile de le tester par avance.

Joker pour les « suggestions » PHPTemplate

(discussion) PHPTemplate offre des suggestions reposant sur des entiers URI. Dans Drupal 6, vous devez styliser les suggestions précédentes ou une en particulier, par exemple :

page-user.tpl.php ou page-user-1.tpl.php

C'était plutôt balourd car pour personnaliser toutes les pages utilisateur, il fallait surcharger page-user.tpl.php, ce qui personnalisait la page de connexion utilisateur.

Le nouveau joker de suggestion pour les arguments de type entier prend les suggestion % page-user-%.tpl.php. Les suggestions qui ont des arguments supplémentaires comme page-user-edit.tpl.php restent les mêmes; le nouvel argument différencie simplement les suggestions qui ont un argument de type entier de celles qui n'en ont pas.

Ajout explicite de définition de thème sur un élément lors de l'utilisation de system_elements()

Dans system_elements(), il est maintenant nécessaire d'ajouter explicitement la déclaration du thème, plutôt que d'autoriser le système à l'attribuer automatiquement.

Ajout de balises pour rendre perceptible la progression de l'installation avec le lecteur d'écran et les CSS désactivés.

Dans Drupal 6 il n'y a pas de balisage indiquant quelle tâche d'installation était terminée ou quelle tâche est active, ces différences ne sont montrées qu'avec une mise en forme via CSS.

Dans Drupal 7, un balisage a été ajouté à theme_task_list() pour :

Ajouter un entête qui n'est visible que par les utilisateurs de lecteurs d'écrans et quand CSS est désactivé

<h2 class="element-invisible">Installation tasks</h2>

Ajouter le texte "(done)" et "(active)" aux tâches pertinentes dans la liste des tâches, visible uniquement par les utilisateurs de lecteurs d'écrans et quand CSS est désactivé.

<span class="element-invisible">(done)</span>

Entête invisible ajouté à theme_breadcrumb().

Dans Drupal 6, il n'y a pas de balise indiquant la fonction ou le but des fils d'ariane aux utilisateurs de lecteurs d'écrans.

Drupal 7 fournit un entête avant les fils d'ariane, qui est visible par les utilisateurs de lecteurs d'écrans et quand CSS est désactivé. Cet entête a été ajouté à theme_breadcrumb() et garland_breadcrumb().

<h2 class="element-invisible">Vous êtes ici</h2>

Modifications sur l'attribut alt et title de l'icône RSS feed

Dans Drupal 6, l'attribut alt de l'icône RSS feed stylisée par theme_feed_icon() était statiquement paramétré à « Syndicate content » et le titre de l'attribut de l'icône était la chaîne passée à la fonction dans le paramètre $title.

Drupal 7 utilise le même texte pour l'attribut alt de l'image et pour le titre de l'attribut de l'ancre RSS feed. Le texte est composé de « Subscribe to » + la chaîne $title passée à theme_feed_icon().

Dans les versions précédentes, la boite de recherche (search_box) était affichée par le thème en utilisant $search_box.

Drupal 7 a supprimé cela. Le formulaire de recherche fait tout simplement partie du système de blocs. Les concepteurs de thèmes devront supprimer toutes les références à $search_box de leurs thèmes et devront peut-être modifier les CSS pour gérer la boite de recherche dans les blocs.

Les responsables de sites qui migrent leurs sites de Drupal 6 vers Drupal 7 devront ajouter le bloc formulaire de recherche à leurs sites.

(discussion)

La fonction menu_tree_output() renvoie maintenant un tableau structuré de données qui peut être mis en forme en html avec drupal_render().

Les fonctions theme_menu_item_link() et theme_menu_item() ont été supprimées et sont efficacement remplacées par theme_menu_link() pour ce qui concerne le rendu d'une arborescence de menu. C'est la fonction par défaut utilisée pour représenter chaque lien d'une arborescence retournée par menu_tree_output().

La fonction theme_menu_local_task() accepte d'autres paramètres et a comme compagnon theme_menu_local_action() qui n'existait pas dans Drupal 6. Ces deux fonctions prennent comme premier paramètre un tableau de liens de menus avec les clés title, href et localized_options . Dans Drupal 6, le premier paramètre était une chaîne. La modification vers un tableau a été réalisée pour permettre la suppression de theme_menu_item_link(). Le deuxième paramètre theme_menu_local_task() est toujours un booléen, $active.

Pour satisfaire aux conditions de Web Content Accessibility Guidelines (WCAG), les entêtes HTML doivent être utilisés avant toutes les zones de contenus, qui incluent les listes de liens telles que le menus.

Les entêtes assurent aux utilisateurs de technologies d'assistance de pouvoir parcourir rapidement les contenus; cependant, de nombreux utilisateurs « visuels » n'ont pas besoin des entêtes des listes de navigation, car ils peuvent avoir une idée de leur structure par la façon dont elles sont agencées sur la page. Aussi, la recommendation est d'ajouter un entête avec la classe CSS element-invisible, ainsi seuls les utilisateurs de technologies d'assistance remarqueront l'entête.

Il est également important que le niveau d'en-tête (H2, H3, etc) soit correctement imbriqué dans la hiérarchie des entêtes. Il n'est donc pas conseillé d'ajouter aveuglement un entête H2 au début de chaque liste.

Pour cette raison, la fonction theme_links() qui est normalement appelée via theme('links',...), a un nouveau paramètre en troisième position $header pour ajouter l'entête exigé à la liste des liens.

Par exemple, dans un fichier page.tpl.php classique de Drupal 6 :

<?php
 
print theme('links'$secondary_menu, array('id' => 'secondary-menu''class' => array('links''clearfix'))); 
?>

Drupal 7 :

<?php
print theme('links'$secondary_menu, array('id' => 'secondary-menu''class' => array('links''clearfix')), array('text' => t('Secondary menu'), 'level' => 'h2''class' => array('element-invisible'))); 
?>

 

Dans Drupal 7, cela aboutira à un menu secondaire accessible et sémantiquement correct puisqu'un entête invisible aura été ajouté :

<h2 class="element-invisible">Secondary menu</h2>

 

Pour plus d'information (en anglais) :

Theme_get_setting() et THEME_settings() ont été améliorés

Dans Drupal 6, les thèmes peuvent ajouter des éléments de formulaires personnalisés à leur page de « paramètres de configuration de thème » dans admin/build/themes/settings/NOMDUTHEME. Les thèmes devront créer une page theme-sttings.php dans leur dossier de thème et utiliser une fonction avec la syntaxe suivante :

<?php
/**
* Implementation of THEMEHOOK_settings() function.
*
* @param $saved_settings
*   array Un tableau des paramètres sauvegardés pour ce thème.
* @return
*   array Un tableau formluaire.
*/
function phptemplate_settings($saved_settings) { }
?>

 

Dans Drupal 7, les thèmes disposent de beaucoup plus de facilités pour modifier l'intégralité de leurs pages de configuration. Dans un theme-settings.php, les thèmes doivent maintenant utiliser une fonction THEMENAME_form_system_theme_settings_alter(&$form, $form_state). Elle offre aux thèmes la même capacité qu'ont les modules qui utilisent hook_form_system_theme_settings_alter(). Consultez « Form API Quickstart Guide » et « Forms API Reference» sur , ainsi que les documents hook_form_FORM_ID_alter() pour connaître la souplesse de Forms API.

Notez que les thèmes ne peuvent plus utiliser phptemplate_prefix dans les fonctions; vous devrez utiliser comme préfixe le nom actuel de votre thème.

Voici un exemple si vous avez un thème nommé « foo » et que vous voulez ajouter un champ texte dont la valeur par défaut est « poisson d'avril » :

<?php
function foo_form_system_theme_settings_alter(&$form$form_state) {
  
$form['caberet_example'] = array(
    
'#type'          => 'textfield',
    
'#title'         => t('Widget'),
    
'#default_value' => theme_get_setting('foo_example'),
    
'#description'   => t("Place this text in the widget spot on your site."),
  );
}
?>

Pour initialiser la valeur par défaut de n'importe quel élément ajouté, vous devrez ajouter une simple ligne au fichier .info : settings[SETTING_NAME] = DEFAULT_VALUE. Pour notre thème foo, vous devrez éditer le fichier foo.info et cette ligne :

settings[foo_example] = Poisson d'avril

Et dans n'importe quel fichier php de votre thème, vous pouvez récupérer la valeur initialisée par l'utilisateur en appelant :

<?php
$foo_example 
theme_get_setting('foo_example');
?>

Ajout d'une fonction theme_form_required_marker()

(discussion) Le balisage pour générer le marqueur des élément de formulaires obligatoires est maintenant gérer par une fonction distincte, theme_form_required_marker() au lieu d'être incorporé comme partie du travail réalisé par theme_form_element(). Cela vous permet de réutiliser ce balisage à d'autres endroits ou de le modifier sans avoir à modifier tout theme_form_element().

(discussion) Le balisage pour générer un lien est maintenant géré par une fonction de thème, theme_link(), au lieu d'être codé en dur dans la fonction l(). Cela vous permet d'implémenter une fonction de pré-traitement ou une fonction surchargée qui personnalisera le balisage d'un lien. Cela peut ralentir les pages Drupal contenant beaucoup de liens, il est donc conseillé d'évaluer le ratio bénéfice/performance, mais cette possibilité existe pour les sites et les thèmes qui en ont besoin.

Cette fonction de thème a pour but de personnaliser le style des liens. D'autres fonctions de thème existent pour personnaliser des liens basés sur le contexte. Par exemple, pour personnaliser des liens de menus, surchargez plutôt theme_menu_link().

Exemple pour hook_preprocess_link():

<?php
function mytheme_preprocess_link(&$variables) {
  
// Pour personnaliser des liens différemment selon vers quoi ils pointent,
  // ajouter des classes qui contiennent des infos sur le chemin du lien.
  
if (strpos($variables['path'], ':') !== FALSE) {
    
// Pour les liens externes, ajouter une classe signalant un lien externe 
    // et une classe indiquant le but (e.g., pour les liens 'mailto:...', ajouter un 'link-mailto'
    // class).
    
$variables['options']['attributes']['class'][] = 'link-external';
    
$variables['options']['attributes']['class'][] = 'link-' parse_url($variables['path'], PHP_URL_SCHEME);
  }
  else {
    
// Pour les liens internes, ajouter une classe signalant un lien interne.
    
$variables['options']['attributes']['class'][] = 'link-internal';
    if (empty(
$variables['path']) || $variables['path'] == '<front>') {
      
// Ajouter une classe signalant un lien vers la page d'accueil.
      
$variables['options']['attributes']['class'][] = 'link-front';
    }
    else {
      
// Pour des liens internes ne pointant pas vers la page d'accueil, ajouter une classe pour chaque partie
      // du chemin. Par exemple, pour un lien vers 'admin/structure/block', ajouter 
      // les classes 'link-path-admin', 'link-path-admin-structure', et
      // 'link-path-admin-structure-block'.
      
$class 'link-path';
      foreach (
explode('/'$variables['path']) as $path_part) {
        
$class .= '-' $path_part;
        
$variables['options']['attributes']['class'][] = $class;
      }
    }
  }
}
?>

Exemple de surcharge de theme_link()

<?php
function mytheme_link($variables) {
  
// Placer un span à l'intérieur et à l'extérieur de la balise ancre pour 
  // implémenter un style particulier.
  
return '<span class="link-wrapper"><a href="' check_plain(url($path$options)) . '"' drupal_attributes($options['attributes']) . '><span class="link-content-wrapper">' . ($options['html'] ? $text check_plain($text)) . '</span></a></span>';
}
?>

(discussion) Pour satisfaire aux Web Content Accessibility Guidelines (WCAG) 2.0, directive 2.4.1. Bypass Blocks, les pages web ont besoin d'un lien permettant aux utilisateurs de clavier et de lecteurs d'écrans d'accéder plus facilement au contenu principal d'un site.

L'implémentation de Garland est visuellement cachée, mais reste disponible aux lecteurs d'écrans. En outre, si un utilisateur exclusif de clavier tabule à travers le site, le lien devient visible lorsqu'il reçoit le focus.

Pour cacher cette navigation, vous pouvez utiliser une des nouvelles classes disponibles pour cacher du contenu facilement.

hooks modifiés disponibles pour les thèmes

(discussion) Les hooks utilisés pour modifier du contenu avant qu'il soit affiché sur la page sont maintenant disponibles pour les thèmes. Parmi les plus importants à retenir il y a :

Notez que même si, techniquement, tous les hooks de modification sont exposés au thème, seuls certains d'entre eux fonctionneront étant donné le fonctionnement du bootstrap de Drupal. Si vous avez besoin d'utiliser, par exemple, hook_menu_alter, vous devrez utiliser un module. ces hooks peuvent être exposés dans template.php.

Drupal 7.x :

<?php
/**
* Implémente hook_page_alter().
*/
function mytheme_page_alter(&$page) {
  
// Supprime des éléments de la page.
}

/**
* Implémente hook_css_alter().
*/
function mytheme_css_alter(&$css) {
  
// Remplace des fichiers CSS avec celui du thème.
}
?>

Les feuilles de style du module System ont été réorganisées pour dissocier les styles « comportement » des styles de présentation

(discussion) Récapitulatif des changements :

  • Les styles de default.css ont été fusionnés dans system.css et default.css a été supprimé.
  • system-behaviour.css a été ajouté aux house behavior-supporting styles. Par exemple, styles pour l'auto-complétion, glisser-déposer, groupes de champs repliables, jauge de progression, etc.

Nouveau paramètre de thème pour l'affichage du lien du module Shortcut "add to shortcuts"

Dans Drupal 7, vous remarquerez que lorsque le module Shortcut est activé, le thème d'administration du noyau 7 affiche un plus ou un moins à côté du titre de chaque page (pour les utilisateurs disposant des droits adéquats), ce qui permet aux utilisateurs d'ajouter ou supprimer la page de leurs raccourcis avec un seul clic sur le lien.

L'aspect de ce lien est contrôlé par un paramètre du thème. Si vous voulez qu'il soit affiché dans votre thème lorsque le module Shrotcut est activé, ajoutez la ligne de code suivante à votre fichier .info du thème :

settings[shortcut_module_link] = 1

Les surcharges spécifiques de thèmes d'un thème générique utilisent le délimiteur -- au lieu de -

Dans Drupal 6, des fichiers gabarits peuvent être surchargés de façon ciblée. Par exemple, le thème peut contenir un fichier node-article.tpl.php qui sera utilisé par les nodes de ce type d'article seulement. Dans Drupal 7, ils ont besoin d'être renommés pour utiliser un double tiret. Par exemple, node--article.tpl.php. Un tiret simple est toujours utilisé pour séparer les mots : par exemple, user-picture.tpl.php ou node--long-content-type-name.tpl.php, ainsi le double tiret indique toujours une surcharge plus ciblée de ce qui précède le « -- ».

Si votre thème les implémente, consultez également http://drupal.org/update/modules/6/7#theme_hook_suggestions_2 pour l'impact sur les fonctions de pré-traitement.

Les fichiers CSS sont parfois chargées avec la balise @import, parfois avec la balise LINK

(discussion) Avant Drupal 6, les fichiers CSS étaient ajoutés à la page en utilisant une directive @import à l'intérieur des balises STYLE. Drupal 6 est passé aux balises LINK. Avec Drupal 7, les balises LINK sont utilisées lorsque le paramètre de performance « Aggregate and compress CSS files into one file » est activé, mais les directives @import sont parfois utilisées lorsque ce paramètre est désactivé. C'était nécessaire pour contourner une limitation d'Internet Explorer qui ne pouvait charger que les 31 premières balises ajoutant des fichiers CSS. Consultez la documentation de l'API concernant drupal_pre_render_styles() pour davantage d'explications sur l'usage de LINK et de @import.

Les fichiers CSS ciblant des navigateurs peuvent et doivent être ajoutées en utilisant drupal_add_css()

(discussion) Drupal 7 permet de spécifier une clé « browsers » lorsqu'on appelle drupal_add_css().

Drupal 6 : page.tpl.php de Garland

<?php
...
&
lt;?php print $styles ? >
&
lt;!--[if lt IE 7]>
  &
lt;?php print phptemplate_get_ie_styles(); ? >
&
lt;![endif]-->
...
?>

template.php de Garland :

<?php
...
function 
phptemplate_get_ie_styles() {
  global 
$language;

  
$iecss '<link type="text/css" rel="stylesheet" media="all" href="'base_path() . path_to_theme() .'/fix-ie.css" />';
  if (
$language->direction == LANGUAGE_RTL) {
    
$iecss .= '<style type="text/css" media="all">@import "'base_path() . path_to_theme() .'/fix-ie-rtl.css";</style>';
  }

  return 
$iecss;
}
...
?>

Drupal 7 :

page.tpl.php de Garland

<?php
...
function 
garland_preprocess_html(&$vars) {
  ...
  
drupal_add_css(path_to_theme() . '/fix-ie.css', array('weight' => CSS_THEME'browsers' => array('IE' => 'lt IE 7''!IE' => FALSE), 'preprocess' => FALSE));
}
...
?>

Consultez la documentation de l'API sur drupal_pre_render_conditional_comments() pour les détails des clés IE et !IE.

Il est conseillé que les thèmes utilisent toujours drupal_add_css() pour ajouter un fichier CSS, ainsi Drupal connaît le nombre exact de feuilles de style ajoutées. Une donnée qui peut être nécessaire lorsqu'on approche des limites d'Internet Explorer qui ne peut charger que les 31 premières balises LINK/STYLE.

Surcharges ciblées (suggestions) disponibles pour theme_menu_link() et theme_menu_tree()

(discussion) En plus de quelques modifications dans le rendu des menus, un thème Drupal 7 peut implémenter une fonction NOMDUTHEME_menu_tree__NOM_MENU() ou NOMDUTHEME_menu_link__NOM_MENU() pour surcharger theme_menu_tree() / theme_menu_link() d'un menu spécifique. Par exemple, THEMENAME_menu_link__management() surchargera theme_menu_link() pour les liens d'un menu « d'administration ». C'est semblable à comment "node--article.tpl.php" surcharge "node.tpl.php".

theme_submenu() a été supprimé

(discussion) Le noyau Drupal ne fournit plus theme_submenu().

Nouvelles variables de gabarit : $title_prefix et $title_suffix

(discussion) Les gabarits Drupal 7 disposent de deux nouvelles variables standard, $title_prefix et $title_suffix qui sont des tableaux renderable contenant des données destinées à être affichées avant ou après, respectivement, la balise du titre principal siituée dans le gabarit.

Tous les gabarits standard susceptibles de contenir un titre (par exemple, les nodes, les blocs, les commentaires, le fichier page.tpl.php principal, etc) devraient mettre en forme ces variables. Il est important que les variables puissent être mises en forme même si le titre n'est pas affiché, puisque les variables peuvent contenir des données importantes ajoutées par les modules (par exemple, des liens contextuels) et intimement associées au gabarit.

Exemple (à partir de page.tpl.php) :

<?php
 
print render($title_prefix); ?>
<?php 
if ($title): ?><h1 class="title" id="page-title"><?php print $title?></h1><?php endif; ?>
<?php 
print render($title_suffix); 
?>

theme_submenu() a été supprimé

theme_node_form() a été supprimé

(discussion)

Le noyau Drupal ne fournit plus theme_node_form(). Les nodes formulaires ont maintenant leurs classes CSS .node-form et .node-TYPE-form afin de faciliter leur mise en forme.

node_get_types() renommé en node_type_get_types()

Dans template.php, rempalcez :

foreach (node_get_types() as $type => $name) {
unset($settings['toggle_node_info_' . $type]);
}

par :

foreach(node_type_get_types() as $type => $name) {
unset($settings['toggle_node_info_'. $type]);
}

Les thèmes du noyau (core) contiennent désormais de package = Core dans leurs fichiers .info

(discussion)

La ligne package = Core a été ajoutée au fichier .info de chaque thème du noyau. Cette propriété est propre au noyau et a été ajoutée pour que le module Update Manager identifie plus facilement les modules et thèmes du noyau. Elle ne doit pas être utilisée dans les thèmes contributifs ou personnalisés.

Pour les titres des résultats de recherches, search-result.tpl.php dispose de ses propres entêtes H3

(discussion)

Afin de faciliter la navigation-clavier, des balises H3 sont maintenant utilisées pour chaque titre de résultat de recherche. Cela implique une conversion de listes DL en listes OL dans deux fichiers - search-results.tpl.php et search-result.tpl.php

Balises Drupal 6 pour search-results.tpl.php:

<dl class="search-results <?php print $type; ?>-results">
  <?php print $search_results; ?>
</dl>
<?php print $pager; ?>

Balises Drupal 7 pour search-results.tpl.php:

<?php
 
if ($search_results) : ?>
  <h2><?php print t('Search results');?></h2>
  <ol class="search-results <?php print $type?>-results">
    <?php print $search_results?>
  </ol>
  <?php print $pager?>
<?php 
else : ?>
  <h2><?php print t('Your search yielded no results');?></h2>
  <?php print search_help('search#noresults'drupal_help_arg()); ?>
<?php 
endif; 
?>

Balises Drupal 6 pour search-result.tpl.php:

<dt class="title">
  <a href="<?php print $url; ?>"><?php print $title; ?></a>
</dt>
<dd>
  <?php if ($snippet) : ?>
    <p class="search-snippet"><?php print $snippet; ?></p>
  <?php endif; ?>
  <?php if ($info) : ?>
  <p class="search-info"><?php print $info; ?></p>
  <?php endif; ?>
</dd>

Balises Drupal 7 pour search-result.tpl.php:

 <li>
  <h3 class="title">
    <a href="<?php print $url; ?>"><?php print $title; ?></a>
  </h3>
  <div class="search-snippet-info">
    <?php if ($snippet) : ?>
      <p class="search-snippet"><?php print $snippet; ?></p>
    <?php endif; ?>
    <?php if ($info) : ?>
      <p class="search-info"><?php print $info; ?></p>
    <?php endif; ?>
  </div>
</li>

L'attribut name dans les balises a et map sont invalides

(discussion)

En raison de l'adoption du Doctype XHTML+RDFa 1.0 par Drupal 7 (qui hérite du doctype HTML 1.1), le code HTML doit être compatible XHTML 1.1, et, ne particulier, il ne doit pas y avoir d'attribut name dans les balises a et map.

6.x

<a id="new" name="new">

7.x

<a id="new">