Jeanluc

Ce problème ne concerne pas le type d'hébergement. Quand le code source d'une page utilise "/css/site.css", c'est le navigateur du visiteur qui va transformer cette adresse en "[i]http://sous-domaine.domaine.com/css/site.css". Le serveur n'utilisera jamais "/css/site.css" directement. Il faut évidemment que tu mettes les documents dans le bon répertoire (voir la réponse de Dan). Jean-Luc

Résultat: [root@le_domaine ~]# sudo -u r6d3g9 sh -c "ls -l /var/www/vhosts/le_domaine.com/statistics/logs" total 1440588 -rwxr-xr-x 1 r6d3g9 psacln 2597882 2009-01-05 11:04 access_log -rwxr-xr-x 1 r6d3g9 psacln 1233012591 2009-01-05 04:53 access_log.processed -rwxr-xr-x 1 r6d3g9 psacln 108475408 2008-08-03 04:55 access_log.processed.1.gz -rwxr-xr-x 1 r6d3g9 psacln 0 2009-01-05 04:53 access_ssl_log -rwxr-xr-x 1 r6d3g9 psacln 183342 2008-12-31 04:53 access_ssl_log.processed -rwxr-xr-x 1 r6d3g9 psacln 73244240 2009-01-05 11:03 error_log -rwxr-xr-x 1 r6d3g9 psacln 52137624 2008-12-17 05:00 error_log.1.gz -rwxr-xr-x 1 r6d3g9 psacln 0 2009-01-05 04:53 xferlog_regular -rwxr-xr-x 1 r6d3g9 psacln 3995655 2009-01-05 04:53 xferlog_regular.processed [root@le_domaine ~]# Jean-Luc

J'obtiens ceci: [root@le_domaine logs]# sudo -u r6d3g9 "ls -l /var/www/vhosts/le_domaine.com/statistics/logs" sudo: ls -l /var/www/vhosts/le_domaine.com/statistics/logs: command not found [root@le_domaine logs]# [edit] Par contre, la même commande sans le -l me donne bien le répertoire. Je n'y comprends rien. [/edit] Jean-Luc

J'ai placé cette commande dans un script Perl de test que je lance à partir de mon browser. Je vois bien le répertoire logs quand je lance la même commande comme root. Le but est de comprendre pourquoi un autre script n'arrive pas à lire le fichier log quand il est lancé par un web user, alors qu'il peut le faire quand il est lancé par cron. Pour le contenu de logs, j'ai ceci: [root@le_domaine logs]# ls -l total 1437040 -rwxr-xr-x 1 r6d3g9 psacln 90191 2009-01-05 05:19 access_log -rwxr-xr-x 1 r6d3g9 psacln 1233012591 2009-01-05 04:53 access_log.processed -rwxr-xr-x 1 r6d3g9 psacln 108475408 2008-08-03 04:55 access_log.processed.1.gz -rwxr-xr-x 1 r6d3g9 psacln 0 2009-01-05 04:53 access_ssl_log -rwxr-xr-x 1 r6d3g9 psacln 183342 2008-12-31 04:53 access_ssl_log.processed -rwxr-xr-x 1 r6d3g9 psacln 72114335 2009-01-05 05:19 error_log -rwxr-xr-x 1 r6d3g9 psacln 52137624 2008-12-17 05:00 error_log.1.gz -rwxr-xr-x 1 r6d3g9 psacln 0 2009-01-05 04:53 xferlog_regular -rwxr-xr-x 1 r6d3g9 psacln 3995655 2009-01-05 04:53 xferlog_regular.processed [root@le_domaine logs]# Si l'utilisateur web demande whoami, la réponse est r6d3g9. Merci pour ton aide. Jean-Luc

Bonjour, La commande ls -lR /var/www/vhosts/le_domaine.com/statistics me donne : /var/www/vhosts/le_domaine.com/statistics: total 40 drwxr-xr-x 2 root root 4096 Dec 24 07:42 anon_ftpstat drwxr-xr-x 2 root root 4096 Dec 24 07:42 ftpstat drwxr-xr-x 2 root root 4096 Dec 19 09:24 logs drwxr-xr-x 2 root root 4096 Dec 24 07:42 webstat drwxr-xr-x 2 root root 4096 Dec 24 07:42 webstat-ssl /var/www/vhosts/le_domaine.com/statistics/anon_ftpstat: total 8 -rwxr-xr-x 1 root root 716 Dec 24 07:42 index.html /var/www/vhosts/le_domaine.com/statistics/ftpstat: total 8 -rwxr-xr-x 1 root root 716 Dec 24 07:42 index.html /var/www/vhosts/le_domaine.com/statistics/webstat: total 8 -rwxr-xr-x 1 root root 716 Dec 24 07:42 index.html /var/www/vhosts/le_domaine.com/statistics/webstat-ssl: total 8 -rwxr-xr-x 1 root root 716 Dec 24 07:42 index.html Pourquoi le contenu du répertoire logs (qui n'est pas vide) ne s'affiche-t-il pas ? Jean-Luc

D'accord avec la réponse de Patrick, mais en quoi cela concerne-t-il un tiers qui fait un développement ou des modifications d'un site ou d'un logiciel à la demande d'un client ? Au nom de quoi pourrait-on être poursuivi parce qu'on a exécuté des prestations de conception ou de maintenance à la demande d'un client. A priori, je ne vois pas en quoi ta responsabilité de prestataire pourrait être engagée, sauf évidemment s'il est flagrant que le client viole la loi ou un contrat (par exemple, s'il est écrit partout sur le site qu'il est la propriété de XYZ qui l'a conçu). Cela dit, je ne veux pas du tout suggérer qu'il faut mettre le client en difficulté en faisant semblant de rien quand un problème risque de se pointer. Jean-Luc

Essaie ceci: Options +FollowSymlinks RewriteEngine on RewriteCond %{HTTP_HOST} ^www.nddbasique-(.+)\.com$ RewriteRule ^(.*) http://www.nddbasique.com/$1?zone=%1 [L,R=301] Ceci ne traite pas les domaines sans www. Ils peuvent facilement être transformés en domaine avec www selon la technique habituelle. Jean-Luc

Joomla peut tout faire, mais c'est une solution lourde que je ne conseillerais pas. Personnellement, je suis fan de WordPress. Au départ, c'est un gestionnaire de blog, donc finalement de site web, puisqu'un blog, comme un site web, est un ensemble d'articles (de pages) datés ou non. Avec ton CMS, l'écriture de nouveaux articles, c'est-à-dire la création de nouvelles pages web, est du même niveau de complexité que l'utilisation d'un traitement de texte standard. Pareil pour la modification des articles et le CMS garantit l'unité de style. Dans le cas de WordPress, le style des pages est défini dans le "thème" (sorte de template). Quant à savoir quel est le meilleur CMS, tu auras autant de réponse qu'il y a de participants à ce forum. Jean-Luc

Je pense que la raison est que, même si le RedirectPermanent se trouve devant la RewriteRule, il est exécuté après. Cela serait lié à la manière dont Apache gère tout cela et il n'existerait pas de moyen de changer cet ordre. Jean-Luc

Essaie en remplaçant le RedirectPermanent par une RewriteRule que tu places avant les RewriteRule existantes. La nouvelle RewriteRule sera comme ceci: RewriteRule ^repertoire1/ancien-repertoire/(.*)$ http://www.mondomaine.fr/repertoire1/nouveau-repertoire/$1 [L,R=301] Jean-Luc

Ton RedirectPermanent est avant la RewriteRule ? Jean-Luc

Tu peux configurer cela dans WordPress (rubrique "permaliens"). Jean-Luc

L'adresse [i]http://coalesce.romdev.fr/ n'est pas introuvable. Elle redirige vers [i]http://creerunreseausocial.fr/. Je ne vois pas où est le problème. Jean-Luc

Oui, mais cela prendra un certain temps. Il faut être patient et laisser faire Google. Jean-Luc

Dans "Réglages" dans la config WordPress, tu mets la nouvelle adresse dans "Adresse de WordPress (URL)" et "Adresse du blog (URL)", puis dans le dossier du blog, tu mets: Options +FollowSymlinks RewriteEngine on RewriteCond %{HTTP_HOST} !^www.creerunreseausocial.fr$ RewriteRule ^(.*) http://www.creerunreseausocial.fr/$1 [QSA,L,R=301] Jean-Luc

Essaie ceci: Redirect permanent texte1/texte2/formation-exemple,1-10.php http://www.monsite.com/texte1/texte2/formation-exemple,2-10.php? Jean-Luc

Je ne comprends pas. Quel est le rapport entre les 100 K et le spam ? Jean-Luc

Tu peux ajouter l'espace en le faisant précéder de \ (backslash). Jean-Luc

robots.txt n'empêchera pas la tentative d'affichage d'une image qui n'existe plus, car le lien vers cette image se trouvera toujours dans la page en cache. Tu pourrais peut-être donner le même nom à toutes ces images différentes. Disons que tes images s'appellent image01.jpg, image02.jpg,.... Copie chaque jour l'image du jour image**.jpg dans image_page_d_accueil.jpg et change le lien de l'image dans la page d'accueil pour qu'il pointe vers image_page_d_accueil.jpg. Ceci résoudra le problème d'image inexistante dans la page d'accueil mise en cache par Google. Une autre solution est de n'enlever les anciennes images du serveur qu'après un délai plus important. Jean-Luc

Bonjour et bienvenue sur le hub, Tu tiens compte du délai de propagation des DNS quand tu fais un changement ? Il faut parfois jusqu'à 48 heures avant que la nouvelle adresse soit prise en compte. Jean-Luc

Les anciens articles qui parlent du "vol de contenu" sont toujours sur le web, mais ils ne sont plus d'actualité. Actuellement, il ne faut plus s'inquiéter du caractère néfaste des redirections 302. Il y a quelques années, il y a eu un grave problème avec la manière dont Google les traitait,mais ce problème est résolu. Le risque de "vol de contenu" a disparu. Soit dit en passant, il n'y a jamais eu de "vol"; il y avait seulement des opportunistes qui profitaient sans scrupule d'une faiblesse des algorithmes de Google. Je serais même plus optimiste que Le-juge. Tout lien est bon à prendre, qu'il soit direct ou en redirection 302. Maintenant quand tu as le choix, préfère les liens directs qui sont manifestement plus bénéfiques, mais les autres liens ne peuvent pas nuire. Il y a des liens très bénéfiques, des liens modérément utiles, des liens inutiles, mais il n'y a pas de liens nuisibles. Jean-Luc

Merci pour la réponse. Je suis d'accord que les referrers ne sont pas toujours déterminés de la même façon quand il y a une redirection. Je ne pense pas que la vitesse de la redirection y est pour quelque chose. En fait, le referrer est exclusivement déterminé par le navigateur et je suppose que tous les naviagateurs ne suivent pas la même politique à ce niveau quand il y a redirection. Je n'ai pas non plus fait assez de tests, donc je ne sais pas aller plus loin dans la réponse. Il faudrait comparer les principaux navigateurs et les principales formes de redirection (301, 302, HTML, JavaScript) et voir ce que le serveur reçoit comme referrer des navigateurs. Jean-Luc

Si la page blanche est affichée, c'est que le navigateur a abandonné une tentative de connexion au serveur. Dans ces conditions, le programme PHP côté serveur est aussi arrêté. Le "refresh" côté navigateur consiste à essayer de recharger la page. C'est donc tout différent. Plus tu fais des "refresh" en PHP, plus tu risques qu'un de ces "refresh" aboutisse à la page blanche (problème temporaire de connexion). Donc ne fais pas de "refresh", si le contenu de la page ne doit pas changer. Jean-Luc

On dirait que, chez Google, la main droite ne sait pas ce que fait la main gauche. Google AdSense t'envoie un message pour te dire que l'accès à la version de ta page mise en cache par Google Image est interdite d'accès par le fichier robots.txt [i]http://images.google.fr/robots.txt. Tu oublies ce message sans intérêt ou tu envoies une copie à Google AdSense en leur expliquant que tu ne contrôles pas les fichiers robots.txt qu'ils mettent eux-mêmes sur leurs sites. Jean-Luc

D'accord avec Kioob. Je navigue aussi avec des onglets qui restent ouverts pendant des heures. Je ne pense pas que la bonne solution soit de mettre un rafraichissement automatique dans la page. Pour francoisch: il faut savoir qu'une page web n'établit pas une connexion continue avec le navigateur du visiteur. En réalité, le navigateur télécharge, une fois pour toute, tous les éléments de la page puis la connexion est coupée et le navigateur se débrouille. C'est seulement, si tu programmes des actions retardées en JavaScript ou autrement qu'une nouvelle connexion sera établie et c'est cette nouvelle connexion qui peut échouer et amener le message que tu vois. Jean-Luc