captain_torche

Vous faites bien entendu ce que vous désirez sur votre site ... Et de son côté, Google fait ce qu'il veut dans son index. Votre site est toujours positionné parce que la "fraude" n'était pas énorme dans votre cas, mais c'était toutefois risqué. Pour savoir si la méthode fonctionne, il faudrait d'abord constater que ce code a eu un effet. Je pense que Google n'a pas eu l'occasion de constater qu'il était caché (Sinon, pourquoi ne pas mettre un "simple" display: none ?) Quant à votre dernière information : si le contenu est intéressant, il faut l'afficher sur votre site. S'il n'est pas affiché, c'est fatalement qu'il est soit redondant avec ce qui est déjà présent sur la page, soit que la structure de votre page laisse à désirer (Contenus non-indexables, par exemple).

Personnellement (Et je pense ne pas être le seul), je pense que seul le fait d'avoir du texte caché destiné à être affiché (Suite à une manipulation JavaScript, par exemple) n'est pas préjudiciable. Si le but est de bourrer la page de mots-clés et de contenus (Même s'ils sont en rapport avec la thématique de la page), c'est effectivement préjudiciable. D'ailleurs, si vous aviez réellement confiance dans votre méthode, pourquoi ne plus l'employer désormais ?

C'est bon, j'ai réussi à trouver ce qui posait un souci : - Lors d'un envoi mixte avec des pièces jointes, il y a deux "boundaries" : une première dans les en-têtes, qui va séparer le message de chaque pièce jointe, la seconde est déclarée dans le corps du message et sépare la version texte de la version HTML - Ces deux versions (texte et HTML) doivent être entourées d'une ligne vide - Chaque pièce jointe doit être séparée de sa déclaration par une ligne vide également. Pour ceux qui seraient intéressés, voici le code de la fonction : envoi_mail.php Je serai ravi d'avoir vos retours.

S'il y a une erreur, c'est que tu tentes de redéfinir une variable qui a déjà été définie. Donc de deux choses l'une : soit une partie de ton script est améliorable, soit tu appelles plusieurs fois ce fichier de configuration. Dans la seconde optique, une solution serait d'appeler les fichiers avec require_once (ou include_once) au lieu de require/include.

Tant que tu suis cette logique, tu ne devrais pas avoir d'erreur. Peux-tu poster le reste du code (Celui qui exécute la connexion au site de test ou de prod) ?

[Edit]Le code fonctionnel est téléchargeable dans le second message de la discussion Je suis en train de développer une fonction d'envoi d'e-mails qui gère les pièces jointes. Mes tests sur gmail et hotmail sont concluants, mais sur Outlook 2010, je ne reçois pas de pièce jointe. Pourriez-vous tester la fonction et m'aider à trouver ce qui ne va pas ? function envoi_mail($nom_from, $mail_from, $to, $subject, $data = null, $template_html = null, $template_txt = null, $pj = array()) { /* 2011-06-22, Marc Brillault String $nom_from $nom_from est le nom de l'expéditeur String $mail_from $mail_from est l'adresse e-mail de l'expéditeur Mixed $to $to est une chaîne ou un tableau contenant les emails des destinataires Si $to est une chaîne, elle sera convertie en tableau String $subject $subjet est l'objet du mail Mixed $data Si $data est une chaîne de caractères, le mail sera envoyé avec ce contenu, en version texte ou HTML en fonction du contenu de $data. Les fichiers templates seront ignorés. Si $data est un tableau, il doit comprendre les codes de remplacement, sous la forme 'code' => 'valeur de remplacement', utilisés dans les fichiers de template. Les templates comprennent les codes rédigés de la manière suivante : '#CODE#' #CODE# sera donc remplacé par $data['code'] String $template_html $template_html est le chemin vers le fichier de template pour les envois en HTML Le fichier contient des chaînes du type #CODE#, qui seront remplacées par les valeurs correspondantes du tableau $data String $template_txt $template_txt est le chemin vers le fichier de template pour les envois en format texte brut Le fichier contient des chaînes du type #CODE#, qui seront remplacées par les valeurs correspondantes du tableau $data Array $pj $pj est un tableau contenant les informations des pièces jointes, sous la forme suivante : array( 'name' => 'nom_du_fichier', 'path' => 'chemin/vers/le/fichier' ) */ $boundary = '_'.md5(uniqid(rand())); // Protections contre les injections dans les en-têtes $nom_from = protege_mail($nom_from); $mail_from = protege_mail($mail_from); $to = protege_mail($to); $subject = protege_mail($subject); // CRÉATION DES EN-TÊTES $headers = "From: $nom_from <$mail_from>\r\n"; $headers .= "MIME-Version: 1.0\r\n"; $headers .= "Content-Type: multipart/alternative; boundary=\"$boundary\"\r\n"; // CRÉATION DU BODY // $body = "--$boundary\nContent-Type: text/plain; charset=UTF-8\r\n\n"; $body = "This is a multi-part message in MIME format.\r\n"; $body .= "Ceci est un message est au format MIME.\r\n"; // CRÉATION DE LA VERSION TEXTE DU MAIL $texte = null; if(is_string($data) && strlen($data) == strlen(strip_tags($data))) $texte = $data; elseif(is_array($data) && is_file($template_txt)) { $texte = file_get_contents($template_txt); foreach($data as $key => $value) $texte = str_replace('#'.strtoupper($key).'#', $value, $texte); } if($texte) { $body .= "--$boundary\n"; $body .= "Content-Type: text/plain; charset=\"UTF-8\"\r\n"; $body .= "Content-Transfer-Encoding: 8bit\r\n"; $body .= $texte; $body .= "\r\n"; } // CRÉATION DE LA VERSION HTML DU MAIL $html = null; if(is_string($data) && strlen($data) != strlen(strip_tags($data))) $html = $data; elseif(is_array($data) && is_file($template_html)) { $html = file_get_contents($template_html); foreach($data as $key => $value) $html = str_replace('#'.strtoupper($key).'#', $value, $html); } if($html) { $body .= "--$boundary\n"; $body .= "Content-Type: text/html; charset=\"UTF-8\"\r\n"; $body .= "Content-Transfer-Encoding: 8bit\r\n"; $body .= $html; $body .= "\r\n"; } // GESTION DES PIÈCES JOINTES foreach($pj as $file) { if(is_file($file['path'])) { $body .= "--$boundary\r\n"; $body .= "Content-Type: application; name=\"".$file['name']."\"\r\n"; $body .= "Content-Transfer-Encoding: base64\r\n"; $body .= "Content-Disposition: attachment; filename=\"".$file['name']."\"\r\n"; $body .= chunk_split(base64_encode(file_get_contents($file['path']))); } } $body .= "--$boundary--"; if(!is_array($to)) $to = array($to); foreach($to as $dest) mail($dest, $subject, $body, $headers); } function protege_mail($string) { // http://phpsense.com/php/php-mail.html $injections = array( '/(\n+)/i', '/(\r+)/i', '/(\t+)/i', '/(%0A+)/i', '/(%0D+)/i', '/(%08+)/i', '/(%09+)/i' ); return preg_replace($injections,'',$string); }

Je ne vois pas l'intérêt de déclarer plusieurs fois ces constantes. Tu peux poster la partie du code où tu les redéfinis ?

Hé non, tu n'achètes qu'une licence d'utilisation dans un cadre personnel !

En ce qui concerne l'illustration musicale, tu peux aussi essayer de trouver des morceaux libres de droits comme sur Jamendo, les tarifs sont abordables : http://pro.jamendo.com/tarifs-musique-illustration?protracking=jamhpcutrates

Ajoute le flag QSA (Query String Append) à la fin de ton expression ([QSA, L]), ça devrait suffire.

Le fait d'avoir quelques contenus cachés pour dynamiser une page n'est pas préjudiciable en soi, mais dans ton cas, c'étaient les trois-quarts de ta page qui étaient masqués ! Le faire en Ajax serait effectivement mieux, mais tu te priverais de l'indexation de liens profonds (notamment pour le menu principal). Et ça ne corrigerait pas pour autant le défaut principal de ta homepage : il n'y a strictement AUCUNE information (Et c'est la galère pour s'y retrouver). Il y a un gros travail d'ergonomie à faire dessus (Et sur tes autres sites également, qui semblent être tout aussi désagréables à utiliser). Les liens en haut de page vers ta galaxie de sites tous semblables sont aussi à zapper. Personnellement, pour débuter : - Je ne conserverais que les liens de navigation principale - Je supprimerais TOUTES les animations, qui ne servent à rien d'autre que perturber l'oeil - J'ajouterai un texte explicatif dans cette page - Je supprimerai TOUS les autres éléments, complètement inutiles à une page d'accueil (En gardant le moteur de recherche). Après ça, une petite épuration du design serait la bienvenue. Et, également : sur les autres sites, basés sur le même template, c'est ENCORE PLUS DÉRANGEANT de voir les encarts d'autopromo à gauche et à droite vers le site de comptabilité : on ne sait plus où on est !

Oui, je m'en suis rendu compte après coup, en analysant mieux le code source (Juste au cas où, l'anti-clic droit est une PLAIE et ne sert strictement à rien). Cela dit, ces encarts jQuery gagneraient à être simplifiés : une simple liste avec un lien à chaque fois, et surtout le CSS dans un fichier séparé, et tu gagnerais énormément de poids sur la page. Idem bien entendu pour le menu #pg. D'ailleurs, à quoi servent ces animations ? Sans lien de navigation, il est impossible de revoir une séquence qui nous a plu. De plus, l'animation de manière générale est toujours perturbatrice. Dans ton cas, il vaudrait sans doute mieux ne mettre qu'une seule image à chaque fois de manière aléatoire. C'est typiquement un menu qui fait plaisir au webmaster, mais dont l'utilisateur n'a rien à fiche. Pareil pour ton menu #contenu : on charge une pléthore de sous-menus en JavaScript, masqués par défaut. Encore un paramètre probable de pénalisation. En résumé, je trouve ta page d'accueil excessivement bancale : il y a trop de menus, de sous-menus (de liens, quoi) et pas assez de contenu (Pas du tout de contenu, d'ailleurs). Je compte 140 liens dans la page, sans aucun contenu ! Si tu veux revenir dans l'index de Google, il va y avoir un sacré travail de refonte à faire ! Et quand je parle de refonte, je parle de l'organisation complète du site.

Pourquoi ne pas enlever TOUT l'attribut title ? A quoi te sert-il ? Sinon, il y a encore pas mal de contenus que je vois dans le source, mais pas dans la page (Notamment le contenu du div #fr). Ta page n'a pas énormément de contenu visible, mais ton code source est bourré de mots-clés, et de codes cachés : ne cherche pas plus loin pour la désindexation !

Personnellement, je vois énormément de contenu caché : ta zone brèves, dans la colonne de gauche gère sont multipages en javascript, et affiche des divs masqués par défaut : ça fait beaucoup de contenu masqué ! Par ailleurs, les attributs title sur les span de présentation de ces nouvelles, surchargés de mots-clés, sont aisément identifiables à une suroptimisation et potentiellement responsables d'une désindexation.

Leur captcha n'est pas assez robuste pour protéger contre quoi que ce soit : celui de megaupload joue déjà ce rôle, d'ailleurs.

En toute logique, ces sites ne devraient pas être illégaux : il ne font que temporiser des liens (En affichant leur pub au passage) vers des sites contenant des liens potentiellement illégaux. Par contre, je ne vois pas du tout comment ils peuvent affirmer qu'ils protègent contre la suppression des contenus : ils ne possèdent aucun contrôle sur MegaUpload et consorts. Pour finir, le fait qu'ils disent protéger la suppression de contenu, invite à croire qu'ils incitent à poster des liens illégaux (Vu qu'eux seulement sont susceptibles de se faire signaler), et que donc ils se font complices du téléchargement illégal. Ce n'est donc pas sur le concept du site qu'ils peuvent se faire attaquer, mais sur leur revendication à protéger des liens illégaux.

Pas de quoi, ravi d'avoir pu t'éclairer !

Si tu veux exécuter le contenu, mais ne pas l'afficher, tu peux utiliser la bufferisation de sortie, avec ob_start()

Il faudrait voir avec les commentaires, qui normalement sont ouverts aux anonymes. Il faudrait juste ajouter la fonctionnalité pour l'upload d'images.

Il faut surtout bien étudier le cahier des charges (Et en exiger un s'il n'y en a pas), et l'étudier en profondeur avant d'accepter. Pour info, sur quoi bloques-tu, précisément ? Je n'ai pas de statut de freelance, mais si ce n'est pas énorme, je veux bien te donner un coup de main via le forum.

Tu peux aussi trouver un sous-traitant qui te débloquera la situation complexe, pour peu que ce ne soit pas l'intégralité du développement qui soit mis en cause.

C'est surtout la limite à 13 caractères qui est dérangeante, parce qu'elle n'autorise pas vraiment la possibilité d'utiliser des solutions maison.

A ce que j'ai vu, c'est l'affichage qui est raccourci (textuellement). Le véritable lien derrière utilise forcément leur raccourcisseur t.co, même si le lien fourni est très court (au-delà de 13 caractères) Techniquement, comme les caractères http:// sont obligatoires et qu'ils prennent déjà sept caractères, il ne resterait que 6 caractères pour faire un lien, soit un lien vers un domaine de 3 lettres avec une extension à deux lettres, ou un domaine de deux lettres avec une extension à trois lettres. C'est court !

En fait, la seule différence est la sémantique : les balises <b> et <i> décrivent une présentation (respectivement gras et italique), alors que les balises <strong> et <em> précisent l'importance qu'on accorde au texte inclus. <strong> est souvent prise pour la "nouvelle version" de <b>, et <em> pour celle de <i> parce que les navigateurs les rendent à l'identique, mais il ne faut pas oublier que ce n'est que de la présentation. Si je veux avoir un <em> en gras je le peux, de même qu'un <b> en italiques maigres. A ce que j'en sais, il n'y a aucune différence pour les moteurs quant à leur utilisation. On en a beaucoup parlé au moment où l'XHTML est sorti, principalement parce que de nombreux webmasters l'ont accueilli comme le saint Graal alors qu'il n'apportait dans la majorité des cas rien de nouveau. Selon moi, l'utilisation de <strong> et <em> est justifiée uniquement quand tout le reste du code respecte une sémantique stricte.

Il est aussi de bon ton de préciser : "Vous recevez cette newsletter parce que vous vous êtes abonné à la mailing list du site X et avez accepté de recevoir nos offres partenaires". Ca aide à comprendre pourquoi on reçoit le mail. En plus du lien de désinscription, un lien pour désactiver les envois de mails partenaires peut être une bonne chose également.