[resolu]Module hook_form_alter

Catégories:

Bonjour,

Je suis en train de réaliser mes premiers modules, et je souhaiterais faire un hook_form_alter sur un champ de formulaire exposé dans un bloc créé à partir de views.

Questions :

Comment retrouver l’id du formulaire créé ? (J’ai bien regardé dans le code source mais ça n’indique pas toujours le bon, exemple user_login_block)

Idem pour le nom du champ que l’on souhaite modifier ?

Comment supprimer le label d’un champ existant ( $form[‘field’][‘#title’] )Si l’on met =”, ça le supprime ?

voici mon code de mon module

function form_boutiques_form_alter(&$form, &$form_state, $form_id) {
if($form_id=='views-exposed-form-chercher-magasin-default' ){
               
       $form['uid']['#default_value']= t('Chercher un magasin');
       
      
   }
}

et celui de mon html

<form id="views-exposed-form-chercher-magasin-default" method="get" accept-charset="UTF-8" action="/vitrines_roanne/recherche-magasin">
<div><div class="views-exposed-form">
  <div class="views-exposed-widgets clear-block">
          <div class="views-exposed-widget">
                  <label>
            Chercher magasin          </label>
                        <div class="views-widget">
          <div id="edit-uid-wrapper" class="form-item">
<input type="text" class="form-text form-autocomplete" value="" size="60" id="edit-uid" name="uid" maxlength="128" autocomplete="OFF"/>
<div class="description">Saisissez une liste de noms d'utilisateurs séparés par des virgules.</div>
</div>
<input type="hidden" disabled="disabled" value="http://localhost/vitrines_roanne/admin/views/ajax/autocomplete/user" id="edit-uid-autocomplete" class="autocomplete autocomplete-processed"/>        </div>
      </div>
        <div class="views-exposed-widget">
      <input type="submit" class="form-submit" value="Ok" id="edit-submit-1"/>
    </div>
  </div>
</div>
</div></form>

Merci d’avance

#

Il n’y a pas de moyen direct de connaître un id (enfin si, avec FireBug mais c’est pas super pratique). Le mieux est de mettre une trace (genre error_log()) dans ton hook_form_alter et de liste ainsi tous les ID d’une page, tu devrais facilement reconnaître le bon.
Sinon, pour vider le label c’est bien cela, sauf qu’un unset() serait peut-être mieux.

Yoran - arNuméral

#

merci pour ta réponse.

J’ai également trouvé le module form inspect qui me permet d’avoir les infos sur les formulaire. Mais il prend énormément de ressources.

J’ai réussi à trouver le form_id qui est différent de ce qui apparaît dans le html.

Pour le trace si j’ai bien compris, tu fais un :

function monmodule_form_alter(&$form, &$form_state, $form_id) {
  //comme on a pas le nom du form, il le fait pour tous les form
         trace(error_log());
      
      
}

//et pour mon label je mets dans mon hook_form_alter où j'ai testé le form_id
        unset($from['monfield']['label'];

Autre question, en fait, j’ai mis une valeur par défaut ‘Chercher un magasin’ dans mon champ de recherche. Le problème c’est que c’est un champ d’autocomplétion, et
que comme le texte n’est pas trouvé, il me l’entoure en rouge et m’indique qu’il n’y a pas de résultat pour cette valeur.

Est-il possible dans views de mettre une valeur par défaut dans un champ d’autocomplétion qui ne serait pas testée ? Si non, à quel moment dois-je faire un hook pour rajouter une condition ‘si mon champ est égal à ‘Chercher un magasin’ alors je ne fais pas de test ou je ne retourne pas de message d’erreur et je n’affecte pas la CSS bord rouge ?

#

Hello
ce que tu dis m’étonnes, j’utilise toujours le code source html pour trouver l’id d’un formulaire et jusqu’ici il me semble bien que ça a marché à tous les coups. exemple quand je regarde le code source du formulaire sur lequel je suis en train de te répondre je peux voir

<input type="hidden" name="form_id" id="edit-comment-form" value="comment_form"  />

le VALUE (et pas l’id) de l’input correspond à l’id de ton formulaire.

donc ctrl+U pour voir le code source et rechercher «form_id» me parait un moyen rapide de trouver l’id d’un formulaire pour mettre en place un hook_alter.

#

Possible en effet, j’avoue que je suis très «traces» :) J’ai toujours une console qui tourne à côté de mon espace de dev, donc le plus simple pour moi reste error_log.

Yoran - arNuméral

#

héhé, j’en suis encore à notepad ++ pour développer alors j’ai mes techniques de survies :-)

#

Shoula, notepad, t’es un warior toi ;-)

Yoran - arNuméral

#

J’aimerais bien passer à un depot subversion et un truc genre eclipse mais j’arrive pas à trouver le temps de comprendre tout ça :-(

#

autre solution tu tapes 3 lignes de jquery pour virer le label ;)

Richard lascols
www.ideia.fr

#

@khtuluu Oh bé c’est super propre ça dit-moi ;-)))

/me lance un D6 et perd 3 points de santé mentale ;-)

Yoran - arNuméral

#

@nyl Ah ouais, surtout subversion, difficile de bosser sans cela

Yoran - arNuméral

#

ce que vous dites m’intéresse, moi aussi bosse avec firebug, notepad++, dreamweaver…

Yoran peux-tu m’en dire plus sur ton environnement de développement ?

Nyl Auster : bien vu, je ne regardais pas l’input mais belle et bien la balise form.

Pour mes formulaires dans les blocs avez-vous une idée sur la manière de procéder pour mettre un texte indicatif à l’intérieur de mon textfield d’autocompletion sans générer d’erreurs ?

Merci d’avance

#

@selinav hum, tu es certain de vouloir savoir ? bon ok..
- Un serveur de développement chez moi. C’est un GNU/Linux Mandriva virtualisé ( http://artisan.karma-lab.net/node/1749 ) sur mon poste de travail. L’avantage de cette approche est que je peux ainsi partage les sources d’un site entre le serveur et le poste de travail tout en ne pourrissant pas le poste de travail en y installant apache & co. Le client a assez rarement accès à ce serveur mais cela arrive (lorsque je travaille en binome généralement).

  • Sur le poste de travail, eclipse+subersive+phpeclipse (pas de bon retour sur pdt) et firefox+firebug

  • Un serveur Subversion sur une machine dédié (dedibox). Lorsque je développe, je commit régulièrement mes modifications sur ce serveur. Le client peut éventuellement y avoir un accès sécurisé. Dans d’autres cas, j’utilise son serveur de version à lui.

  • Un serveur d’intégration sur le même serveur dédié. Les sources sont lus à partir du dépôt subversion, ce qui permet de mettre à jour sans effort l’intégration par un «svn up». Le client a généralement accès au serveur d’intégration (pour donner son avis, tout ça). Dés fois il a son propre serveur d’intégration mais c’est pas souvent.

  • Un serveur de production qui est généralement celui du client (sans blagues ;-), sur lequel, là aussi j’utilise le dépôt subversion pour synchroniser les sources. La différence est que généralement le crée une branche dans le dépôt lorsque le code est stable, et je checkout uniquement cette branche.

    • Accessoirement j’ai une batterie de scripts qui me permettent de synchroniser la base de données en production sur l’intégration et/ou le développement.

En gros, le serveur subversion est central dans cette histoire car il me permet :
- de mettre à jour tous les serveurs sur la même base en une simple opération. Chez certains clients c’est même automatique en production. Dés que la branche est créée, le serveur de production s’update automatiquement.
- de pouvoir tracer qui fait quoi lorsqu’on bosse à plusieurs
- de revenir facilement en arrière en 10 secondes et en production, si y’a un pépin (genre une update de module qui plante par effet de bord, au hasard ;-)
- de backuper de manière autonome tous mes projets sans que j’ai à m’en soucier
- et cerise sur le gâteau, de partager un même drupal entre plein de projets différents ce qui me permet par exemple des mises à jour de modules sur plusieurs projets en une seule passe.

Yoran - arNuméral

#

ouhlala, c’est bien trop compliqué pour moi… Je ne comprends pas tout, je ne m’y connais pas vraiment en serveur.
Bon pour le coup tu es tranquille question sauvegarde !

J’ai un peu honte avec mon Wamp ! :-)

Une idée pour mon problème de champs exposés ?

#

J’ai pas bien compris. Dans views tu peux mettre un filtre exposé qui est en autocomplétion ? si c’est le cas je savais pas. Est ce que si tu le préremplis en javascript plutôt qu’avec le hook_form_alter ça le fait aussi ?

Sinon tu peux simplement mettre «chercher un magasin» dans la propriété description de ton champ au lieu de le mettre en valeur pas défaut, ce sera aussi clair pour l’utilisateur.

Parce que sinon, à part créer une nouvelle fonction d’autocompletion je ne sais pas… (copier-coller celle qu’utilise views, la mettre dans ton module, modifier à ton gout, créer un chemin avec le hook_menu vers cette nouvelle auto-completion, puis hook_form_alter pour essayer d’affilier l’autocompletion au chemin que tu as crée -amenant à ta fonction autocomplete custom- plutôt que par celui par défaut)

#

et oui views le permet car il me recherche un utilisateur ou de la taxonomie dans mon cas.

C’est sur j’aurais préférer mettre dans un label mais c’est la charte graphique qui l’impose…

Je comprends ton cheminement mais pas le hook_menu.
Que vient-il faire là ?

Merci

#

voir ici :
http://api.drupal.org/api/drupal/developer—topics—forms_api_reference….

un champ autocomplete a pour paramètre une url. Le hook_menu dans Drupal sert justement à déclencher une fonction à partir d’une url. (la fonction déclenchée est le paramètre callback du hook_menu). donc si tu fais une fonction autocomplete custom que tu appeles «mafonction_custom_autocomplete», il faut que tu fasses un hook_menu pour qu’un chemin mène à ma fonction ; un truc du genre

<?php
$items
['mon_url'] = array(
 
'title' => 'pouet'
  'page callback'
=> 'ma_fonction_custom_autocomplete',
 
etc...
)
?>

Après avec ton hook_form_alter tu devrais pouvoir changer le paramètre autocomplete du champ d’autocompletion pour le faire pointer vers TON chemin et donc ta fonction.

#

Ok merci pour ces explications.

je vais essayer de faire modifier la charte graphique sinon faudra que je mettes les mains dans le cambouis.

Syndiquer le contenu