TheRec

Bonjour, la gestion d'erreurs fait l'office d'un explicatif complet dans le manuel PHP... mais ce n'est pas "exactement" ce que tu demande... Pour "sortir" d’une boucle tu as l'instruction break qui arrête la boucle et qui exécute le code se trouvant après... Une autre possibilité, si ton script est appelé depuis un autre fichier avec un include ou un require, est d'utiliser la fonction return... Ainsi lorsque cette fonction est appelée dans le fichier qui a été "inclu", le reste du fichier n'est pas appelé et le script contenu a être interprété depuis la ligne qui suit l'appelle à include ou require (dans le fichier de base, depuis lequel tu as fait l'appelle pour "l'inclusion"). Dans la gestion de retour pour un formulaire ça peut être utile par exemple... mais toutes les instructions qui ont été effectuées par ton script avant ce "retour" auront été effectuées...le script ne peut pas annuler des actions qui vient de s'exécuter juste en utilisant ce genre de technique...d'ailleurs il ne peut tout simplement pas le faire... tu devrais le faire toi même. Une autre méthode pour la gestion d'erreur (très utilisée dans le framework PHP en général) est la variable de session...et lorsque l'erreur se produit, le script redirige l'utilisateur vers un page et juste avant cela enregistre le message d'erreur dans une variable de session (un tableau en général)... Cela a un inconvénient, c'est qu'il faut obligatoirement gérer une session, mais comme c'est souvent le cas dans une application, pourquoi pas EDIT: Pardon, je t'avais mal compris... le break en l'occurence ne va pas t'aider si tu souhaite continuer ta boucle

Qu'entends-tu par "regarder le membre test et monter beaucoup plus haut" ? Fais un petit effort au niveau de la grammaire, je t'avoue que ça joue beaucoup lorsqu'il s'agit de comprendre... on n'est pas à la dictées de Pivot non plus, mais cela fait partie des règles du forum, merci d'avance. Si je me force un peu et que je traduis ça par "regardez le membre test est monté beaucoup plus haut", je miserait plutôt sur un problème (X)HTML/CSS ... si tu as utilisé un tableau pour présenter ces lignes, regarde si tu ne t'es pas trompé dans la syntaxe de celui-ci pour une des lignes...

Bonjour, en fait si tu n'as pas le contrôle sur les entrées DNS (domaines, sous-domaines, ...) tu ne va pas pouvoir faire ce que tu souhaites. Le problème étant que pour effectuer une redirection depuis "www.erreur.domaine.com" il faut une entrée DNS qui corresponde à ce sous-domaine, la résolution du sous-domaine en une adresse IP est la première étape, ensuite Apache (ou autre httpd) s'occupe de gérer un VirtualHost ou un Alias et l'interprétation de fichier .htaccess est effectuée bien après encore... Désolé, mais à mon sens, tu n'as pas de solutions tant que tu n'a pas d'entrée DNS pour ton sous-domaine.

Bonjour, Ces sujets ne serait-il pas préfixé d'un "Déplacé:" ? Parce que ces deux sujets on été déplacés (par mes soins) dans les rubriques qui correspondaient plus à leur contenu, et comme plusieurs personnes avaient déjà participé à ces sujet j'ai laissé une trace de ce sujet afin que les intervenants ne soient pas troublés de ne plus trouver le sujet sur lequel ils ont participé dans la rubrique d'origine (si personne n'avait participé à ces sujets on ne laisse pas de trace habituellement). EDIT: Grillé par NorSeb

Bonjour, "FORCE" (ou tout autre variation de case, comme "force") est un mot réservé MySQL ... à ne jamais utiliser comme nom de champ ou de table lorsqu'on crée un schéma de base de données...change le nom de ton champ dans la base de données. (Tu as pu l'utiliser pour créer ta table car dans une requête CREATE ce mot clé n'est pas "réservé"...mais dans un UPDATE oui). Bonne continuation.

Effectivement...si c'est pour le parcourir, foreach fera tout à fait l'affaire... Merci Anonymous, je n'avais pas lu la question complètement.

Loin de moi l'idée de vous contredire, mais array_merge fait ce boulot à lui tout seul lorsqu'on lui passe un seul tableau en paramètre Donc : $ton_tableau = array_merge($ton_tableau); Et le tour et joué. Bonne continuation.

Comme je l'ai dit, chaque sous-domaine représente une URL canonique et donc un "site" à part entière sur Google entre autres (ce que tu ne souhaites pas). Donc si tu ne peux pas faire cette redirection depuis le sous-domaine, je ne te conseille pas d'utiliser des sous-domaines si tu souhaites que tes pages soient indexées comme faisant partie du même site (regroupées sous la même URL canonique).

Et c'est donc bien ce que je te disais, le chemin n'est pas le même si tu es à la racine de ton sous-domaine ou à la racine de ton domaine. Donc tu ne peux pas utiliser le même chemin... pour répondre à ta première question, si tu souhaites conserver tes fichiers aux places où ils se trouvent actuellement tu devras effectivement changer tes chemins d'accès en chemins absolus vers ton domaine (vu qu'ils sont accessible par-là). Ou alors tu peux changer les fichiers concernés de place, et les rendre accessible depuis ton sous-domaine...mais comment tu utilise ces fichiers sur plusieurs pages tu auras des doublons ce qui n'est pas vraiment facile à maintenir lors du développement Personnellement, j'opterais pour la première solution... Au mieux, si tu tiens à tes sous-domaines et si ton hébergeur (en mutualisé c'est parfois le cas, en dédié c'est toi qui choisi) le permet tu peux éventuellement utiliser des sous-domaines qui redirigent l'utilisateur vers tes répertoires... cela à une gros avantage au niveau du référencement, car si tu fais une redirection avec statut 301, les sous-domaines ne seront pas pris en compte par les moteurs de recherche (en tous cas ceux qui suivent les redirections HTTP correctement), seules les URL de destination des redirections seront indexée. Ce qui m'amène à ce GROS avantage, tu conserveras une seule URL canonique, car si tu utilises des sous-domaines (sans redirection) pour Google par exemple, chacun d'eux représentera une URL canonique et donc un "site" à part entière (à mon avis ce n'est pas ce que tu désire...mais je peux me tromper)

Bonsoir, Peux-tu donner plus de détails concernant ton site une fois qu'il a été publié.... Une URL du site publié ? Un exemple de code HTML avec les chemins tels que tu les as mis ? L'endroit ou tu placé tes fichiers par rapport à la racine de ton site ? L'essentiel à savoir sur les chemins lorsque tu utilises des sous-domaines, c'est que le chemin relatif à la racine de ce sous-domaine est "/" et non "/nom_du_dossier_vers_lequel_pointe_le_sous_domaine/" (ça peut paraître logique...mais c'est l'erreur la plus commune lorsqu'on passe d'un test local (dans un répertoire, à un hébergement en sous-domaine).

De rien ! Je ne suis pas un AJAX-convaincu (enfin s'il est implémenté en tenant compte de l'accessibilité, pourquoi pas), mais c'est toujours intéressant de faire des incursions dans des domaines que je connais moins (les framework AJAX/PHP)... enfin ton problème au final se trouvait plutôt sur un terrain que je connais (xHTML et sémantique) À bientôt.

Bonsoir, Il suffit de remplacer, dans "configurator.php" : <p id="choix_os"> <?php echo get_text_choix_os_html($os); ?> </p> par <div id="choix_os"> <?php echo get_text_choix_os_html($os); ?> </div> Et ton script fonctionnera En fait il ne s'agit pas d'un "bug" Firefox (franchement... IE est plus souvent coupable que FF dans ces cas-là, je sais que ce n'est pas une raison pour condamner IE avant investigations, mais je me pose d'abord des questions sur IE avant de mettre en doute FF (ou Gecko en général)). Simplement, Firefox n'autorise pas une balise "<form>" à l'intérieur d'un "<p>", ceci car c'est ce qui est recommandé par le W3C (et parce que c'est logique, un paragraphe, sémantiquement ne doit pas contenir un formulaire) ! Donc Gecko (le moteur d'affichage de Firefox), s'occupe de fermer ton <p id="choix_os"> (à ta place, parce que c'est son boulot d'avoir quelque chose d'interprétable) juste après que toi tu décides d'y mettre un formulaire (par Javascript). Un "<div>" en revanche n'a pas cette limitation, donc ton problème disparait si tu en utilise un... D'ailleurs tu peux faire de même avec tous ces paragraphes qui sont destiné à contenir des formulaires (ou autres balises prohibées dans un "<p>"), à toi de voir ce que tu prévois d'y mettre et d'utiliser les bonnes balises en conséquences. Au passage, et cela n'affecte en rien le fonctionnement de ton script, des lignes comme : $objResponse->addAssign("titre_configurator_part", "innerHTML", "" ); peuvent tout à fait être remplacées par ceci : $objResponse->addClear("titre_configurator_part", "innerHTML"); Pas que ce soit une faute grave, mais vu qu'une méthode existe, autant l'utiliser Bonne continuation.

Étonnant...J'ai bien compris, et je peux t'assurer ce ces règles fonctionnent (j'ai testé cela sur un hébergement Windows et un hébergement Linux) peut être une particularité du mod_rewrite de OVH... Dan s'y connait mieux que moi à ce niveau, peut être que la variable THE_REQUEST n'est pas renseignée chez cet hébergeur... En fait non, il faut que l'URL renvoie un status 301 de redirection pour que les moteurs de recherchent considèrent cette URL comme obsolète et remplacée par celle de la destination de ta redirection. Pour cette solution, tu vas renommer ton fichier "dossiers.php" en "dossiers2.php" et idem pour "cat.php" par exemple... et les règles à utiliser seront les suivantes : RewriteEngine On RewriteCond %{QUERY_STRING} ^id_dossier=([0-9]+)$ RewriteRule ^dossiers/dossiers.php$ /recettes/%1/? [R=301,L] RewriteRule ^recettes/([0-9]+)[/]? /dossiers/dossiers2.php?id_dossier=$1 [L] RewriteCond %{QUERY_STRING} ^idcat=([0-9]+)$ RewriteRule ^dossiers/cat.php$ /rubrique-recettes/%1/? [R=301,L] RewriteRule ^rubrique-recettes/([0-9]+)[/]? /dossiers/cat2.php?idcat=$1 [L] Je t'explique le fonctionnement d'Apache, avant d'effectuer quelque réécriture que ce soit, il va essayer de regarder si un fichier (réel) correspond à l'URL demandée par l'utilisateur...si c'est le cas, il l'envoie à l'utilisateur...sinon il passe au mod_rewrite, qui regarde si une des règles correspond à l'URL. S'il en trouve une, il l'applique, s'il n'en trouve pas, il renvoie une erreur 404 (c'est le schéma classique, il peut varie selon les cas). Dans notre cas, lorsqu'un utilisateur va tenter d'accéder à ta page par l'ancienne URL, le fichier demandé n'existant plus (tu l'as renommé), il va dont passer au mod_rewrite et la il va tomber sur la RewriteCond, qui dit que : si la QUERY_STRING commence par id_dossier=<un chiffre ou un nombre>, passer à la règle suivante... qui elle contrôle si la page demandée est bien "dossiers/dossiers.php" et si c'est le cas effectue une redirection vers ta nouvelle URL en utilisant le nombre (référence arrière de la RewriteCond %1 (le ? indique qu'il n'y a pas besoin d'appondre la QUERY_STRING, car dans ton cas ce n'est pas nécessaire). Si tout ça ne s'est pas produit, il passe à la règle de réécriture suivante (celle pour ton nouveau schéma d'URL)...ça sera le cas quand l'utilisateur demande une de tes nouvelles URL ou qu'il vient d'être redirigé avec la règle au dessus...car après redirection il procède comme si c'était une nouvelle requête bien entendu. Et tu arrives aux résultats que tu désires... en tout cas les deux solutions dont je te parle fonctionnent, je les ai testées avant de te les proposer.

En fait la règle que je t'ai donnée fonctionne...simplement elle effectue une redirection en boucle car ton fichier de base dossier.php lorsqu'il est appelé lors de la réécriture invoque la règle de redirection... qui appelle la règle de réécriture (à chaque fois une nouvelle requête...). Pour prévenir ceci, il faut vérifier, avant d'effectuer la redirection que l'utilisateur a bien demandé le fichier "dossiers.php", et non la règle de réécriture qui affiche "dossiers.php", bref le code complet est le suivant : RewriteEngine On RewriteCond %{THE_REQUEST} !/recettes/ RewriteCond %{QUERY_STRING} ^id_dossier=([0-9]+)$ RewriteRule ^dossiers/dossiers.php$ /recettes/%1/? [R=301,L] RewriteCond %{THE_REQUEST} !/rubrique-recettes/ RewriteCond %{QUERY_STRING} ^idcat=([0-9]+)$ RewriteRule ^dossiers/cat.php$ /rubrique-recettes/%1/? [R=301,L] RewriteRule ^recettes/([0-9]+)[/]? /dossiers/dossiers.php?id_dossier=$1 [L] RewriteRule ^rubrique-recettes/([0-9]+)[/]? /dossiers/cat.php?idcat=$1 [L] THE_REQUEST contient la requête HTTP complète faite depuis le navigateur... c'est la seule variable au niveau Apache que j'ai trouvée qui contient bien "/recettes/" lorsque l'utilisateur utilise la règle de réécriture (et pas une ancienne URL). Bref, si tu en trouve une autre tu peux toujours l'utiliser... Sinon une autre solution serait de renommer ton fichier "dossiers.php" et d'utiliser ce nouveau nom dans la règle de réécriture (celle qui n'est pas liée à la RewriteCond), cela n'a pas vraiment d'importance face à l'utilisateur car lorsqu'il utilisera la nouvelle URL il ne voit pas le nouveau nom du fichier (but de la réécriture) et cela ne correspond pas à la RewriteCond et lorsqu'il utilise l'ancien nom la redirection se fait car l'URL utilisée correspond à la RewriteCond. Ce n'est pas très clair, je le sais, mais ce n'est pas évident à expliquer par écrit...en tous cas, je ne trouve pas d'autres formulations pour le moment

Bonjour, Quelque chose comme : RewriteEngine On RewriteCond %{QUERY_STRING} ^id_dossier=([0-9]+)$ RewriteRule ^dossiers/dossiers.php$ /recettes/%1? [R=301,L] Devrait faire l'affaire. C'est le seul moyen à ma connaissance d'effectuer une analyse la QueryString depuis un .htaccess. Si tu as besoin d'une explication sur %1 et autres j'avais déjà traité de ceci dans ce sujet. Bonne continuation. EDIT : Non le QSA n'améliore rien... il ne fait que concaténer la QueryString (QueryString Append) après avoir effectué la réécriture et non avant...

Je l'ai expliqué un peu plus haut : Simplement parce qu'Apache avant d'effectuer une réécriture, s'occupe de vérifier si l'URL demandée par l'utilisateur pointe vers une répertoire ou un fichier existant ou non... s'il n'en trouve point, il fera la réécriture (ou redirection, suivant le cas... bref l'analyse du .htaccess du répertoire en cours). S'il en trouve un il présentera son contenu... Il y a encore une couche intermédiaire qui est activée par l'option "Multiviews" (qui permet de trouver un fichier en ne mentionnant qu'une partie de son nom dans l'URL, mais ce n'est pas le propos de ce sujet).

Tu n'étais pas loin Simplement lorsque tu définis une classe de caractère (entre parenthèses carrées), cela correspond à un caractère... puis tu l'étends avec un caractère comme * ou + ou même ? , cela signifie toute "suite" de caractères contigus de cette classe (enfin pour * et ? il peut n'y avoir qu'un seul caractère ou même aucun)... Donc en déclarant deux classes de caractères tu as définit que ceci: La chaîne doit commencer par 0 ou plusieurs caractères allant de 0 à 9 : [0-9]* La chaîne doit ensuite avoir 0 ou une lettre entre a et b : [a-b]* Alors que tu souhaitais sûrement faire ceci : RewriteRule ^([0-9a-z]+)[/]?$ /test/$1.html [L,NC] Une seule classe (contenue dans un sous-masque...définit par les parenthèses), qui doit avoir au moins 1 caractère ou plus et étant composée uniquement de caractères numériques et de lettres comprises entre a et z. Le flag "NC" (nocase) indique que la chaîne correspondra même si tu utilises des majuscules dans la chaîne et que tes classes de caractères n’autorisent pas les majuscules.

Bonsoir, Je t'invite à lire cet article dans les publications du Hub... Il y est décrit exactement ce que tu cherches à faire et même plus, donc bonne lecture.

Bonjour, Ce n'est pas étonnant... nbsp signifie non-breaking space qui se traduit par espace insécable. En d'autres termes un espace qui ne peut pas être rompu par un passage à la ligne. C'est effectivement la solution à adopter pour éviter qu'un mot soit isolé...Et IE à tendance à considérer tout ce qui n'est pas un caractère alphanumérique comme une "limite de mot" (boudary). Si en revanche, tu souhaitais que tout ton text ne soit jamais renvoyée à la ligne tu pourrais utiliser la propriété CSS : white-space: nowrap;

Pardon, je n'avais pas lu cette ligne. Si les trois premières ligne de ton site étaient : <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> Tu pourrais utiliser le validateur du W3C ... mais tu va tomber de haut car tu as environ 200 avertissements (beaucoup se répètent). Effectivement ton site est décalé avec cela, mais tu ne peux pas prétendre utiliser le validateur sans que tu lui dise ce que tu vas valider (une page HTML ? une page XHTML ?), le DOCTYPE sert à cela également... évidemment tu ne peux pas faire ça sur ton site en-ligne... fais le en local et utilise Firefox (navigateur) et une extension comme "Web Developer Bar" qui permet de valider le fichier local (Ctrl+Shift+A, une fois la barre d'outils installée). En fait, ton site utilise des tableaux pour effectuer sa présentation, je ne pense pas qu'il soit justifier d'essayer de rendre valide un site qui fait ceci. Les recommandations du W3C ne se limitent pas à la syntaxe (le validateur lui se limite à ça, mais c'est loin d'être suffisant). Rendre valide un tel site pour la validateur n'apporte "rien" à tes visiteurs...il est inaccessible pour les personnes naviguant sans feuille de style et avec par exemple un synthétiseur vocal.

Serait-il possible d'avoir une URL pour voir ce qui cause ce problème dans ta page ? Ce serait plus facile pour résoudre ton problème, ou au pire, poste le code source de ta page (complet et entre balises CODEBOX car c'est un long code certainement). En fait lorsque tu ne définit pas de DOCTYPE, ta page est interprétée en "Quirks Mode" (mode de compatibilité) alors que dès l'instant où un DOCTYPE valide est spécifié le "Strict Mode" (mode de ... L'interprétation des règles de styles et de certains autres éléments est différente suivant le mode utilisé. C'est ce qui entraine ces problèmes d'alignement chez toi certainement.

Bonjour, La ligne que tu cites ne correspond pas au DOCTYPE, c'est la balise ouvrant de l'élément <html> (elle entourera entre autre des balises comme <head>, <body>, etc.). Je ne sais pas quel DOCTYPE il te faut, il y en a plusieurs en fonction des cas, je te laisse lire cet article qui décrit chacun d'eux (apparemment dans ton cas tu utiliseras un des trois DOCTYPE XHTML 1.0).

En fait tant qu'il est sémantique, ton menu sera accessible car sans la feuille de style il sera affiché correctement. Maintenant, il ne faut pas perdre de vue la majorité de ton public, ils vont avoir les feuilles de style activées (à moins que ton public cible soit dans l'autre "camp", mais ce sont des cas vraiment particuliers). Donc il faut tout de même que les menus fonctionnent même si Javascript est désactivé et qu'ils utilisent la feuille de style. L'accessibilité ne se limite pas à la sémantique, cela regroupe également l'accès à tes pages par tout type de navigateurs et tout type d'équipements (Ordinateur, PDA, ...), ... Je t'ai décrit les cas les plus courant, mais c'est "impossible" de prévoir tout les cas bien évidemment

Oui, l'amélioration au niveau de la sémantique est notable ! Une unordered list est vraiment plus appropriée qu'une liste de définition dans le cadre d'un menu. Par contre, est-ce cela qui t'empêche de réaliser des sous-menus comme tu l'avais fait dans cette version ? Après quelques tests, voici mes constations : Le rendu dans Firefox 1.5.x (Windows XP et Mac OSX...enfin c'est la même chose de toute façon grosso modo), Safari 1.3.1 (Mac OSX), Opera 8.5 et 7.5 (Windows XP) est correcte et accessible avec ou sans Javascript. C'est ceux que j'appelle des navigateurs modernes (pas de troll, je constate juste que ce sont les navigateurs qui supportent le plus de techniques "modernes" et qui sont activement développés). Par contre sous IE6 (Windows XP), sans Javascript les sous menu ne s'affichent pas et les images PNG avec transparence alpha ne sont plus affichées (normal, les filtres se basent sur cela, je ne t'apprendrais rien). Mais cela rend le menu inaccessible aux personne ayant Javascript désactivé, mais utilisant tout de même les feuilles de style (ils sont plus nombreux qu'on le pense, les personnes travaillant dans des grandes entreprises en font partie...selon la stratégie de sécurité de l'entreprise bien entendu). Sous IE7 Beta 2 (Windows XP), le menu est inaccessible par la souris... en fait il semble que Microsoft ait changé le comportement de la unordered list pour revenir à une interprétation pareille à celle de IE 5.5 au niveau des margin et padding...simplement sous IE5.5 cela fonctionne avec la souris et sous IE7 Beta 2 lorsqu'on sort la souris de l'élément <li> déclencheur il "ferme" le menu... cela reste une version Beta, si tu es sûr que le comportement est juste, essaie d'attendre la version finale pour effectuer des tests. Pour information, IE 5.2 MAC (qui n'est plus officiellement supporté par Microsoft depuis le 31 janvier 2006) le menu n'est pas du tout affiché...mais cela a une importance relative (quoique, beaucoup de journalistes utilisent ce navigateur...enfin maintenant Microsoft leur conseille d'utiliser Safari, alors qu'ils aillent se plaindre ailleurs ) Sinon rien de spécial à signer... ha si, l'inaccessibilité du menu est comblée lorsque les styles sont désactivés, mais les personnes n'ayant pas la possibilité d'avoir Javascript activé, ont parfois tout de même envie d'utiliser les feuilles de style :S Finalement, Félicitation pour ce menu et ce tutoriel et merci de les avoir partagés avec nous, j'espère que mes remarques te serviront ! P.S. : Je peux sembler négatif, mais en fait je ne fais que des constatations pour t'aider à développer un menu encore plus efficace... ces remarques on pour but dêtre constructives

La seule solution que j'entrevois est celle-ci : HTTP Authentication with HTML Forms Et tant que tes utilisateurs ont un navigateur "moderne" et qu'il gère l'objet XmlHttpRequest ... Personnellement, pour créer l'objet xmlhttp, j'utiliserais une autre fonction que celle proposée... je testerais d'abord la possibilité d'utiliser XMLHttpRequest puis j'essayerai de charger l'ActiveX ensuite...mais dans les deux cas cela fonctionne, c'est juste une question de logique évolutive. Lorsque Javascript est désactivé, l'utilisateur devra cliquer sur un lien pour invoquer la page protégée afin de pouvoir enter ses informations... l'accessibilité est ainsi préservée.