froidure_nicolas

Les voies de Google sont impénétrables...

Alors de ce point de vue, je ne peux qu'approuver ta décision. WYMEditor est pauvre en fonctionnalités, mais il est conforme aux standards. Et, généralement, pour avoir un code pratiquement conforme aux standards, les autres outils voient leurs fonctionnalités réduire comme peau de chagrin.

Dommage, ça retire tout intérêt pôur moi qui ait choisi de ne pas implémenter de moteur de recherche interne. Mais bon, ça reste intéressant pour certains d'entre nous. A ce sujet, rien à voir, mais existe-t-il un moyen "autorisé" d'afficher des annonces par rapport à certains mots clés ? Parce que, il arrive que les annonces soient complètement inadaptée (bien que répondant à certains mots présents dans la page, mais pas dans le même contexte). Je suis tout nouveau chez Adsense, je tâtonne encore. Bref, merci pour votre aide.

Qu'entends-tu par là ? Si tu as eu un problème avec le BBComposer, rends ta démarche utile, et voyons ensemble ce qui peut être amélioré.

Une application intéressante de ce concept, ça serait récupérer les mots clés que le visiteur a tapé dans le moteur pour trouver la page et afficher des Adsenses en rapport avec ces mots clés. C'est vrai que parfois, on a des recherches complètement inadaptées qui atterrissent sur nos sites. Ca serait un bon moyen de : améliorer la qualité du surf de nos visiteur en leur proposant un contenu, même quand le résultat de la recherche est tombé sur notre page de manière fortuite. monétiser un trafic de gens qui, lorsqu'ils se trouvent sur un résultat pas très pertinent, cliquent sur le bouton retour. Bref, très intéressant ce petit truc !

Dans mon ptit tutoriel sur la sécurité, j'ai répertorié un site qui va jusqu'au SHA-256 en terme de Hachage.

Sur ce point, j'ai envie de te répondre qu'un site Internet d'entreprise (puisque c'est la cible du BBComposer) est le reflet de la politique commerciale. Et, en tant que tel, cela ne se modifie pas sur un coin de table à la va vite, mais se réfléchi et surtout se mûri. C'est pas un skyblog... Maintenant, je suis conscient que BBComposer n'est pas la solution miracle et que l'utiliser peut présenter des inconvénients. Notamment la mobilité dont tu parles. Mais franchement, abandonner ses avantages pour une situation qui n'arrive que 3 fois dans l'année... je trouve ça bien dommage. Je pense surtout que les clients arrivent gavés de "Web 2.0" et ils veulent qu'on leur en fournisse à toutes les sauces. Mais ils oublient que le "Web 2.0", c'est une mode que seuls les grands portails peuvent s'offrir et ont intérêt à utiliser. Un site d'entreprise aujourd'hui, ça reste un site informatif assez statique en fin de compte. Et c'est surtout la qualité de son contenu qui influera sur le nombre de contacts, et pas les clignotements, les animations Flash ou autres.

Si il ne me fait pas confiance, il ne m'achètera pas ma solution. C'est peut-être un bon point pour moi ! De toute façon, si il veut que son projet réussisse, il a plutôt intérêt de se débrouiller seul. Ma cible, c'est les PME. Or, il ont pas de quoi me faire bosser H24 sur leur site, ils n'ont pas envie de claquer 200 euros d'Adsense tous les mois et veulent avoir du trafic. La condition pour réussir ce pari, c'est qu'il s'investissent. Et pour cela, je propose le BBComposer, sa doc. et mon numéro de portable. Un client qui ne sera pas capable de faire vivre son site seul, ne sera, de toute façon, pas une bonne publicité pour moi. Celui qui a peur de tester un clic-droit, sauf s'il se forme, n'a pas intérêt à modifier lui même son site. C'est soit, on place une secrétaire en CDI sur le projet, on lui offre une petite formation sur l'édition Web (comme on lui paierai une formation Word), soit on prend un site statique ou avec juste un module de news en texte simple et on fait faire les mises à jour par le webmestre quand c'est nécessaire. Quand on investit dans un site, on doit se donner les moyens aussi, de la faire vivre.

En réalité, tu n'es pas obligé d'imposer Firefox, il existe aussi des éditeurs XHTML utilisable avec IE (comme XStandards) ou même de façon indépendante. C'est ça le plus d'ailleurs, c'est le choix de l'éditeur. Mais bon, je n'exclue pas de faire un BBComposer pour Internet Explorer. seulement, c'est pas pour tout de suite.

Salut ! Je suis ce débat houleux avec attention, et j'aimerai juste dire quelques mots, notamment sur les éditeurs WYSIWYM dont, à ma connaissance, seuls BBComposer et WYMEditor peuvent se targuer d'en faire parti. Pour répondre à Spark, bien-sûr que les éditeurs WYSIWYG sont moins "user-friendly" que les autres éditeurs tels que FCKEditor. Mais la question qu'il faut se poser, ce n'est pas comment, mais pourquoi ! Avec FCKEditor, tu vas à la ligne en tapant entrée, avec le BBcomposer, tu dois faire Shift + Entrée ou cliquer sur le bouton à la ligne. Certes, on est pas habitué à cela, mais je ne changerai pas cela pour deux raisons : depuis sa création, forcément, j'utilise BBComposer. Je peux te dire qu'on s'y habitue extrêmement vite. Cela évite un des gros travers des éditeurs WYSIWYG, la maladie des "br partout". En effet, le web est spécial, un document HTML n'est "heureusement" pas un document Word. Il est normal que sa modification soit différente. Ainsi, dans un éditeur WYSIWYM, tu raisonnes sémantiquement. Ton texte n'est pas une suite de lignes les unes en dessous des autres. C'est un ensemble de blocs contenant des lignes de texte. Ces blocs ont chacun une valeur sémantique et le texte qu'ils contiennent ont eux aussi une valeur sémantique qui est déterminée par des éléments dits en ligne. Certes, utiliser le BBComposer nécessite de la bonne volonté et, assurément, un apprentissage. Mais comme je le dit, c'est le prix de la sémantique, de la conformité et d'un bon référencement, car, il ne faut pas se leurrer, Google préfère un contenu organisé et sans erreur. Bref, les mentalités changent lentement, mais ne vous accrochez pas à FCKEditor qui est une vision dépassée du WYSIWYG. Par exemple, les fonctions de sortie du BBComposer, celles qui font que je peux sortir du BBCode, du XBBCode, du Mediawiki, du Spip ou encore des codes Skyblog n'ont pu être crées que parce que j'ai la maîtrise du contenu produit par le BBComposer. Essayez de les adapter à FCKEditor, ça sera une autre paire de manche...

Soit, tu fais ce que tu veux Mais si ça peut t'éclairer, voilà un petit lien vers une vidéo pour découvrir les + de BBComposer. Par rapport à la démonstration chez le client, hier même, j'ai fais une démo sur le PC du client. BBComposer + Firefox installé en quelques minutes. Ca m'a donné le temps de discuter un peu sur les logiciels libres et leur avantage.

Je partage ton point de vue, mais le template est utile dans un cas, et pour que celui-là soit possible, il faut une bonne dissociation du code et du template. Par exemple, pour le site du BBComposer, la seule différence entre les actualités en HTML et les actualités en RSS ou ATOM, c'est le template. Tout le reste est identique. C'est là que se trouve l'utilité des templates.

Tout d'abord, ne désespère pas, c'est super passionnant et je pense qu'en persévérant, on y arrive. Pour en revenir à ta question, il s'agit d'un fichier de template (.tpl). Il y a plusieurs façons de voir : La façon Spipienne Avec Spip, le fichier de template est un vrai langage à lui seul. Tu peux faire des transformations sur les variables, créer des boucles complexes et même faire de la retouche d'images etc... L'inconvénient, c'est que du même coup, ça prend beaucoup de ressource et, pour quelqu'un qui comme toi connaît PHP, ça force à apprendre un nouveau langage alors que tu en connais déjà un. La façon intermédiaire Disons que certaines transformations seulement sont possibles, mais que cela reste tout même de petites tranformations. La façon drastique Celle que j'utilise dans XCMS. En fait, je pars du principe qu'une dissociation totale du code et du template doit être réalisée. Les variables sont définies par PHP et mises dans le template. Le template ne peut pas influer sur leur contenu. L'inconvénient, c'est qu'il faut mettre les mains dans le PHP pour modifier le contenu des variables (mais quand on connaît PHP...). L'avantage, c'est que c'est ultra-rapide, ultra-léger et très sommaire ce qui permet au graphiste de s'y retrouver facilement (encore que, si il respecte la dissociation de la forme et du fond, c'est juste quelques div et span à rajouter avec modération là où ce n'est pas possible de faire autrement). Pour ta gouverne, en général, un moteur de template, ça se fait en POO (c'est plus conceptuel). Principalement, on utilise des expressions régulières. Mais, un système caractère par caractère serait plus rapide. Je compte réécrire mon moteur dans ce sens sitôt que j'ai un peu de répit. Voilà, voilà

Après, c'est une question de vision des choses. L'éditeur WYSIWYG doit-il faire parti du site ou du navigateur ? Pour moi la deuxième option est la meileure en ce sens que : c'est déjà possible (j'ai cité BBComposer pour FF, mais pour IE, on trouve aussi XStandards, un peu moins pratique, mais plus complet). Ca facilite les mises à jour ainsi que la migration d'un éditeur à l'autre. C'est ce qu'on peut appeler, la liberté. Et puis, après, on peut tout imaginer, genre des templates types par types de contenu, je pense notamment à programme XUL (scenari) que j'ai vu y'a pas longtemps qui impose un certain format pour l'édition etc... etc...

Personnellement, j'ai une méthode moins prise de tête... J'ajoute un content-type:text/html Et je convertis tous les retours chariot du corps du message en br ( (\r?\n) => [br]). Edit : Cependant, il me semble que ce problème est résolu dans les dernières versions de PHP.

Salut, Je vais faire un peu de pub pour un logiciel libre qui s'appelle BBComposer Le principe est simple, de ton côté tu crées un <textarea> avec l'attribut id renseigné. De l'autre, tu installes l'extension BBComposer sur ton browser préféré, c'est à dire, Firefox. Non, ne dis rien, c'est ton navigateur préféré... Et tu peux éditer tes messages en XHTML 100% conforme avec les balises h1 à h6, mais aussi toutes les balises sémantiques (ul, ol, dl, em, strong, cite, q, blockquote, acronym, abbr, code, del, ins, etc... etc...). Tu peux, en plus, ajouter des CSS (tout CSS2 est supporté sauf le positionnement) et une collection complète de smiley et de clipart peut être utilisée pour illustrer tes tutoriels. L'upload d'images se fait par drag n' drop, simplement. Et, de plus, avec la nouvelle version 0.7 (qui sort dans quelques jours mais que tu peux télécharger avant tout le monde ici), tu as la possibilité d'enregistrer le contenu de l'éditeur pour le reprendre après. Voilà, je prêche pour ma paroisse, mais je pense, en toute modestie, que je peux en être fier. Je suis dispo. si tu as besoin d'aide. PS : Tu peux faire des dégradés de couleur, accessoirement et aussi, poster dans les forums, dans le CMS Spip et dans les wikis Wikimédia.

Pour le particulier, une et une seule référence : blogger.com. Tout est possible (adwords, par exemple Tu peux utiliser mon BBComposer avec pour une source 100% sémantique et conforme XHTML et quelques plus sympa !

As-tu essayé : Chemin > Objet en chemin ?

Je n'utilise pas ce système dans mon url rewriting à cause, justement, de cette limitation. La seule façon de faire ce que tu souhaites est un peu tordue en fait. Il s'agit : De récupérer "n-importe-quoi" dans n-importe-quoi-id5.html. Pour cela, tu devras sûrement modifier tes règles d'URL rewriting du genre : RewriteRule ^([a-z\-]+)id([0-9]+)\.html$ index.php?id=$2&mavar=$1 [L] Ensuite, tu recherche l'endroit dans ton script où se situe la requête de récupération de l'entrée avec id=5. Enfin, tu trouve la fonction qui génère le bout d'URL contenant une partie du titre de l'entrée et tu la regénère pour la comparer avec la variable $_GET['mavar']. Si c'est égal, c'est la bonne URL, sinon, c'est la mauvaise. Par contre, ne fais pas une erreur 404, mais une redirection 301. Tes visiteurs accèderont quand même au contenu et google considérera les liens vers cette URL pas si mauvaise que ça comme pointant vers la bonne URL. J'espère que j'ai été assez clair. Bonne soirée @+.

Alors, j'ai fait un peu le tour de la question et je pense que ceci peut être utile : User-agent: * Disallow: /index.php* //-> Ligne 1 Disallow: /?* //-> Ligne 2 Disallow: /*.html?* //-> Ligne 3 Explication de mon raisonnement : Ligne 1 : ne pas indexer tout ce qui commence par index.php (en effet, on utilise l'URL rewriting donc on met à disposition le contenu à indexer sous forme de fichier HTML. Ligne 2 : Devrait avoir le même effet que le première ligne, mais pour un accès à index.php implicite. Ligne 3 : Coup de sécurité pour être sûr que les individus malveillants n'ajoutent pas des paramètres CGI au page HTML réécrites. Cependant, j'émets des réserves. Notamment au sujet du ?. En effet, je ne connais pas les algorithmes utilisés par les moteurs en la matière. Le ? dans une expression régulière signifie 0 ou 1 caractère et j'ai peur que certains moteurs ne l'interprètent comme tel. Si vous avez des ressources traitant de ce sujet, je suis prenneur. A propos de la ligne 3, je suis entrain de voir pour traiter ça directement au niveau de l'URL rewriting avec une redirection 301.

Tu tombes à pic car c'est justement ce que je suis entrain de faire suite à de vaines attaque d'un guignol dues à l'utilisation de liens vers des fichiers qui n'existent pas sur mon site. En tout cas, j'espère qu'il aura été assez malin pour empêcher le cache et l'indexation de ses pages.... Heureusement, je surveille mes logs et le mal n'aura pas le temps d'agir car je m'en occupe depuis ce matin et j'avais prévu des adaptations pour faciliter cela. Je ne connais pas le cas spécifique de cet annuaire, mais si la gestion des erreurs est centralisée, il te suffit de référencer les cas où une erreur 404 devrait être retournée et, avant tout envoi de données, utiliser ceci : header('Date: ' . gmdate('D, d M Y H:i:s') . ' GMT', true, 404); Voilà ! Par contre, pour te préserver de ce genre d'attaque, il faut aussi désactiver l'indexation des URL avec index.php. Et c'est là que j'aurai besoin d'aide en ce sens que je souhaiterai pouvoir donner une intruction dans le fichier robots.txt qui empêche justement cela. Donc, si vous avez une page dans vos bookmarks qui parle de ça, je suis prenneur.

Ce petit sujet m'a inspiré un billet sur les sidebars qu'on a tendance à oublier et qui sont aussi à prendre en compte. Dans ce cas, même avec une résolution de 728*1024, il faut faire un design du type de ceux compatible avec le 800*600. Bref, de quoi devenir cinglé !

Je rejoins l'idée qui dit que les fautes d'orthographe jouent un rôle dans le référencement. Tout simplement parceque si je souhaitai améliorer la qualité des résultats d'un moteur, je calculerai le rapport : Mots du document dans le dictionnaire / Mots du document Et ça serait un des nombreux facteurs entrant en ligne de compte. Et puis, les fautes d'orthographe... c'est l'horreur...

Je fais du 800*600 aussi pour trois raisons : ne pas laisser d'utilisateurs sur la touche. les personnes qui utilisent d'énormes résolutions naviguent rarement en plein écran. De plus, quand on a une bonne résolution, on a tendance à laisser toujours ouverte une barre latérale (lecteur de flux, extensions etc...). créer un design extensible impose des limitations côté complexité du design. Bref, je pense que le 800*600 a encore de long jours devant lui sans compter que les ordinateur portables sont de plus en plus nombreux et qu'il faudrait être fou pour les utiliser avec une résolution astronomique... Et puis, vous en connaissez beaucoup vous, des gens dont l'écran ressemble à ça ?