Archives pour la catégorie Drupal

Drupal 7 : regénérer sa cron_key en cas de problème

Au secours ! ma cron_key a disparu !!

Dernièrement, ayant des soucis de crons, j’ai suivi des tas de forums disant comment s’en sortir.
Sauf que parmi les manip, j’ai viré toutes les variables commençant par cron_
Donc dedans, il y avait la cron_key !

Des modules existent vous permettant de le faire, mais franchement, pas besoin d’installer tout un module pour le faire

drush php-eval "variable_set('cron_key', drupal_random_key());"

La cron_key sera alors de nouveau renseignée en base, et vous pourrez la récupérer comme d’habitude dans votre back-office, onglet Report (admin/reports/status).

(pour info, vous ne pouvez l’insérer avec un phpMyAdmin facilement, en créant name=cron_key, value=la valeur, car la valeur est un objet PHP sérialisé en fait.

Enjoy !

Mettre en évidence les champs d’édition d’un nœud synchronisés d’une langue à l’autre (i18n_sync)

En multilingue, lorsque votre contenu contient un grand nombre de champs en tous genres, et que certains sont copiés d’une traduction à l’autre, il est souvent utile pour le contributeur de savoir que tel ou tel champ sera écrasé dans les autres langues. De même, il saura ainsi s’il doit aller dans chaque traduction modifier le champ ou s’il sera copié d’une traduction à l’autre.

C’est le rôle du module « i18n_sync » livré avec le module i18n, mais pas activé par défaut.

Continuer la lecture de Mettre en évidence les champs d’édition d’un nœud synchronisés d’une langue à l’autre (i18n_sync) 

Ajouter LESS à un site Drupal existant

logo lesscssLESS est un langage dynamique pour écrire des CSS. C’est une surcouche en quelques sortes. Cela ajoute ce qui manque aux CSS : les fonctions, les variables, l’imbrication des instructions principalement. L’autre compilateur/language du même style est SASS. Ce sont 2 très bons outils, le choix vous appartient. Pour avoir fait quelques recherche, on trouve pas mal de librairies (type bootstrap, etc) qui utilisent LESS, d’autre part, le site de LESS est plus clair et beau, et lecompilateur est simple à intégrer, notamment dans Drupal. J’ai donc choisi LESS.

Continuer la lecture de Ajouter LESS à un site Drupal existant 

Choix d’un framework JS pour site mobile en single-page

Le site Web que je gère au quotidien repose sur Drupal. Pour faire une version mobile, la 1ère idée qui vient est simplement de faire un thème mobile et de continuer de se servir de Drupal pour desservir les pages. Mais je suis joueur, et j’avais envie depuis longtemps d’aller taquiner le JS de façon plus poussée, en faisant autre chose que du jQuery (Article très intéressant sur le sujet), étant une technologie de plus en plus utilisée, tant pour le mobile que pour des applications Web.

L’idée est donc naturellement venue de créer un site mobile « à part », appelant des Web-services Drupal qui retourneront le contenu (et seulement le contenu utilisé = perf). J’espère ainsi apprendre de nouvelle technologies, créer une application structurée, innovante, performante…

Continuer la lecture de Choix d’un framework JS pour site mobile en single-page 

Médias : supprimer les médias dont le fichier physique n’existe plus

Juste un petit morceau de code utile pour nettoyer la base des médias, qui n’existent plus physiquement.

A adapter selon vos besoins !

$q = db_query('SELECT fid, uri FROM file_managed ORDER BY fid');
$medias = $q->fetchAllAssoc('fid');

$i = 0;
foreach ($medias as $fid => $media) {

  $url = file_create_url($uri);
  $exists = file_exists($media->uri);

  if (!$exists) {
    $i++;
    var_dump($media->uri, $exists);
    $file=file_load($fid);
    file_delete($file);

    if($i>0){
      return;
    }
  }
}

return;

A mon avis, ce genre de fonctionnalité devrait exister directement via le back-office du module Médias, ce serait top. Je n’ai pas eu le temps de vérifier si les futures versions aurait une fonctionnalité similaire…

node_save d’un stdClass incomplet, jusqu’ici tout allait bien !

Après un changement d’hébergeur, me revoilà de retour !

Il m’est arrivé ces derniers jours bien des problèmes suite à la mise à jour du module « field_collection ». Ce module est certes génial, et presque indispensable selon les types de contenus à mettre en place, mais alors … que de soucis … je dirais qu’en 2 ans, sur les gros soucis que j’ai pu rencontrer quant aux données pures, field_collection était souvent en cause.

Il faut dire que le module réalise quelque-chose de techniquement pas téléphoné…

Venons-en au sujet !

Les contributeurs de mon site ont soudainement retrouvé tous les « field_collection » de leurs contenus vides …

c’est plutôt gênant, heureusement que j’avais des dumps quotidiens !!

 

Pourquoi ?

Continuer la lecture de node_save d’un stdClass incomplet, jusqu’ici tout allait bien ! 

Contexte : ne pas afficher les blocs d’une page non autorisée (403) ou non trouvée (404)

En étudiant un peu les fonctionnalités d’aperçu de contenu, j’ai découvert un module très intéressant si vous utilisez le module « context » pour entourer vos contenus de divers blocs.

Le problème était que si le contenu n’était pas publié, il n’était donc visible que par son auteur dans mon cas. En revanche, les internautes non authentifiés tombaient sur une page 403, mais tous les blocs associés au contenu, eux, s’affichaient toujours, comme si de rien n’était…

 

C’est là qu’intervient le module context_error, qui permet d’ajouter une condition à votre contexte, pour dire : « ce contexte ne s’applique que si la page n’est pas une erreur 403 ou 404 ».

Le module permet également de faire l’inverse, à savoir d’appliquer un contexte à une page 403 et/ou 404.

 

Le module est très basique, il se contente de récupérer les headers HTTP définis par Drupal en amont, et regarder le statut « 404 Not found » ou « 403 Forbidden », pour en déduire que c’est une page d’erreur ou non, et de quel type.

 

 

Comment Drupal dessert-il un hook de menu par rapport à l’URL demandée ?

Après avoir passé sa phase d’initialisation (bootstrap), Drupal appelle depuis l’index.php, la fonction chargée de trouver le bon « hook » de menu qui correspond à l’URL courante.

Dans l’ordre, ça donne :

  • menu_execute_active_handler()
    • menu_get_item()
      • _menu_translate()

Quelques explications :

menu_execute_active_handler() : charge la page de maintenance si le site est en maintenance, ou celle demandée sinon.

3 cas possibles : la page est affichée, l’utilisateur n’a pas accès, la page n’est pas trouvée.

menu_get_item() : recherche le hook de menu dans la table menu_router en gros.

_menu_translate() : Comme son nom de l’indique pas… cette fonction va vérifier les droits d’accès au hook de menu trouvé (en utilisant le « access callback » déclaré dans ce hook de menu).

 

 

Cache de bloc : attention au hook_block_view !

C’est expliqué sur drupal.org, au niveau de l’API du hook_block_view, dans un commentaire :

si le bloc est en cache, dès le 2nd affichage du bloc, le hook_block_view correspondant n’est plus appelé. Logique, c’est ce qu’on veut en mettant du cache : éviter à Drupal de recalculer à chaque coup le bloc et son rendu.

Seulement, la petite bourde facile, c’est d’utiliser drupal_add_css, drupal_add_js, drupal_add_library directement dans le callback du hook_block_view.

Erreur ! Car le JS, CSS ou la librairie ne sera ajoutée qu’une seule fois, avant que le bloc ne soit en cache. Ensuite, nada, que d’chi, vous n’aurez plus vos attachements…

Solution ?

la 1ère réponse au commentaire explique qu’on peut gérer son cache soi-même, en disant à Drupal : ne cache pas ce bloc, je m’en occupe !

La 2nde, plus « best practice » à mon sens, conseille d’utiliser tout bonnement la clé #attached de votre render Array. Ah oui, j’espère que vous utilisez un render Array, sinon, c’est pas bien !

 

En même temps, il suffit de lire la doc et de respecter les standards, mais c’est si facile de se tromper que ça valait bien un article !