captain_torche

Pour un truc comme ça, j'utiliserai un tableau multidimensionnel : $tab_couleurs = array( 0 => array('couleur col0', 'couleur col1'), 1 => array('couleur col0', 'couleur col1') ); Avec en première donnée, le numéro de la ligne, et en seconde, celui de la colonne. Ce qui te donnerait, après un p'tit print_r : Array ( [0] => Array ( [0] => #FFF [1] => #000 ) [1] => Array ( [0] => #000 [1] => #FFF ) )

Si tu n'autorises qu'une seule image par user, je te conseillerais plutôt un seul dossier, dans lequel tu stockerais toutes les images, en les renommant pour correspondre à l'id de l'utilisateur.

Tu pourrais être plus précis ? Tu cherches à attribuer les couleurs en fonction de quoi ?

Tout simplement parce qu'en dix ans, y'a eu pas mal de pages qui le conseillaient, et qui ne sont plus à jour . Sinon, pour le problème de base, je partirai plutôt du postulat suivant : - On ne fait pas de page intermédiaire à l'accueil. C'est mauvais pour le référencement, et pour le visiteur, qui a à se cogner une attente supplémentaire avant d'accéder au contenu. Et encore, je parle pas des pages de 'présentation' en flash, avec redirection automatique à la fin de l'animation, et impossibilité de zapper le truc. (Généralement, je reste sur ces sites juste le temps de fermer l'onglet). - Pour ce qui est du site multilangue, il existe effectivement la solution d'objectifweb (à savoir; détecter la langue du navigateur pour rediriger automatiquement vers le site adéquat (ou vers la langue par défaut)), mais on peut faire plus simple : pourquoi en effet, ne pas arriver par défaut sur la page la plus probable (la langue de la majorité de tes visiteurs), et mettre dans cette page (ainsi que dans toutes les autres pages du site), des liens bien visibles pour changer de langue ? - Pour finir, en ce qui concerne le redimesionnement de fenêtre, oublie ça tout de suite. Au même titre que les keywords, ça n'a plus lieu d'être (et plus personne ne s'émerveille de voir sa fenêtre changer de taille), et ça devient techniquement impossible à gérer : quasiment tous les navigateurs gèrent la navigation par onglets (Opera, Firefox, Safari ?, IE7 ...), et il est impossible de les redimensionner individuellement (bien heureusement !). Il faudra donc trouver une autre solution, comme le centrage de ton image (si tu persistes bien sûr à vouloir garder une grosse image en page d'accueil).

Et même s'il le rattrapait dans sa prochaine version (ce qui ne semble pas encore gagné), il faudrait encore prévoir les 'vieux' IE6 pendant quelques années.

Essaye en CSS, avec : form { padding: 0; margin: 0; } [Mode Gros Bourrin]Y'a de ça quelques années, quand la sémantique et le respect des normes établies n'avait aucun sens pour moi (et pas plus pour mes collègues), qu'on n'utilisait le CSS que pour du span class="titrevert" tout en trouvant ça génial, et qu'on faisait en tabulaire parce qu'on savait pas faire autrement, on utilisait l'astuce suivante : <table> <form> <tr> <td> ... </td> </tr> </form> </table>

Dans Dreamweaver, tu peux afficher le code source de la page. Ca doit être une icône en haut à gauche du logiciel (si mes souvenirs sont exacts). Le PHP est modifiable dans ce code source.

Tous les navigateurs comprennent la première syntaxe. C'est la seconde (html>body #default) qu'IE ne comprend pas. Il garde donc la première définition, alors que les autres navigateurs, la comprenant, modifient la valeur. On peut aussi passer par : height: 18px !important; height: 20px; le !important spécifiant aux navigateurs conformes aux normes, que la valeur ne doit pas être modifiée par la suite. IE ne comprenant pas cet attribut, voyant une nouvelle valeur, modifie l'ancienne.

C'est effectivement avec $_SERVER['PHP_AUTH_USER'] et $_SERVER['PHP_AUTH_PW'] que tu récupères ces infos. Je crois bien que certaines versions de PHPMyAdmin (sur des serveurs mutualisés) l'utilisent pour la connexion à la base en fonction des infos perso demandées en .htaccess

D'ailleurs, côté performances, vaut-il mieux ouvrir/fermer la base à chaque requête, ou bien l'ouvrir en début de script, et la fermer à la fin ?

C'est très sympa, mais je te conseillerais de mettre une image de fond derrière ton menu, histoire de voir véritablement le menu en action ...

Tu peux exposer tout de même ton problème ainsi que sa solution, ça permettra à d'autres personnes dans le même cas, de tomber sur ta solution en effectuant une recherche.

Ben, l'interdiction de crawl devrait suffire à ne pas avoir de duplicate content, si on le met sur le site info, non ?

Je me rappelle qu'à l'époque où je bossais en web-agency, il y avait une 'clause de communication' dans les contrats.

C'est tout le mal que je t'espère

J'imagine que tant que le projet est public, ça ne pose pas de problème (sous réserve de mon absence totale de conniassances juridiques). Mais il serait sans doute judicieux, à l'avenir, de spécifier une clause dans votre contrat, vous autorisant à communiquer sur vos réalisations.

Ce genre de 'protection', va seulement encrypter le source. Ca n'empêchera en rien un utilisateur de faire un copier-coller du contenu. Et sinon, entre une hypothétique perte de revenus à cause d'une copie du source, et perdre tout le marché potentiel des moteurs de recherche, le choix est vite fait ...

Il marche très bien sans /index.html, pour moi. Sinon, pas mal de remarques côté ergonomie, mais il vaudra mieux mettre ça dans un autre topic.

Le souci, c'est que db_name(), ne semble pas être valide pour mySQL. Ce que tu pourrais éventuellement faire, c'est lister les bases disponibles avec mysql_list_dbs. Mais, je ne comprends pas véritablement ce que tu veux faire. Si c'est retourner la base courante (sur laquelle est connecté ton script), il suffit de le voir dans les fichiers de conf, non ?

Ben, si jamais l'affaire va plus loin, je ne crois pas que la mention fictive soit une bonne idée.

Effectivement, c'est assez flou. D'une part, on a le contrat de licence qui autorise n'importe qui à utiliser le texte tel quel, ou à le modifier, tant qu'il en précise 'auteur original. D'autre part, la législation autorise un auteur à effectuer son 'droit de retrait', c'est-à dire, supprimer son oeuvre. Par contre, à ce que j'ai vu pour l'instant (sources wikipedia, educnet.education.fr), l'auteur ne peut exercer ce droit de retrait, que s'il indemnise les autres parties du contrat pour le préjudice subi.

Woops, pardon

Pourquoi perdant ? Il va perdre son PR ? Non. Le site avec le PR moindre aura plus de répercussions positives, c'est sûr. Mais le site à haut PR n'aura pas de répercussion négative non plus. L'échange est gagnant-gagnant, dans ce cas-là.

Personnellement, oui, j'échangerais un PR6 contre un PR1 (même), si le site est de qualité. On va dire, pour simplifier, que le PR est un instantané de popularité d'un site (dont les critères sont encore flous). Ce n'est pas parce qu'un site est populaire, qu'il est de qualité (et réciproquement).

Personnellement (et ça n'engage que moi), je trouve ces types d'échange assez puérils. Selon moi, le but d'un échange de lien, n'est pas de gagner en PR, mais de gagner en pertinence. Si les sites liés sont de même thématique et qualité, l'échange sera bénéfique à tous les deux.