Lanza

Bonsoir, Sans vouloir casser l'ambiance, tu as une sacrée concurrence. Je ne suis pas certain que les recettes de cuisine soient le marché le plus facile à conquérir aujourd'hui.

La fenêtre de commande de Windows est un poil merdique, dès qu'on s'amuse un peu avec SSH. Pour du TSE, ou une interface web, c'est kif kif. Ensuite ça dépend de l'environnement de travail, les langages et logiciels utilisés. Faire de l'ASP.Net sous Linux relève plus du masochisme qu'autre chose, par exemple. Personnellement, je suis sous Linux (Ubuntu) depuis 6 mois et je ne m'en plains pas, mais je vais probablement passer sur Mac dans pas longtemps, pour éviter de me prendre la tête avec la config des machines. Une quand on est tout seul, ça va, mais à partir du moment où il y en a plusieurs, les problèmes de drivers et compagnie peuvent rapidement devenir chronophages. A moins de prendre des machines Linux toutes prêtes chez un revendeur.

Bonsoir, "imap_headerinfo", c'est pour le protocole IMAP pas POP, donc ça risque effectivement de ne pas bien marcher

Un conseil de bon sens : toujours prévenir le visiteur quand on ouvre une nouvelle fenêtre. Je fais partie des utilisateurs dont parle Monique, qui ont l'habitude de gérer leurs onglets et qui ne supportent pas qu'on leur force la main. Mais si on me prévient avant, je suis plus conciliant

Si tu as un accès SSH à ton hébergement, que tu as la bonne habitude d'utiliser un système de contrôle de sources (CVS ou Subversion), et que tu n'as rien contre ruby, tu peux jeter un oeil à Capistrano. C'est prévu pour Ruby on Rails à la base, mais rien n'empêche de s'en servir avec un autre type d'application. Ça permet d'automatiser le déploiement, de revenir en arrière quand on a fait une boulette, le tout en une seule commande.

Il y a toujours la possibilité de la négociation de contenu : regarder les en-têtes HTTP pour connaître la langue préférée envoyée par le navigateur et rediriger en conséquence. fr-FR -> france, fr-BE -> belgique, etc. Si l'entête n'est pas envoyé, ou ne correpond à aucune des options, envoyer la page qui permet le choix.

Google n'invente rien, si ces adresses sont indexées, c'est qu'ils les a trouvées dans un lien. Si tu désactives les cookies dans ton navigateur, tu devrais voir apparaître le PHPSESSIONID. Je suppose qu'en changeant d'autres paramètres, et en parcourant un peu le site pas forcément par le menu principal, on doit pouvoir retrouver les autres paramètres amusants qui sont rajoutés (comme le flash=non en désactivant flash). C'est le script de ton site qui est en cause, et il va falloir le modifier (il est possible que ce soit de grosses modifs) si tu veux vraiment faire disparaître ces url. En théorie, une session ne devrait jamais être initiée par un lien (methode HTTP GET), mais uniquement après un POST (de formulaire). Comme les robots ne suivent pas les POST le PHPSESSIONID n'apparaît pas, si cette règle était respectée.

Oui

Bénon puisque l'autre renverra une erreur 404, donc devrait se faire virer de l'index. Et d'ailleurs, si le titre change, il y a fort à parier que le contenu aura suffisamment changé lui aussi pour éviter le duplicate content.

L'idée est d'interdire les referrers qui n'appartiennent pas au domaine. Yapluka chercher dans la doc d'Apache comment on fait Attention toutefois, certaines configurations utilisateurs trop "sécurisées" n'envoient pas le referrer, (merci Norton Internet Security et consorts), ce qui fait que les gens avec ce genre de configuration ne verront pas tes images.

Ah heuuuu.... houlà. Pour stocker et faire fonctionner le site ou juste pour la saisie ? Si c'est pour stocker, oublier Excel. (Les mauvaises langues rajouteront File Maker Pro et Access également.) Ensuite, le serveur du site tourne utilise quel système d'exploitation ? Si c'est un serveur Linux, difficultés en perspective pour lire ces fichiers. Ces trois logiciels sont adaptés à une utilisation bureautique, pas à une utilisation en tant que système de base de données pour le Web, même si Access est parfois utilisé comme tel. En général on utilise MySQL, ou SQLite (pour les petites bases) sur des serveurs Linux, et SQLServer sur des serveurs Windows. Si la liste des contacts est le seul contenu en base de données et que le serveur est un serveur windows, Access peut faire l'affaire.

JE crois que le contrôle parental est activé par défaut, mais il faudrait vérifier, je n'ai pas AOL. Mais en fait à la relecture, si ça te sert le 404 personnalisé, ça ne doit pas être un problème de contrôle parental, ni de timeout. Il y a quelque chose de pas net ailleurs, probablement dans la requête du navigateur AOL. Sinon la page d'accueil est en XHTML Frameset, alors qu'elle devrait être en transitional, si j'en crois le code. Normalement c'est juste pour les Frames (pas les iframes, les frames), body est interdit dans un document XHTML Frameset. . On pourrait imaginer, même si je vois mal pourquoi que le navigateur AOL essaie d'afficher des Frames en allant piocher une adresse je ne sais où d'où le 404. Mais c'est chercher loin ?? La première chose que je ferais c'est de regarder dans le logs du serveurs les requêtes passées via AOL, et regarder l'url qui est demandée.

Quelques pistes : - L'encodage des caractères. Est-ce que le nav d'AOL ferait pas des trucs bizarres ? - Le site est lent (oui, déslé, une dizaine de secondes pour s'afficher ici), voir si y'a pas un délai max dans le navigateur AOL avant que ça ne décroche - Chercher du côté de mots qui ne passeraient pas le contrôle parental ?

M'est avis qu'on te complique la tâche, juste pour le plaisir de causer. Ce qu'on veut dire avec la sensibilité à la casse c'est que : http://www.tonsite.com/toto.html et http://www.tonsite.com/TOTO.HTML sur un serveur Windows, c'est la même page, alors que sur un serveur Linux ce sont deux pages différentes. Il faut juste faire gaffe quand on fait des liens. Et administrateur du serveur, ça signifie que tu gères la machine sur laquelle tourne ton site (installation des logiciels, mise à jour, etc). Ce qui je pense, n'est pas ton cas, c'est 1&1 qui s'en occupe.

Les moteurs de blog, par exemple, qui stockent leurs url sous la forme /annee/mois/jour/titre ou titre tout court, en laissant l'utilisateur corriger en cas de doublon. Et rien n'empêche de garder l'ancien titre comme id. Cool URLs don't change

Admin du site ou du serveur ? Ce n'est pas la même chose Pour du PHP/MySQL, je confirme, un hébergement LAMP (Linux Apache MySQL PHP) est le plus indiqué. Sauf dans l'offre 1&1, ça n'est pas proposé.

Nope. Google fait la sélection à l'aide des entêtes HTTP envoyés par le navigateur, qui indiquent que la langue préférée est le français. Par exemple mon firefox envoie : Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3 Ensuite c'est éventuellement sauvegardé dans un cookie, mais lors de la première visite c'est bien ce qui se passe.

<li id="pave">>> You Wot ?: the history of the English language</li> This code is not valid HTML 4.01 transitional. Commence par remplacer les > dans le texte par ">", ça pourra t'éviter de mauvaises surprises par la suite. Ensuite, ce que tu récupères par getElementById() n'est pas une chaîne de caractères, mais un objet de type HTMLElement (dans le cas d'un LI, c'est même un objet HTMLLIElement). On ne peut donc pas compter le nombre de caractères qu'il contient, puisqu'il n'en contient pas. Il t'appartient de récupérer son contenu sous forme de chaîne de caractères, mais pas avec value comme le suggère webor, car si j'en crois la documentation du DOM pour l'élément LI, l'attribut value n'a rien à voir avec le contenu textuel de cet élément (c'est une histoire de numérotation des éléments de liste). Le plus simple serait d'utiliser "innerText", mais ça ne marche qu'avec Internet Explorer. Donc il te faut récupérer la valeur du noeud texte, premier enfant de ton élément LI : function compte() { var pave=document.getElementById("pave"); document.write(pave.firstChild.nodeValue.length); } Ça devrait mieux marcher comme ça. Attention cependant, si tu as d'autres éléments HTML dans le contenu de ton LI, s'il est balisé quoi, ça ne marchera pas. Mais la solution dans ce cas est un poil plus compliquée.

Nous sommes réalistes. Il n'existe pas de bonnes raison pour quelqu'un qui n'y connaît rien de prendre une solution Windows plutôt que Linux. C'est transparent tant qu'on n'utilise que le transfert FTP. Par ailleurs, PHP est plus souvent préinstallé sur des hébergements mutualisés Linux que Windows. Ensuite, il y a la gestion du serveur Web proprement dit. Sans avoir la main sur le serveur complet, (ce qui ne semble pas être la demande de Krys, si je ne m'abuse), Apache est beaucoup plus configurable (.htaccess) au niveau répertoire que IIS. C'est bien de cela qu'il s'agit. Si tu lis correctement nos réponses, tu verras que pour l'utilisation qui est demandée, à savoir un hébergemetn bête et méchant pour quelqu'un qui ne sait pas comment ça marche, on prend l'offre standard qui est l'hébergement LAMP. Ça ne te viendrait pas à l'idée de proposer Linux à un débutant en informatique ? Ça ne nous vient pas à l'idée de proposer Windows à un débutant en matière d'hébergement Web. Il n'est pas ici question d'administrer un serveur, mais d'héberger un site. Non ça n'a rien à voir. La plupart des gens qui utilisent un hébergement Linux travaillent sous Windows. C'est justement la magie d'internet que de faire communiquer des machines différentes.

Rien n'empêche cet id d'être une chaîne de caractères...

Dans ce cas, il y a très peu de chances que tu voies une différence, quel que soit ton choix. Je dirais donc Linux, vu que c'est la configuration la plus courante et pour laquelle tu trouveras plus facilement de l'aide. <troll> Vivivivi. N'empêche que IIS est une catastrophe quand même... </troll>

C'est moi ou il y a beaucoup plus de femmes que d'hommes qui ont répondu ? C'est marrant, ça.

Il y a aussi toutes les saloperies de protections du genre norton internet security et compagnie qui ont tendance à bloquer toutes sortes de choses (cookies, referrer, appel à un domaine différent du site en cours, voire même requêtes POST, etc.). Je me suis laissé dire qu'Analytics ne prenait pas en compte les données incomplètes (pas de referrer par exemple). Et Analytics, contrairement à Xiti, n'a pas d'alternative à JavaScript. Sans compter qu'il doit également ajaxifier pas mal et que ça n'est pas supporté par tous les browsers, même avec javascript.

Ben non. S'ils existent tous les deux, c'est bêtement parce qu'il ne servent pas à la même chose. POST sert à envoyer des informations. GET sert à demander une ressource. Dans le cadre d'un formulaire de recherche, par exemple, GET est indiqué : tu vas demander le document résultant de la requête. Comme la requête passse dans l'url, il est possible de la bookmarker. A contrario, dans le cadre d'un formulaire de contact, POST est plus adapté. On ne demande rien, on envoie des infos et en retour on reçoit une confirmation qui n'a pas vocation (ni d'intérêt) à être bookmarké. De plus, la plupart des navigateurs intègrent une sécurité qui fait qu'on ne peut pas renvoyer deux fois les mêmes informations par POST sans confirmation.

Bonjour, Pour approfondir un peu ce qu'est le design et aller au delà de faire un "beau" site, je te conseille de lire (si tu comprends l'anglais) quelques articles sur Design View. Tu ne trouvera pas comment faire tel ou tel effet, mais pourquoi le faire, dans quel contexte, etc. Chaque élément d'un design bien fait a une fonction particulière, et n'est pas seulement là pour faire joli. Les sites que tu lies en exemple reflètent assez bien ce que j'essaie de dire.