Ernestine

L'idéal serait plutôt de repérer à quels endroits dans le site sont générés les urls avec paramètres, et modifier ça, de manière à ce que tous les liens du site pointent sur la bonne version d'url. Ce serait plus propre et plus efficace que le coup de la redirection 301. Mais avant ça, comme le précise Captain Torche, il faut déjà être sûr que ces paramètres ne servent pas à quelque chose. Il n'est jamais conseiller de bidouiller le code d'un CMS (car je suppose qu'il s'agit d'un CMS), c'est souvent source de gros ennuis.

Si tu veux afficher une alerte directement au moment du clic, c'est en javascript. Mais si après tu veux faire un traitement côté serveur (éventuellement pour enregistrer le résultat), alors il faut aussi le faire en php. Côté javascript ce sera un truc du style : if(document.getElementById('allergie').value=='tomate' && document.getElementById('manger').value=='bolognaise') alert('attention, vous allez être malade'); (il faut bien sûr adapter 'allergie', 'manger', 'tomate' avec les valeurs de tes champs) Côté php c'est très similaire : if($_REQUEST['allergie']=='tomate' && $_REQUEST['manger']=='bolognaise') print('attention, vous allez être malade');

Un tuto pour apprendre javascript peut-être ? En gros, il faut : - capter l'évènement clic avec onclick - lorsque cet évènement se produit, récupérer les deux valeurs sélectionnées : document.getElementById('allergie').value - ensuite, avec un simple if, regarder si les deux valeurs sont égales aux valeurs qui vont bien (ou pas), et le cas échéant, faire un alert.

C'est souvent comme ça avec Google image : les gens arrivent, ils enregistrent l'image (ou simplement son url pour l'afficher directement sur leur site et merci pour la bande passante) sans lire une seule ligne de texte et repartent aussitôt. D'ailleurs souvent ils cliquent en haut sur "Afficher l'image en taille réelle" et ne jettent pas le moindre coup d'oeil sur le site. Google image, c'est super pour les utilisateurs, mais pour les webmasters, c'est zéro.

Ce n'est pas juste un clic, c'est : - attendre que la page temporaire se charge (car il s'agit souvent d'animations publicitaires relativement lourdes) - passer plusieurs secondes à se demander si on est sur le bon site (car il faut du temps pour comprendre qu'il s'agit d'une page "bonus") - chercher le bouton pour refermer la page et accéder au site, car en général, le bouton n'est pas très visible - le sentiment d'être pris pour un consommateur qui est juste là pour manger de la pub

Salut, N'est-ce pas la plus grande absurdité de l'histoire du web, que ce type de pages avec un bouton "Accéder directement au site" ? En gros, je viens sur le site, mais au cas où, on me demande confirmation, parce qu'on ne sait jamais... C'est totalement anti-ergonomique, mais bon. Donc pour faire ça, il s'agit en général non pas d'une page proprement dite, mais d'un gros div (bloc) qui vient se positionner en position absolute par-dessus la page. Il y a aussi souvent un cookie qui s'installe, pour ne pas infliger cette horreur deux fois de suite à l'internaute. Rien de bien compliqué, mais il te faudrait quand même un minimum de connaissances en html/css. Je ne pense pas qu'il existe de solutions toutes faites pour ça.

D'accord, merci pour vos réponses Je vais donc laisser les commentaires en dur dans la page. (je reste à l'écoute de tout complément d'information)

Je sais bien, mais ma question, c'est juste de savoir si les commentaires apportent une valeur ajoutée, du point de vue des moteurs, oui ou non ?

Salut, En fait la démarche se fait plutôt dans l'autre sens. Tu ne dois pas partir d'une charte graphique existante pour y intégrer dedans un CMS (oscommerce, prestashop, etc), mais plutôt le contraire : tu installes le CMS et ensuite, tu lui appliques ta charte graphique. Avant d'opter pour oscommerce, renseigne-toi sur prestashop, il paraît que c'est mieux.

Non, puisqu'il y a une version avec les commentaires, et une version sans les commentaires, les deux pages ne sont pas identiques (la page avec commentaires peut facilement être trois ou quatre fois plus grande en quantité de mots). Et c'est justement ma question : laquelle des deux préfère google. D'un côté, les commentaires peuvent apporter une valeur ajoutée à la page aux yeux de google, car c'est un bonus d'information. D'un autre, ils peuvent aussi devenir pénalisant, quand il y a trop de hors sujet (car cela dilue le poids des mots clés de la thématique de l'article). Concrètement, on me demande de faire une pagination des commentaires via Ajax, sur un site web. Je m'interroge donc sur les effets que ça peut avoir niveau référencement. Car une fois que les commentaires seront chargés en ajax, ils ne seront plus visibles en dur par les moteurs de recherche. Je veux donc d'abord être sûre que ce n'est pas pénalisant, avant de faire n'importe quoi.

Bonjour, Je voudrais connaître l'effet des commentaires sur les blogs/sites d'actus/sites d'informations, etc, par rapport au référencement. Si le webmaster écrit un bon article (assez long, bien fourni, détaillé, documenté, etc) et que cet article est suivi d'un nombre "raisonnable" de commentaires (disons une vingtaine) qui restent dans le sujet, est-ce que ces commentaires vont booster globalement le référencement de la page, puisqu'ils apportent du contenu ? Que faire avec un article qui comporte plusieurs dizaines (voire centaines) de commentaires, sachant que dans le lot, il y en a forcément qui sont hors sujet ? (et donc plutôt négatifs pour l'optimisation de la page pour un terme donné) Une bonne manière de le tester serait de mettre en ligne deux versions d'un même article : la version sans commentaires, et la version avec les commentaires, et voir laquelle des deux ressort dans google pour une requête sur le titre de l'article. Quelqu'un a-t-il déjà effectué ce genre de test ? Bref, toutes les idées, solutions et éclaircissements sont les bienvenus, merci d'avance.

Salut, Les fonctions jquery s'appliquent aux objets (textarea dans ton cas) chargés dès le départ dans la page. Elles ne s'appliquent pas aux éléments chargés ultérieurement (via ajax). Pour résoudre en partie ce problème, tu as la fonction live() : http://api.jquery.com/live/

Salut, Tu peux ajouter après les trois divs un div vide avec pour style clear both : <div id="global"> <div>contenu bloc1</div> <div>contenu bloc2</div> <div>contenu bloc3</div> <div style="clear: both; float: none; height: 0;"></div> </div> "clear: both" signifie que le div ne peut pas se trouver sur une ligne horizontale où se trouverait un élément flottant. Le div sera donc forcément au-dessous des trois autres, ce qui forcera le conteneur global à s'agrandir en hauteur. Dans le code j'ai mis "float:none;" et "height:0" car la façon dont tu as écrit les styles, ils vont s'appliquer à tous les divs contenus dans global (il vaudrait beaucoup mieux que tu leur appliques une classe spécifique).

Aenoa > je crois que Siriu veut le faire en javascript Sur l'évènement onsubmit du formulaire, il faut compter les options sélectionnées : var compteur = 0; for (var i=0; i<document.getElementById('SelectProd').length; i++) { if (document.getElementById('SelectProd').options[i].selected) { compteur++; } } Ensuite, si compteur vaut 0, on empêche la soumission du formulaire avec return false;

Salut, Ça ne va pas être simple. L'idéal serait que le script de migration produise un tableau de correspondances entre les ids de Dotclear et ceux de Wordpress, et à partir de ce tableau, générer la liste des redirections pour le htaccess. Ou alors tu peux peut-être utiliser les dates, puisque la date apparaît dans l'ancienne url de même que dans la nouvelle, et sous le même format (/2009/10/07/). Dans index.php, si l'url est de forme Dotclear, le script recherche la nouvelle url en se basant sur la date, et redirige sur celle-ci. Par contre, si tu as écrit plusieurs articles par jour, ça se corse.

Il est également possible de créer un fichier javascript avec l'extension .php, ça marche pareil, et de l'inclure : <script type="text/javascript" src="monscript.php"></script> Ça permet de mettre des tags php dans le javascript. Et si vraiment on veut conserver l'extension .js pour faire plus propre, on met dans le htaccess : RewriteRule ^.*monscript\.js$ monscript.php [L] Et on inclue simplement : <script type="text/javascript" src="monscript.js"></script> PS : en fait je viens de dire la même chose que Captain et Paolo.

Que le code JS soit inclus directement dans la page, ou bien dans un fichier séparé, ça ne fait aucune différence pour les moteurs de recherche : le javascript est simplement ignoré. Il n'y a aucun bénéfice, du point de vue référencement, à vouloir séparer le fichier. Mais c'est quand même bien de le faire pour la propreté du code. Pour résoudre ton problème tu peux cacher des champs dans ta page comme ça : <input type="hidden" id="truc" value="<?php echo 'machin'; ?>" /> (le value est donc généré dynamiquement en php) Ensuite dans le fichier JS, tu récupères la valeur du champ truc en javascript : var truc = document.getElementById('truc').value; et le tour est joué.

Salut, Je n'ai strictement rien compris à cette question : Mais je suppose que tu veux éviter de lier un fichier JS ? Ta solution, dans la pratique, est possible, mais plutôt comme ça : <?php $fichier_js = file_get_contents('url_du_fichier_js'); ?> Et ensuite dans la page: <script type="text/javascript"><?php echo $fichier_js; ?></script> Mais je ne vois pas l'intérêt profond de cette méthode. Au final, la quantité de lignes de code sera la même. La différence c'est que ça tiendra en un seul fichier au lieu d'avoir un fichier JS séparé. Certes, ça représente un petit gain pour le chargement, mais tellement infime (comparé au volume de données), que c'est vraiment se compliquer la vie pour rien.

Salut, Il y a pas mal de façons de résoudre ce problème. En voici une qui n'utilise pas de javascript. Le principe est de définir un seul champ "action" et deux boutons "submit : <input type="hidden" name="action" value="test" /> <input type="submit" name="submit" value="Action 1" /> <input type="submit" name="submit" value="Action 2" /> Ensuite pour le traitement du formulaire, le champ action te permet de savoir que le formulaire a été soumis, et un test sur $_REQUEST['submit'] te permet de savoir lequel des deux boutons 'submit' a été cliqué. L'inconvénient, c'est que du coup, si tu modifies la valeur d'un des boutons submit, ben ça ne marche plus (ou alors il faut aussi modifier la partie traitement). Donc c'est assez moyen. Mais dans des cas simples ça peut servir. Sinon tu peux effectivement récupérer quel bouton a été cliqué avec javascript.

Le prénom et la ville en disent aussi beaucoup... eh eh

Salut, J'ai lu l'article que tu as mis en lien dans ton premier message, et je pense que l'auteur parlait d'un cas très particulier, et pas du cas général. Car dans ton cas, le # n'a aucun rapport avec Ajax : il permet simplement de passer d'une image à l'autre au sein de la même page (c'est pour vérifier ça que je t'ai demandé l'url). Ensuite, avec le javascript posé par-dessus, les liens avec # permettent d'afficher une image particulière tout en masquant les autres en jouant sur les styles CSS, c'est une technique assez courante. D'ailleurs si tu désactives le javascript, tu constateras que toutes les images se succèdent en grande taille les unes au-dessous des autres. C'est donc du simple javascript/css, il n'y a pas d'Ajax dans cette page La seule url que tu peux référencer dans Google est l'url de base de la page : http://devkick.com/lab/galleria/demo_01.htm Les autres urls (avec #) sont en réalité des ancres qui correspondent à des sous-parties de la page : il n'y a rien à faire pour le référencement. Google découvrira les images tout seul.

Bonjour, Merci de nous donner l'url de ta galerie photos, car tout ceci me paraît très flou. A priori, le # n'a aucun rapport avec Ajax. Le # signifie simplement une ancre, c'est à dire un point de repère interne à la page.

Mais au final, le serveur envoie envoie une page web avec du code html. Que tu fasses des opérations avant, des setCookie() ou des header location, ça ne change rien, le résultat est le même : la production d'une page web envoyée au client. Et c'est dans cette page web (entre <body> et </body>) que doit se trouver Dewplayer. Eh bien justement, c'est dans la "page suivante" que doit être inserré le Dewplayer (en réalité ce n'est pas une question de "page", il vaut mieux parler de fichiers, qui eux-mêmes produisent des pages). Je te conseille de reprendre les choses calmement dans l'ordre. Pour commencer, essaie simplement d'intégrer le Dewplayer et de lui faire jouer un son quelconque, sans t'occuper de ton bloc if/else. Une fois que le Dewplayer sera correctement placé et opérationnel, et seulement à ce moment-là, tu pourras y greffer par dessus ton bloc if/else.

La redirection n'est même pas effectuée, puisqu'il est trop tard pour la faire. C'est une redirection serveur (header location), or, comment le serveur pourrait-il rediriger s'il a déjà commencé à envoyer du code html (le code de dewplayer) ? C'est ce qu'indique justement l'erreur "Cannot modify header information".

C'est bien ce qui ressortait de tes messages : ton code d'insertion de Dewplayer n'est pas du tout placé au bon endroit. Là en gros, tu insères Dewplayer et un peu plus loin tu fais un Header Location (redirection vers un autre fichier), il est donc normal que ça produise une erreur. Comme expliqué plus haut, le code de Dewplayer doit impérativement se trouver quelque part entre les balises <body> et </body> de ton fichier. En aucun cas tu ne peux le placer ailleurs. Tu peux tout à fait conserver ce bloc de code mais sans mettre le Dewplayer. Ensuite, dans la page proprement dite (entre <body> et </body>), tu peux effectuer à nouveau le test if : <?php if ( $_COOKIE['Service']['reference'] == strtolower ( $reponse ) ) { ?> <div style="display:none;"> <object type="application/x-shockwave-flash" data="dewplayer.swf?mp3=Windows XP Erreur.mp3&autostart=1" width="200" height="20"><param name="wmode" value="transparent"><param name="movie" value="dewplayer.swf?mp3=Windows XP Erreur.mp3&autostart=1" /></object> </div> <?php } ?> (les setCookies(), par contre, doivent bel et bien être faits avant l'envoi du code html)