Jump to content

Ernestine

Membre+
  • Content Count

    1294
  • Joined

  • Last visited

Everything posted by Ernestine

  1. Si "A l'eau" devient "A l\'eau" , c'est que Magic Quote est bel et bien activé sur ton serveur. Tu peux le désactiver avec : ini_set("magic_quotes_gpc", 0) ; Si ton hébergeur le permet. Sinon, tu peux effectivement utiliser stripslashes pour empêcher l'échappement. Et dans le doute, tu peux n'appliquer stripslashes qu'à condition que magic quote soit activé : if(get_magic_quotes_gpc()==1) $valeur = stripslashes($valeur); Fais bien attention ensuite à échapper ces valeurs (avec mysql_real_escape_string si tu es sur mysql) si tu les introduis en base de données.
  2. Pas forcément : tablettes, téléphones, etc... Que tu sois sur un iPhone 3, dont la surface physique de l'écran est 320x480px, ou sur un iPad3 (surface physique 1536x2048px), la largeur du viewport utilisée par Safari est dans les deux cas de 980 pixels, qu'on soit d'ailleurs en mode portrait ou paysage. Idem pour Android 4, Opera mobile, et d'autres. Sur IE mobile c'est 1024 pixels. On peut régler cette dimension avec la balise meta viewport, mais ce n'est pas ça qui résoudra ton problème. Voir par exemple : http://www.alsacreations.com/article/lire/1490-comprendre-le-viewport-dans-le-web-mobile.html
  3. Tu peux regarder le plugin dialog de jQuery UI : http://jqueryui.com/dialog/ Et il existe des tas d'autres plugins qui font ça. Ou sinon tu crées un bloc en plein centre de la page, tu le mets en display none, et en js tu fais un timer qui au bout de quelques secondes le passe en display block.
  4. Si le bloc de contenu principal fait la même largeur (ou plus) que la largeur du viewport, je ne vois vraiment pas comment tu peux afficher quoi que ce soit de part et d'autre de ce bloc. A moins de le réduire en largeur sur les versions mobiles, par exemple en faisant un design responsive. Mais est-ce que ça vaut le coup de réduire les dimensions du contenu utile pour afficher un background publicitaire sur mobile ?
  5. Un truc important aussi, c'est de savoir ce qui va être fait de ces informations. Si elles sont destinées uniquement à être lues par les commerciaux, à la façon d'un simple texte ou une simple fiche technique, alors il n'y a pas besoin de faire un schémas de base de données complexe : il suffira de les stocker en BDD de façon très basique. Par contre, si les informations recueillies sont destinées à être traitées (par exemple triées par catégories, filtrées selon que telle ou telle option est sélectionnée, etc), alors il devient nécessaire de les structurer un minimum en base. Donc la première question c'est de savoir ce qui va être fait de ces données.
  6. Salut, Sur le site que tu montres en exemple (aufeminin.com), l'habillage publicitaire n'est autre qu'une grosse image placée en background du body, l'image est : http://www.aufeminin.com/clients/skin/milka-03-13/fond.jpg Partant de là, ils ont englobé leur bloc principal (de largeur fixe 1001 pixels) dans des blocs transparents de largeur 100%, et le clic sur ces blocs renvoie sur l'autre site dont ils font la publicité. Pour une fenêtre de 1000 pixels de large, évidemment, la publicité n'apparaît pas de part et d'autre du bloc principal. A partir de 1000 pixels, elle commence à apparaître. 1/ Si tu mets l'habillage en background du body, il sera toujours en arrière plan. 2/ Le plus simple est de ne pas gérer la hauteur. A la limite, définir des dimensions en fonction de celles de la fenêtre, c'est possible (mais il faut envisager tous les cas de figure, surtout si on ne veut pas que l'image soit déformée), mais en fonction du contenu, sachant que le contenu est de hauteur variable, c'est possible, mais c'est galère, donc à voir si ça vaut vraiment le coup. 3/ En général, la largeur en pixels d'un viewport de navigateur mobile est de 980 pixels. Donc si ton bloc principal de contenu est d'une largeur supérieure à 980 pixels, il va de soi que l'arrière plan n'a pas de place pour apparaître sur les côtés.
  7. Merci, mais je n'utilise pas Wordpress (du moins pas uniquement), et la compatibilité avec jQuery Validation est une nécessité, car je l'utilise systématiquement sur tous mes formulaires. Et c'est bien sûr totalement indépendant du CMS utilisé, puisque la validation javascript se passe côté client. Pour l'instant j'ai commencé à créer un plugin répondant à cette demande, il permet déjà de customiser et valider les checkboxes et les select/options, mais quand je vois le nombre d'options et de méthodes de jQuery Validation, je me dis que ça va prendre beaucoup de temps pour arriver à quelque chose de vraiment fonctionnel et réutilisable.
  8. Sur la démo que tu montres, il semble pourtant que la casse a été respectée. Sinon apparemment, la fonction truncate_post n'est pas dans le Wordpress de base, elle doit faire partie de l'un des plugins du thème. Du coup on ne peut jamais être sûr du bon fonctionnement, car Dieu sait qui l'a codée. Mais bon si elle se contente de tronquer un texte y a pas de raisons que ça bugue, ce n'est pas de la grosse opération. Par contre je ne trouve aucune doc dessus. Apparemment elle prend deux arguments : le premier est la longueur de la chaîne souhaitée, et le deuxième : encore une fois, impossible à savoir, à moins d'aller voir dans le code. Par contre tu as une fonction de Wordpress qui apparemment fait la même chose, et qui est peut-être plus fiable : http://codex.wordpress.org/Function_Reference/the_excerpt
  9. Bonjour, Il existe des plugins jQuery de customization de formulaire (genre Uniform), et il existe des plugins de validation, notamment le meilleur de tous à ma connaissance : Validation. Malheureusement on ne peut jamais coupler les deux, car les plugins de custom formulaire créent des "fakes" des différents champs, du coup la Validation se perd complètement (ça n'applique pas les class d'erreur aux bons éléments, ça ne détecte pas toujours les évènements "change" sur tel ou tel champ, etc). Connaissez-vous donc un plugin jQuery de customization de formulaire qui fonctionnerait AVEC jQuery Validation ?
  10. Il n'y a pas à être réfractaire ou pas, en xhtml strict l'attribut target est interdit, en html5 il est autorisé, donc selon le doctype choisi on utilise la méthode qui convient, voila tout.
  11. Peu importe que le formulaire existe ou pas, ce qui compte, ce n'est pas le formulaire lui-même, mais le script qui en fait le traitement. Et ce script est certainement encore sur ton serveur. Il doit y avoir sur ton site un contrôleur qui intercepte le post du formulaire et l'oriente sur la bonne action. Du coup, le formulaire peut-être posté directement vers la racine de ton site, le contrôleur va continuer de le traiter. Il faut que tu supprimes ou modifies le traitement du formulaire. Ton site est fait comment ? PHP maison ? Framework ? CMS ?
  12. Enfin bon là ta social bar semble être de largeur et de hauteur fixes, il est donc très simple de faire les arrondis en lui mettant en background un png avec arrondis dans les angles Ça se résume à une seule malheureuse ligne dans le CSS. Autant la question de la technique peut se poser quand les dimensions sont fluides (car il faut alors manipuler plusieurs blocs et plusieurs images pour les coins), autant pour un bloc de dimensions fixes, je ne vois pas où est le problème.
  13. Pas la peine de demander la suppression de la page dans Google ou autre, car les moteurs de recherche ne stockent évidemment que la partie cliente du formulaire, et les robots spammeurs ne l'utilisent même pas (si ce n'est la première fois pour connaître les champs et les enregistrer) alors que là c'est surtout la partie serveur qu'il faut désactiver, c'est à dire s'assurer que le traitement du formulaire n'existe plus, ou qu'il n'est plus appelé par la même url (la valeur de l'attribut "action" du formulaire). Quelle était l'url renseignée dans l'attribut action de ce formulaire ? Cette url répond-elle toujours ? Si oui, il faut s'occuper de ça. Si non, c'est que le problème est complètement ailleurs (ce robot connaîtrait tout simplement ton adresse email).
  14. Eh bien tu télécharges et inclues jQuery à ton site, puis tu télécharges et inclues un package jQueyrUI (en prenant au minimum "Core", "Widget", et "Progressbar"), ensuite tu copies-colles le code d'exemple et tu l'adaptes à tes besoins grâce aux options. Après, si c'est une simple progressbar statique et sans méthodes particulières, pas la peine d'aller télécharger tout ça, le plus simple est d'en créer une toi même : <div id="progressbar"> <div id="progressbar_jauge"></div> </div> En décorant tout ça et en attribuant la bonne largeur à progressbar_jauge
  15. Salut, La progress bar que tu montres en exemple sur ce site n'est autre que le plugin Progressbar de jQueryUI, que tu trouveras à cette adresse : http://jqueryui.com/progressbar/ Et pour les options/méthodes/évènements : http://api.jqueryui.com/progressbar/
  16. Plutôt que hauteur = window.innerHeight; Mets donc : hauteur = document.documentElement.clientHeight; ça marchera sur tous les navigateurs Pour ton deuxième problème, le moyen le plus radical pour faire des coins arrondis sur IE7 et IE8, ça reste l'utilisation d'images pour simuler ces arrondis.
  17. Oui apparemment ils ne se sont pas trop cassés, d'après l'article d'Abondance cité ci-dessus, Quant utilise Bing et Yahoo pour la partie moteur, Amazon pour la partie Shopping, Wikipedia pour la partie Qnowledge Graph, et Kurrently pour la partie sociale
  18. Il y a deux choses à faire : 1/ le transfert avec changement de contact administratif 2/ le changement de propriétaire pour que ton entreprise devienne la titulaire du NDD. Tu peux très bien réaliser le point 1 sans t'occuper de savoir qui est propriétaire. Si tu étais webmaster indépendant, tu pourrais même tout simplement te contenter du transfert, et simplement informer ton client qu'il n'est pas titulaire, et ce serait alors à lui de prendre contact avec l'ancien webmaster pour faire la démarche (la "propriété" du NDD, ce n'est pas ton problème). Mais puisque tu es le webmaster de cette entreprise, alors vous allez également devoir vous occuper du deuxième point, qui est évidemment un peu plus délicat que le premier, puisqu'il s'agit d'un changement de propriétaire (ou plutôt locataire), la démarche est un peu plus complexe. Comme dit Dadou, c'est à ton entreprise de prendre contact avec lui pour lui demander de débloquer tout ça. En général ça se passe plutôt bien, sauf quand l'ancien webmaster a mis la clé sous la porte et ne répond plus au téléphone, là c'est un peu plus long, mais y a pas de raison
  19. Normalement, le nom de domaine est enregistré au nom du client et non pas au nom du webmaster. Le précédent webmaster doit être simplement enregistré comme contact technique/administratif, etc, ce qui lui permet de gérer le NDD sans en être le propriétaire. Il ne s'agit donc pas d'un changement de propriétaire, mais simplement de changer les contacts associés, de façon à ce que ce soit toi le nouveau contact administratif. Il n'y a donc pas de vente ni d'achat à effectuer, mais simplement un changement de contact. Si le NDD est actuellement enregistré chez un autre registrar que le tien, alors tu dois effectuer un transfert du NDD de l'ancien registrar vers le tien. Si tu restes chez le même registrar, alors il faut simplement changer le contact administratif. Dans les deux cas la procédure est à peu près la même, et assez simple : le précédent webmaster doit débloquer son NDD pour en autoriser le transfert. Quand il le débloque, son registrar lui fournit un code d'autorisation, qu'il doit te communiquer. Tu peux alors te rendre sur le site de ton registrar et demander à récupérer ce NDD, en fournissant le code d'autorisation. Voici une page d'informations : http://wiki.gandi.net/fr/domains/transfer?s=transfert (c'est sur le site de Gandi mais ces infos sont à peu près valables pour tous les registrars).
  20. Pour les <ul> qui correspondent à ces menus, supprime : top: 38px; Et mets à la place : bottom: 38px; Ainsi ils devraient se placer comme il faut au-dessus
  21. Dans la page de ton formulaire, il faut qu'il y ait une div vide, prête à l'emploi pour l'affichage des erreurs. Par exemple juste avant le formulaire : <div id="errors"></div> Quand tu récupères les erreurs avec ajax, tu n'as plus qu'à les y insérer dans ce div : function(data) {$("#errors").text(data['erreur3']);} Bon, si tu veux faire ça correctement, prépare-toi à y passer un moment. L'idéal, c'est que côté php, toutes les erreurs soient réunies en un seul tableau, puis renvoyer ce tableau encodé en json. Ensuite, côté javascript, l'idéal est d'avoir une fonction afficherErrors() qui va prendre ce tableau d'erreurs et le transformer en liste ul/li qui va être affiché dans à l'endroit prévu pour les erreurs. Idem pour les messages de succès. Il est également préférable que cette liste d'erreurs se vide chaque fois que le formulaire est soumis de nouveau, et éventuellement prévoir une petite image indiquant que le traitement est en cours, etc... Par ailleurs, pour la majorité des champs, inutile de faire des requêtes Ajax. Pas la peine de faire une requête ajax pour savoir si une adresse email est valide (par exemple), puisque ceci peut se faire en javascript. A ce titre, le plugin de validation peut t'aider : http://bassistance.de/jquery-plugins/jquery-plugin-validation/ Voila, on ne peut pas faire le code à ta place, faut juste que tu comprennes bien le principe et ça ira tout seul.
×
×
  • Create New...