[resolu]Module hook_form_alter

Information importante

En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".

Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact


De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.

Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".

Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.

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

Forum : 
Version de Drupal : 

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.

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.

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.

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.