captain_torche

Je connaissais déjà ces articles, mais je pars sur ce site du principe que des utilisateurs peuvent vouloir modifier l'url de leur page (mauvaise orthographe, par exemple). Je ne compte pas les inciter à le faire, mais seulement leur en donner la possibilité (et faire en sorte que ce soit le plus propre possible).

C'est tout simplement parce que le contenu principal n'étant que des images, il n'y a pas d'alternative textuelle à laquelle se référer. Ceci dit, légalement, tu ne peux pas encaisser de revenus publicitaires en tant que particulier (tu trouveras plus d'infos dans le forum administration et droit).

Merci pour l'article, il est très intéressant. Bon, je pense que je vais conserver mon idée première : les urls utilisées pour les articles "supprimés" ne seront plus disponibles.

L'image est une image de fond, définie en CSS : background:#FFFFFF url(img/q.png) no-repeat scroll 4px center; padding-left:18px;

Le problème ne se pose pas, si la redirection utilisée est une redirection 301.

J'ai édité ton message pour ne plus mentionner les noms propres. J'ai également changé le mot "poêle" en "casserole" pour éviter à ce topic de paraître en bonne place sur la requête en question. Dans l'absolu, le courrier ne me semble pas justifié, d'autant plus qu'on parle d'une association probable de noms communs, et pas non plus d'une marque notoirement connue. Malgré tout, la meilleure chose à faire reste de modifier la légende de l'image incriminée, ça évitera potentiellement beaucoup de démarches. C'est ce qu'on appelle une "poêle génante"

Je suis en train de créer un site perso, qui poura éventuellement devenir plus communautaire par la suite. J'essaye de tout prévoir en amont, histoire de ne pas tout développer deux fois. Dans le principe, j'attribue à chaque page une url personnalisable, unique (dans le but de pouvoir appeler via urlrewriting, une page du type "nom-de-la-page.html"). Lorsqu'une url est modifiée, je conserve les anciennes versions, pour pouvoir rediriger par 301 vers la dernière url en date. Par contre, lorsqu'une page est supprimée, dois-je considérer l'url comme caduque, et aboutir à une erreur 404, ou puis-je la rendre de nouveau disponible pour un éventuel nouvel article ? N'hésitez-pas à me demander des détails si je ne suis pas suffisamment clair.

Il me semble que Dan l'avait déjà fait, et l'avait retiré pour ces raisons (et aussi parce que ça ne lui apportait pas de clic supplémentaire). Edit : je viens de retrouver le topic où il en parle.

Ca a été le cas jusqu'il y a quelques temps avec le Google bombing : des sites étaient premier sur une requête sans aucun rapport avec leur contenu (même si là, la quantité de liens prévalait sur leur qualité). Depuis, Google a mis en place des filtres pour éviter cela.

Bienvenue à toi ! Je suis certain que beaucoup seront ravis de connaitre tes conseils

Il semble que ce ne soit pas ton serveur lui-même qui ait un problème, mais qu'il s'agisse plutôt d'un problème d'accès à ton serveur. Je viens d'effectuer un traceroute vers ton site, il semble qu'il y ait des blocages. Détermination de l'itinéraire vers doublecanon.be [213.251.135.71] avec un maximum de 30 sauts : 1 1 ms 1 ms 1 ms 192.168.0.254 2 53 ms 61 ms 55 ms 82.245.xxx.xxx 3 63 ms 64 ms 72 ms 213.228.23.254 4 * * * Délai d'attente de la demande dépassé. 5 * * * Délai d'attente de la demande dépassé. 6 234 ms 125 ms 54 ms 10giga.p19-2-6k.routers.ovh.net [213.186.32.134] 7 98 ms 40 ms 67 ms p19-11-m1.routers.ovh.net [213.251.130.166] 8 127 ms 56 ms 119 ms sd32099.performant-hosting.com [213.251.135.71]

Non, ça rentre parfaitement en compte dans leur démarche : Un site ayant un bon PR (donc une notoriété certaine), est censé avoir du contenu de qualité (et des liens sortants de la même valeur). Il est logique que le poids accordé à ces liens soit plus important que celui émis depuis une page perso quelconque.

Encore heureux ! Parce que dans le principe, ce n'est pas parce qu'un site est codé avec les pieds, que son contenu n'est pas intéressant (et inversement).

Tout simplement parce que tu accordes plus de poids au terme "bretagne" qui de plus, correspond au contenu de ta page. Pour faire plus simple, avec la solution "Bretagne - France - Europe - Nom Annuaire", le moteur associera tous ces mots-clés à ton contenu, mais avec un poids moindre que s'il n'y avait que le mot "Bretagne", car les mots ne sont pas réellement liés entre eux. En ne mettant que le nom "Bretagne", tu permets d'associer le nom de ta page, avec son contenu. Tu augmentes donc tes chances qu'un internaute, après avoir tapé la requête "Bretagne", atterrisse sur ta page.

Tout dépend de quels meta tags tu parles. S'il s'agit de keywords, l'ordre n'a aucune importance (et la balise en elle-même n'en a quasiment plus). S'il s'agit du titre, la seconde solution est la meilleure des deux. Mais il serait encore meilleur de n'y mettre que le nom de la page (ie : "Bretagne"), pour y gagner en pertinence.

Tu peux éventuellement essayer de positionner les deux premières colonnes en relatif, par rapport à leur contenant. Je ne garantis pas le résultat, ne l'ayant pas testé

Si le seul affichage que tu as es Cannot modify header information - headers already sent ..., vérifie bien que ton code ne retourne strictement AUCUN caractère avant l'appel à la fonction header. Si ce n'est pas déjà fait, place-le en début de fichier. Si c'est déjà fait, vérifie que tu n'as pas une ligne vide (ou même un espace) avant.

En principe, un site seul (c'est-à-dire sans AUCUN lien qui ne mène à lui), ne peut pas être référencé : les robots suivent les liens des sites qu'ils connaissent déjà, pour découvrir de nouveaux sites. Le problème, c'est que tu ne peux pas empêcher telle ou telle personne d'effectuer un lien vers ton site, et donc aux robots d'accéder à ton site. Dans tes pages, tu peux toutefois ajouter une ligne, qui interdira aux robots de l'indexer : <meta name="robots" content="noindex, nofollow"> Tu peux également mettre à la racine de ton site, un fichier nommé robots.txt, contenant ceci : User-agent: * Disallow: / La première ligne signifiant que ce qui suit est adressé à tous les robots (caractère joker *). La seconde interdisant l'indexation du site depuis sa racine (/). Toutefois, ça ne reste pas une sécurité suffisante pour empêcher d'éventuels indésirables d'avoir accès au contenu de ton site. Donc, de deux choses l'une : ou ton contenu n'est pas privé, dans quel cas les informations précédentes devraient être suffisante (mais potentiellement n'importe qui aura accès à l'information), ou alors ton contenu est "top secret", et il va falloir que tu te renseignes sur les différentes méthodes de limitation d'accès. Tu trouveras dans la FAQ d'Orange ce dont tu as besoin (Lien "comment filtrer l'accès à mon site) : ils proposent apparement un service de génération de fichiers .htaccess.

Tout ton problème semble venir de la première ligne de code. Le message que tu obtiens : ini_set() has been disabled for security reason est explicite : apparemment, ton hébergeur empêche d'utiliser la fonction ini_set, pour des raisons de sécurité (tu peux en savoir un peu plus sur cette page, rubrique "Protection des ressources"). Le reste des erreurs affichées sont dûes au fait que tu as un premier message d'erreur, qui empêche la redirection (la fonction header doit être appelée avant que tout caractère ne soit envoyé au navigateur, d'où les erreurs suivantes). En supprimant le début de ton code (càd la ligne contenant le ini_set()), tout devrait rentrer dans l'ordre. PS : j'ai édité ton message, pour utiliser la balise CODEBOX, qui permet de coller des codes assez longs, sans toutefois défigurer la page.

Tu peux poster ton code depuis la définition de l'array, jusqu'à l'appel de la fonction array_shift ?

C'est parce que tu utilises indifféremment le nom de dossier "Images" avec et sans majuscule. Sous Windows, ça ne pose aucun problème (il ne fait pas de différence), mais sous un système Unix comme ton serveur distant, le chemin "images/icon2.jpg" n'existe pas, alors que "Images/icon2.jpg" existe. Il te suffit d'ajouter la majuscule dans ton fichier CSS.

Super, ça marche nickel ! C'était tout bête Merci beaucoup !

Pour des raisons de confort (quand il fait beau, j'aime bien coder sur le balcon), j'aimerais pouvoir accéder au serveur du PC fixe depuis mon portable. Mais malheureusement, bien que tout me semble ouvert, je n'y arrive pas. Ma config : - 1er PC branché en direct sur la freebox, @IP 192.168.0.1 (bail permanent) - portable connecté en Wi-fi, @IP 192.168.0.2 (bail permanent) - Les PC communiquent correctement entre eux (ping OK, partages de fichiers, etc) - J'ai ouvert à tout hasard le port 80 sur la Freebox, redirigé vers le PC fixe - J'utilise EasyPHP 1.8 comme serveur Malheureusement, lorsque je tente de mettre l'adresse IP du serveur dans le navigateur du portable (http://192.168.0.1), cela ne marche pas (et je viens de me rendre compte que tenter d'afficher cette même adresse sur l'ordi fixe (donc possédant cette adresse IP), ne fonctionnait pas non plus). Que faire ?

A mon avis, tout dépend du site en question. A partir du moment où le contenu est amené à évoluer plus ou moins régulièrement, un back office complet est nécessaire (que ce soit un CMS ou un BO propriétaire). J'imagine également que, pour tes clients, le prix n'est pas le même dans les deux cas; ils doivent choisir l'une ou l'autre des solutions en toute connaissance de cause.

Après "$farray = file('news.xml');", fais un "var_dump($array)", pour voir ...