captain_torche

La page "plan" ne peut pas te pénaliser pour duplicate content : elle ne fait que reprendre les intitulés de pages.

Si les robots n'indexent pas le flash, je doute que tu risques une quelconque pénalisation pour duplicate content.

Tu peux forcer le nom du fichier avec la fonction header : header('Content-Disposition: attachment; filename="nom_de_ton_fichier"');

Dans ce cas, il faudrait que tu attribues un style 'clear: left' à ton dernier paragraphe. [Edit : Grillé]

Surtout qu'une salle blanche, c'est assez galère à fabriquer dans sa salle de bains. Plus sérieusement, il ne suffit pas d'avoir le matériel adéquat pour fournir un service de qualité, il faut aussi avoir de bonnes infrastructures derrière. Il te faudrait donc une salle sécurisée, climatisée, et du personnel prêt à intervenir en cas de panne, 24h/24. Difficile de gérer ça chez soi.

Non, quand tu fais ça, tu définis un style qui s'appliquera à tous les ul situés dans un élément de classe '.maclass', ainsi qu'à TOUS les li de ta page.

Logiquement, une clé formatée en FAT32 devrait passer sur les deux systèmes sans souci.

Tu peux éventuellement ajouter un set_time_limit(xx) pour augmenter le temps maximum d'exécution de xx secondes (ou le rendre illimité au cas où tu mettrais 0).

Tu pourras trouver dans les publications du Hub - un mailer pour votre site web une méthode fonctionnant en PHP (donc, ne nécessitant pas de CGI, et utilisable sans souci sur un hébergement OVH).

Sauf qu'il est également conseillé de placer ce script dans un répertoire protégé par .htaccess Ceci dit, si le malveillant a accès à ton serveur, ça ne servira à rien, mais il n'y a dans ce cas aucune solution de sécurisation à ma connaissance.

C'était vrai ... à sa sortie, il y a deux ans. Depuis, il est quand même indispensable. Ton souci vient sûrement de là.

Le souci, c'est que les couleurs d'écran ne sont pas fixes : elles varient selon le matériel de l'utilisateur, et son réglage. Il n'y a pas de paramètre fixe, comme en impression papier.

Et tant qu'à faire, on évite d'utiliser le $_REQUEST, qui est potentiellement moins sécurisé qu'un $_GET ou un $_POST

Vu le prix d'un bon hébergeur mutualisé, et celui d'un nom de domaine, je doute que ce genre d'offre soit réellement intéressante.

La méthode (dans les derniers messages) est identique. La seule différence est que ma requête va chercher un enregistrement au hasard, alors que celle de Portekoi va en chercher un précis (quand on connait son Id).

Personnellement, je ne change pas les polices par défaut, pour voir les sites "en conditions réelles"

Justement, désactive le javascript dans ton navigateur, recharge la page, et admire ... [Edit : grillé ]

Une "règle de remplacement compliquée", c'est effectivement quelque chose qui implique l'utilisation des expressions régulières (regex en VO, expreg en français ) Dans le cadre du remplacement d'un caractère par un autre (ou d'une liste de caractères par une liste d'autres), donc d'une "règle de remplacement simple", il vaut mieux utiliser une fonction spécialisée dans ces remplacements simples (comme str_replace), moins gourmande en ressources.

Bourinho, ton code fonctionne, mais il n'est pas des plus performants. Dans ce cas, il vaut mieux utiliser la fonction str_replace, moins gourmande. Pour ce qui est des espaces, où que ce soit sur internet, effectivement, le navigateur interprétera une suite d'espaces comme un seul. La solution de bourinho permet de transformer chaque espace en espace insécable, mais elle a l'inconvénient de son avantage : le navigateur ne fera pas de retour à la ligne lorsqu'il n'aura plus de place pour afficher la suite de la phrase. On peut également envisager de mettre ton texte dans des balises <pre>, stylées en CSS pour ressembler à quelque chose de plus propre (mais sémantiquement, c'est pas ça). Je viens aussi de tester avec l'attribut CSS "white-space: pre;", mais ça ne semble pas fonctionner sous IE6. Pour finir: pourquoi as-tu besoin de respecter ces espaces ? Tu les utilises pour une mise en page ?

Mais sinon, j'approuve également le tahoma des deux mains. Bien sûr, prévois quand même des polices de substitution équivalentes au cas où. Par exemple, en CSS : font-family: Tahoma, Arial, Verdana, Sans-serif;

SELECT cat_name,cat_id AS selecteur FROM categories WHERE group_id = '3' ORDER BY cat_name ASC

Non, si tu as 1000 intros et 2 corps de texte, avec le format que je t'ai proposé, tu as ... 1002 lignes. Et comme les textes sont les seuls à être associés au type 'corps', il suffit de limiter ta recherche à ce type.

Avec le schéma que je t'ai donné, ils sont indépendants. Il te suffit de faire une requête du type SELECT Texte FROM Table WHERE Type = 'intro' ORDER BY RAND() , pour avoir une intro aléatoire.

Personnellement, je ferais une table avec un champ Id, un champ texte, et un champ type, qui contiendrait une des valeurs 'intro', 'corps', 'basdepage'.

Pour une raison toute simple : POST ne peut être envoyé que par le biais d'un formulaire. On ne peut également pas non plus enregistrer dans ses favoris, les paramètres passés en POST à une page. De manière générale, on agit comme ça : - données envoyées en POST dans le cadre d'un formulaire. - données envoyées en GET dans la plupart des autres cas (pseudo-frames, paramètres de pages, etc).