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

Règles d'héritage

Référence en anglais sur drupal.org : 6 Mai 2009
http://drupal.org/node/109584


Avant de plonger dans les différents callbacks, nous devons apprendre les règles d'héritage, elles sont simples mais puissantes. Pour cela, nous utilisons les parents d'un path donné, par exemple les parents de node/%/view sont :

node/%
node

S'il n'y a pas de page callback de déclaré pour un path, on regarde quel est le plus proche parent qui en a et on l'utilise. Si le page callback est hérité d'un parent, alors les arguments de page, le fichier et son chemin sont également hérités du parent, mais peuvent être surchargés. La plupart du temps, il est seulement nécessaire de surcharger les arguments de page et rien d'autre.

Si un page callback est déclaré pour un path donné, il n'y a pas du tout d'héritage et les arguments de page, fichier et chemin d'accès doivent être déclarés s'ils sont nécessaires.

Par exemple :

<?php
  $items
['admin/user/roles'] = array(
    
'title' => 'Roles',
    
'page callback' => 'drupal_get_form',
    
'page arguments' => array('user_admin_new_role'),
    
'file' => 'user.admin.inc'
  
);
  
$items['admin/user/roles/edit'] = array(
    
'title' => 'Edit role',
    
'page arguments' => array('user_admin_role'),
  );
?>

Ce qui précède est un raccourci pour :

<?php
  $items
['admin/user/roles'] = array(
    
'title' => 'Roles',
    
'page callback' => 'drupal_get_form',
    
'page arguments' => array('user_admin_new_role'),
    
'file' => 'user.admin.inc'
  
);
  
$items['admin/user/roles/edit'] = array(
    
'title' => 'Edit role',
    
'page callback' => 'drupal_get_form',
    
'page arguments' => array('user_admin_role'),
    
'file' => 'user.admin.inc',
  );
?>

Notez que page callback et file sont hérités du parent alors que page arguments est déclaré (surchargé) pour ce path.

Si vous aviez :

<?php
  $items
['admin/user/roles/edit'] = array(
    
'title' => 'Edit role',
  );
?>

ce serait une raccourci pour :

<?php
  $items
['admin/user/roles/edit'] = array(
    
'title' => 'Edit role',
    
'page callback' => 'drupal_get_form',
    
'page arguments' => array('user_admin_new_role'),
    
'file' => 'user.admin.inc',
  );
?>

Dans ce cas, le callback, les arguments et le fichier sont hérités.

Si vous aviez :

<?php
  $items
['admin/user/rules'] = array(
    
'title' => 'Access rules',
    
'page callback' => 'user_admin_access',
    
'file' => 'user.admin.inc',
  );
  
$items['admin/user/rules/edit'] = array(
    
'title' => 'Edit rule',
    
'page callback' => 'user_admin_access_edit',
    
'file' => 'user.admin.inc',
  );
?>

Dans cet exemple il n'y a pas d'héritage car un page callback est déclaré pour le path admin/user/rules/edit, donc si page arguments, file et file path sont nécessaires, ils doivent être déclarés dans la déclaration de l'élément de menu.

Avant Drupal 6.2, l'héritage pour les access callbacks étaient supportés de la même façon que les page callbacks. Depuis Drupal 6.2 cependant, les access callbacks sont seulement hérités pour les tâches locales par défaut, et ne sont pas hérités dans les autres cas (ni le callback ni les arguments).

Dans le cas général (c'est à dire tous les cas sauf les tâches locales par défaut), si les access callbacks et les arguments ne sont pas paramétrés, alors les accès seront refusés (le access callback sera initialisé à zéro). Si access callback n'est pas paramétré mais que access arguments l'est alors http://api.drupal.org/api/function/user_access/6 sera utilisé comme access callback, c'est à dire que vous n'avez pas à fournir les access callback à tous les éléments de menus mais seulement à ceux qui utilisent autre chose que default_user_access(). Si access callback est paramétré mais que access arguments ne l'est pas, alors access arguments deviendra la valeurs par défaut du tableau vide.

Regardez l'implémentation de _menu_router_build pour voir comment est construit l'héritage.

Il est intéressant de noter que lorsque les éléments de menus définissent des page callbacks, cela désactive l'héritage, et cela désactive également toute imbrication basée sur les path, comme on pourrait s'y attendre. Dans le dernier exemple ci-dessus, les deux éléments de menu Access rules (admin/user/rules) et Edit rule (admin/user/rules/edit) seront de même niveau dans le menu Navigation, plutôt que d'être l'un sous l'autre (comme attendu).