Aller au contenu

JJJ

Hubmaster
  • Compteur de contenus

    106
  • Inscrit(e) le

  • Dernière visite

Tout ce qui a été posté par JJJ

  1. Ca foisonne ! mmmh en effet ton site est un bon exemple. Merci bien. Oui j'avais rencontré ces ressources didactiques, bien faîtes. Merci En fait avant de me lancer dans l'un ou l'autre (plume, dotclear, plume, dotclear...), je cherchais à avoir des expériences d'usagers ayant pratiqué la même chose que moi, mais plus loin encore : personnaliser plume autant que dotclear, histoire de comparer la somme de difficultés pour un même but recherché. Mon avis n'est pas arrêté et je sens de toutes façons qu'en torturant le code de dotclear, je vais fatalement me pencher sur plume en même temps... m'enfin, au cas où, j'aurais tenté de trouver aussi tordu que moi
  2. Oui, tu as tout à fait raison. Je planais en disant ça je crois...
  3. Davidm, merci pour la petite leçon, je te suis plus que tu ne le crois. Pour moi un blog est un CMS. Un CMS cest un content management system cest à dire un système de gestion de contenu. Stricto sensu un outil de blogging est un CMS : il permet de gérer du contenu. Ensuite, c'est la fonction principale qui va primer pour déclarer qu'un instrument est plus ceci que celà, en l'occurrence un wiki n'est pas un blog mais tout deux sont des système de gestion de contenu. Donc en effet, ce n'est plus une différence de nature entre applications, mais de degrés. Après, comme te l'a fait remarqué Dudu... j'ai bien employé un néologisme En fait si je demandais des astuces, c'est parce que même si je sais le fonctionnement du complexe php/css dans ces applications, le passage de l'un à l'autre (Dotclear>Plume) n'est pas techniquement explicite quand on n'a pas mis les mains dans les deux à la fois... C'était histoire de monter un petit cahier des charges anticipé et voir si ça valait plus le coup d'adapter dotclear au thème et à l'utilisation que je souhaite en faire, ou adapter le thème à plume, ce dernier correspondant plus au but recherché, dans sa fonction applicative.
  4. Mais que faire du spam humain ?... C'est moins amplifié que le spam indexing par robots, mais l'humain lui il comprendra très bien ce script source :-/
  5. J'y vais aussi alors ? Je savais pas si ça interessait l'auteur du topic puisqu'il ne semblait pas balancer spécifiquement entre phpBB et IPB, mais si tel était le cas, question ACP et tout, IPB est laaaaargement devant à mon avis aussi. Certains se sont même laissé porter à dire... usine à gaz... Mais c'est très bien. Evidemment y'a pa que ça à prendre en compte. Moi aussi je considère que du code valide c'est important quand on lance un forum, c'est une grosse botte d'épine dans le pied en moins ! (Dan confirme la validité de ipb apparemment... et reste discret sur phpBB...)
  6. J'espère qu'on ne va pas perdre la motivation et l'attention de l'auteur du topic en entrant dans certains détails, mais je veux quand même resituer ce que je dis. Le lamer dont tu parles, je crois pas qu'il aille acheter le produit pour trouver des failles.... quand même. On parle de pirates au moins un minimum doué là. Je n'ai jamais essayé ipb payant, note-le. Donc je te crois sur parole. Cependant, j'ai une expérience de l'époque gratuite et surtout du support bénévole officiel (français), et c'est jamais plus long qu'ailleurs en ce qi me concerne. Au-delà du temps d'attente pour une réponse, ce qui avantage ce support (et donc ce produit) à mon sens, c'est que pour le temps que tu attends, tu as une réponse qui veut dire quelque chose... Y'en a pas mal des communautés chez les autres, que je citerai pas, ou le premier type ayant installé un pauvre ipb 1.3 se prend pour le tout-puissant webmaster du foruming, et raconte n'importe quoi. Ce qui savent (vraiment), savent remettre les horloges à l'heure et rappeler des évidences. C'est con, mais c'est un fait aussi : un produit payant a souvent un support plus recommandable que son équivalent gratuit. Note que j'ai pas employé les relatifs souvent et recommandable pour rien... Je ne sais pas, je n'ai pas les moyens techniques d'avancer de pareilles certitudes. Est-ce que ipb est moins troué selon toi parce que moins hacké ?.. Arf t'as raison, j'ai oublié un mot au passage, ça porte à confusion... non je parlais de mod, pas de serveur dédié. De mod dédiés à cette option. - Je ne connais pas de forum inattaquable perso... - Je n'ai jamais fait que voir des webmaster qui, s'ils sont effectivement attaqués (ce qui, dans mon idée, est universellement possible), ont apris à sortir leur forum de ce foutoir avec des moyens préventifs et des connaissances techniques précises. - Question de choix ou de compétences de chacun peut-être, je pense que tu code bien mieux que moi le html respectueux que j'attendrais d'un forum. En ce qui me concerne, je préfère un forum faillible (comme tous) et apprendre/comprendre sa remise en route, puis faire sa en un tournemain, qu'un forum soi-disant inattaquable (qi va aveugler ma vigilance peut-être) qui en plus ne respecte rien dans son code généré, et passer des centaines d'heures à le rendre vivable pour un aveugle par exemple. Qu'en est-il de l'auteur de ce fil ? Lui seul le sait... D'accord avec le fait de relativiser les expériences de chacun. Ce sont des contributions subjectives, quel que soit le degré d'objectivité que chacun essaie d'y inséminer. Il me semble que le stress apparent de l'auteur du topic était fondé sur l'embarras du choix. Certains verront dans le choix un avantage (c'est clairement le dicours de fire soft board en page d'accueil), d'autres y voient là leur roblèm premier. Comparez et tester, c'est un idéal. Mais je peux comprendre le type qui ne veut pas acheter une licence juste pour comparer avec 18 autres applications... C'est pourquoi je me permettais de me mettre à la place de l'auteur du topic et de dire que l'important c'est d'abord d'analyser ses besoins + ses compétences + sa motivation à évoluer (car il ne s'agit pas seulement de se dire, ça je sais faire alors je prends ça, mais de se demander jusqu'où on veut bien aller pour ce projet en terme d'évolutivité, donc d'investissement perso). Quelqu'un qui veut du léger, il va se tourner vers punBB peut-être. Un peu rachitique, mais c'est un forum qui fonctionne bien. Quelqu'un qui veut la même chose sans bdd, va se tourner vers... Quelqu'un qui en comprend les enjeux, va se tourner vrs ça + des précisions sur la sécurité; alors le choix sera peut-être ipb si l'on en croit Dudu. Oui mais ipb c'est des ronds, et notre quidam a décrété qu'il aimait son projet mais ne pouvait pas acheter un truc pareil. Alors il va peut-être faire l'impasse sur la sécurité. Ou plutôt sur le code généré. Ou alors décider qu'il prend un forum considéré comme sûr, mais impropre dans son codage. Alors il va reconsidérer la question de l'investissement perso dans le cambouis du code source... et va tester sa motivation en surfant le hub par exemple et aller chercher quels sont les enjeux et les difficultés du codage à la main et la philosophie du W3C aussi.. ..etc etc. En résumé, avant de comparer tester et juger une application, il faut peut-être se pencher sur son propre projet quand il est encore en l'état d'idée.
  7. Ben écoute, je comprends ta recherche d'efficacité couplée à l'évolutivité (les mod etc), mais tu réponds à ta propre question. Du moins s'agissant de comparer IPB et phpBB. D'accord le nombre de mod phpBB est écrasant. Mais déjà vas voir chez ibf french, tu verras que t'as de quoi faire question mod. Ensuite, comme tu l'as bien remarqué, il y a plein de mod phpBB qui sont mal codés. De plus, qui déconnent entre elles (ceci est le cas pour tout ce qui se mode, mais objectivement plus t'as de mod possible, plus t'as de d'incompatibilités possibles). Enfin, ce sont pas toujours des mods supportés par les très fréquentes mises à jour de version de phpBB. Chose dont se passe assez ipb, qui pond beaucoup moins de nouvelles versions. La raison leur appartient, je débattrai pas dessus. Peut-être moins de failles chez ipb, peut-être moins de piratage, je ne sais pas. Donc ces considérations n'ébranlent pas mon propos précédent : ipb, ça le fait. Mais c'est payant d'une part, d'autre part on peut ne pas apprécier leur politique marchande (notamment la licence rétroactive, qui consiste dans le fond à faire une énorme étude de marché en se faisant passer pour du gratuit, tiens ça plaît à pleins de gens, donc maintenant on fait raquer. L'étude de marché et le lancement d'une stratégie pilote, les moins chères au onéreuses !). phpBB ça le fait, question philosophie (monsieur phpBB a rondement envoyé balader monsieur ipb quand ce dernier lui a proposer une association, ou un truc dans le genre. Je crois même que j'ai suivi le lien depuis le hub, qui racontait ça...), mais c'est instable, un peu bordélique, et prisé par peut-être plus de pirate que pour IPB. Quoique cette notion cmme je l'ai dit est très relative et ma foi sujette à éternelle nuance. Il me semble donc, pour arriver à ma conclusion, que si un forum comme phpBB, tout gratuit, puissant etc, parvient en plus à produire du code respectueux, et ben c'est un plus vis à vis de ces concurrents, notamment payants, et la question de la sécurité devient encore plus secondaire. Aloçrs si je me trouvais devant les mêmes problématiques que toi, je pense que je commencerais par vérifier ce que je crois (IPB a autant de mod que phpBB sinon plus, et en tout cas ils sont plus sûrs) (note que pour moi Mod = masculin...), puis je me demanderais si une bonne fois pour toute je tiens à mettre autant d'argent dans une application compte tenu des circonstances (il y a du gratuit qui peut assurer autant, c'est un fait), je poserais sur une feuille blanche mes priorités (modification avant tout ? Sécurité ? Code html généré ?) et enfin je me demanderais alors quel est le compromis à préférer dans la somme de tous ces premiers prémisses. En ce sens, à l'heure actuelle, si j'ai bien compris ce que tu cherches : gratuit + valide W3c (ça tu l'as pas énoncé mais je le considère pour toi ) + hautement modulable... je n'ai rencontré que punBB qui déclare officiellement être ceci. En natif punBB semble basique, c'est le cas. Beaucoup te diront, c'est génial, c'est basique mais on peut moder à fond, mais moder c'est une galère incroyable sur punBB. Si tel est le seul argument qui laisse des doutes, je me demanderais ce qu'il en est chez des concurrents (si on peut parler de concurrence parmi les appli libre) : et personnellement, pour avoir pratiqué IPB puis phpBB, ben je dis que quand c'est la merde, c'est la même odeur chez tut le monde. Moder, c'est difficile (selon le mod appliqué). Alors l'argument est nul et non avenu. Voilà une autre piste pour toi... (si pas compris, retourner à l'équation en rouge)
  8. Cet hébergeur c'est IR (pour les intimes) (y'en a qui connaissent). J'ai 2 solutions pour comprendre la chose : - leur site est en refonte et la partie francophone semble être passée à la trappe. Il n'y a pas plus d'infos là-dessus. Peut-être qu'il sont en train d'élaborer tous ces détails d'administration mais leur version francophone n'est pas en ligne. - j'ai eu des problème pour m'enregistrer chez eux. Leur script de formulaire de renseignement était gelé pour moi à partir d'un champ particulier (complètement inintéressant en plus !). Sur cette page de renseignement il y avait les champs de whois à remplir, et c'était assez exhaustif. Du fait de mon problème, je n'ai pas procédé à un enregistrement en ligne jusqu'au bout mais c'est un des admin du support qui l'a fait pour moi à la main. Je lui avais donné, sous forme d'image mise en ligne sur un espace web extérieur, tous les champs que j'avais rempli dans la page d'inscription gelée. Il y avait les infos whois... Malgré tout, ce ne sont pas celles-ci qui apparaissent quand je fais un whois. Pas du tout même. Peut-être que sa façon de procéder lui permettait moins de renseignements à indiquer que la page d'inscription en ligne, je ne sais pas. Toujours est-il que tu as vu juste sur une chose : je n'ai trouvé nulle part quoi que ce soit qui me permette de modifier mon whois à ma guise, et même si ça existe, en vertu du mail que j'ai copié ci-dessus, on ne m'a rie indiqué. Voici ma réponse à ce jour : "Bonjour, merci pour votre sollicitude mais je préfèrerais procéder moi-même. N'y a-t-il aucune voie admnisitratrice qui me soit offerte dans mon compte pour y parvenir ?" J'attends la réponse et vous informe...
  9. Oui c'est vrai, mais j'ai tendance à centraliser parce que bien que différentes, ces interrogations sont liées... Merci pour tes réponses et la confirmation ci-dessus Je suppose que tant que ça ne devient pas le foutoir dans l'arborescence FTP*, 6 bon mois avec un htaccess explicite devraient suffire...? (* voir question liée en bas de mon post. Je parle de foutoir dans le cas où l'on placerait un htaccess non pas à la racine mais dans chacun des répertoires renseignés comme déplacé ou redirigé de manière permanante) Merci pour le détail sur yahoo! Voilà je cherchais cette nuance qui n'était pas éclaircie dans l'article sur le hub. Merci encore Qu'est-ce qu'un effet de bord dans cette situation ? Une expression de la bouche du cap Haddock ? Ah oui je n'ai pas de reproche pour cet article Mon problème vient bien de cPanel, pour lequel d'ailleurs, en dehors des htaccess, je ne parviens pas à trouver un bon tuto exhaustif ou un site dédié à son utilisation. C'est pour ça que je disais que ça aurait bien sa place dans le hub, je dois pas être le seul à m'interroger sur cette appli puissante mais un peu obscure quand on aime comprendre ce qui se passe... Une question à laquelle tu as probablement une réponse mais qui t'a échappée dans la floppée de mon propos... : on peut centraliser tout htaccess en un seul fichier, à la racine du site ? Afin d'éviter de placer plusieurs htaccess dans un même ftp et dans chacun des répertoires. Et pour n'en plus finir... questions subsidiaires - si oui (on peut tout écrire dans un seul fichier maître), les url renseignés devraient plutôt être relatif ou absolus ? - Par absolu, faut-il entendre www.mondomaine.tld/etc.../etc..../ ou plutôt la ligne du path de apache, qui est autrement plus longue ? (note que j'anticipe : tu me dis que www.mondomaine.tld est un sous-domaine en fait lui aussi, donc j'en déduirais qu'il faut écrire le path et non passer par l'url du domaine général - mais je demande confirmation ) Bonne soirée
  10. J'ai l'impression de lire certaine idées reçues qui attestent une certaine méconnaissance des forums cités. Sans prétention mais uniquement avec ce que je sais (ou crois savoir), je réponds que : - une licence ne protègera jamais personne d'abus de hacking.... Celle-ci te servira au moins à pouvoir compter sur un support pro, qui devient un prestataire de service même. Si tu mets le prix, on te fera tout à ta place presque. (je parle pour IPB) - Les fonctionnalités de phpBB sont nombreuses, mais en natif phpBB ne ressemble jamais vraiment à tous les beaux et très customisés phpBB qu'on peut croiser sur le net ! Avoir des sous catégories et compagnies, par exemple, demande l'emploi de un ou deux dédiés à cet effet et assez célèbre chez les usagers de ce forum. Normal, c'est le plus qui donne à un forum sa richesse d'arborescence et tout ça. - Côté template et thème, IPB et phpBB sont assez équivalents. Je veux dire : le choix est vaste. A noter que chez IPB, on trouve dans des sites de fan des thème (skin) grandioses, mais ils ont le passage au payant plus facile depuis que IPB est lui-même devenu payant... L'avantage de phpBB est avant tout sa gratuité donc. Sinon le reste : support réactif (parmi les bénévoles disons), thèmes, modification, c'est assez similaire. Il me semble donc que ce n'est pas la question des failles de sécurité qui doit compter dans le choix d'un webmaster qui en plus a l'ambition de faire de son site un instrument marchand, mais plus le code généré par son forum. Des failles, il y en aura tout le temps et un peu chez tout le monde. Etre préventif demeure la règle fondamentale. Comprendre en grande partie le fonctionnement de son forum est une constante à promouvoir. Mais aujourd'hui, n'est-ce pas l'inquiétude vis à vis du code produit par son forum qui doit être prégnante ? Là par contre, j'ai rien à dire. Je crois que phpBB2 (l'actuelle version à ce jour) est pas au top, IPB je n'en sais rien du tout. Qui sait quel genre de code html sera sensé produire le très attendu phpBB3 ? Ca m'interesse fortement, et y'a comme un sorte de mutisme étrange autour du code généré par phpBB dans les communautés officielles...
  11. J'ai écrit à mon hébergeur pour avoir le coeur net et savoir quelle procédure utiliser pour modifier un whois. Sa réponse est sympathoche, mais ne me renseigne sur rien. Mouais...
  12. Ne pas afficher son adresse via un mailto, ni en image : la solution serait côté serveur. Enfin c'est ce que mon petit neurone webmaster me murmure. Donc disons un formulaire en php. Mais dans ce formulaire, l'adresse est aussi écrite, alors il faudrait crypter ce code source là pour l'empêcher d'être lisible par les programmes capables de repérer un @ correct dans du code source. Alors ce cryptage se fera-t-il avec du javascript au milieu de php ? Je sais pas si c'est possible mais en tout cas ça pose problème auprès de naviguateurs qui ne veulent pas entendre parler de javascript. Donc il semble que par élimination la solution soit d'utiliser un script php dans son formulaire d'envoi (pour éviter la visibilité auprès du public) avec un e-mail écrit crypté (pour emmerder les robots spammeurs). Question ? C'est possible ça ? php saurait fonctionner avec un e-mail crypter comme avec une écriture normale ? Moi afficher un e-mail crypté par php, je fais ça : <? function email_encode($string) { // CETTE FONCTION VA ENCODER L ADRESSE EMAIL $ret_string=""; $len=strlen($string); for($x=0;$x<$len;$x++) { $ord=ord(substr($string,$x,1)); $ret_string.="$ord;"; } return $ret_string; } // TEST echo email_encode("mon-email_AT_ici.tld"); ?> Le hic c'est que l'adresse n'est pas lisible dans le source mais affichée sur la page : le spam est humain aussi, malheureusement... Fabriquer un formulaire de contact par php afin déviter l'affichage brut du mail sur la page, je fais aussi. Mais allier les deux, ben je sais pas faire !
  13. Bah moi je ne crache pas sur les éditeurs de code (pas les ce-que-vous-voyez=ce-que-vous-obtenez hein, j'ai eu trop de mésaventures), parce que l'automaisation de lourde tâche en html, c'est bien quoi. Un peu comme le traitement par lots de photoshop, faut vérifier, être précis, mais quand c'est bien paramétré ça le fait bien de traiter 150 images en 5 minutes au lieu de le faire à la main. J'ai commencé à travailler avec webexpert, puis maintenant que la plupart de mes pages sont réalisées je fais des modif en mode texte avec notepad++ pour cause de légèreté d'ouverture et colorisation qui me convient bien... Puis un jour j'ai percuté que j'avais de grosses lacunes en ce qui concerne les standards (je m'en foutais complètement quand j'étais sur webexpert) et je cherche à recoder en apprenant bien. Dans ces cas-là un éditeur html peut s'avérer être un obstacle s'ilo est soit mauvais, soit mal paramétré. Alors j'ai lu le fil et les propositions fusent.... J'essaye HTML-kit en ce moment et sa tronche d'usine à gaz me fait déjà vaciller. Je suis déçu par sa traduction française aussi, qui n'est pas complète du tout (vous me direz, avec une usine pareille...). Pourtant, dommage car c'est plébiscité. Finalement mon bon vieux notepad++ me manque... mais manuellement je peux pas tout refaire seul, j'ai besoin d'un assistant qui allie performance, vélocité, légèreté d'interface et puis françisation aussi parce que j'ai autre chose à faire que traduire en permanence alors que je bosse déjà sur des langages qui ne me sont pas maternels ! Nvu semble interessant mais d'après framasoft, encore assez instable, pas assez matûre.... En clair, chuis paumé Je me demande aussi, l'interêt des apllications différents, séparant les travaux : il y a des gens qui ont un CSSeditor, couplé avec un devPHP par exemple + codage html... puis d'autres qui emploient tout en un (comme html kit). Pourquoi ces différences ? Le module de gestion php d'un html-kit est moins performant que devPHP ?
  14. Mmmmh... en effet comme je le pressentais ça m'a l'air un tantinet casse-gueule mon histoire. Non pas que je recule devant la difficulté mais bon, ce n'est qu'un site assez secondaire en fait... Je viens de parcourir les caractéristique du CMS 'Plume CMS' (anciennement Xulit), qui lui est tournée CMS en revanche. Il semble que ce soit un CMS basé sur dotclear, mais pas de blog en vue. Mon but initial en fait est de conserver le thème que j'ai trouvé qui me convient parfaitement. Celui-ci a été développé à l'origine pour dotclear, et j'ai cru comprendre que certains thème venant de dotclear pouvaient être adapté à Plume. Qui me confirmerait cela ? Parmi les usagers, certains ont des astuces pour adapter un thème dotclear vers plume ? Merci Dudu
  15. Bonjour bonjour, Appel aux usagers de dotclear, ou tous ceux qui le connaissent bien. Voilà, les blog c'est pas mon truc en terme de webmastering, mais certaains applications comme dotclear et d'autres peuvent s'avérer interessante concernant la gestion de contenu. J'ai déjà utilisé pleins de CMS, un peu moins d'applications orientées blog. Dotclear est plutôt orienté blog, mais j sais que certains s'en servent comme gestionnaire de contenu pas forcément avec l'esprit blog. Je crois même, si mes souvenirs sont bons ou si confonds pas les sites officiels, que le site francophone de dotcleau emploie sa propre application mais ce site a tout la tronche d'un non-blog. Donc je pourrais utiliser un petit CMS non orienté blog pour arriver à mes fins mais il se trouve que j'ai trouvé un thème pour dotclear qui colle parfaitement à ce que je cherche à réaliser : mon but étant alors de publier des ressources textuelles qui ne s'écrasent pas les unes et ls atres au fi du temps, comme ça se fait généralement dans les blog avec l'archivage par semaine, mois ou année. Je ne veux pas de calendrier, pas d'archives chronologiques, bref quitter les spécificités du blogging. Ma question est : est-ce possible avec une application automatisée comme dotclear ? Cel se passe-t-il en un clic dans la gestion de dotclear, ou est-ce qu'il s'agirait aussi de mettre les mains plutôt dans le thème ? Merci d'avance
  16. Tu peux aussi utiliser le javascript de cette façon : Dans un fichier terminé par l'extension .js js_banurl = new Array; js_banimageUrl=new Array; js_banimageUrl[0] = "url/Image1.gif"; js_banurl[0] = "Url du lien"; js_banimageUrl[1] = "url/Image2.gif"; js_banurl[1] = "Url du lien"; js_banimageUrl[2] = "url/Image3.gif"; js_banurl[2] = "Url du lien"; js_banimageUrl[3] = "url/Image4.gif"; js_banurl[3] = "Url du lien"; js_banimageUrl[4] = "url/Image1.gif"; js_banurl[4] = "Url du lien"; affiche = false; function AffichePub() { if(!affiche) { numimage= Math.round(Math.random()*(js_banurl.length-1)); document.write ('<A HREF="#" onClick="window.open(js_banurl[numimage],\'_blank\')"><IMG SRC="' + js_banimageUrl[numimage] + '" BORDER=0 NAME=js_banpub></A>') affiche = true; } else { if(numimage == (js_banurl.length-1)) numimage = 0; else numimage++; document.js_banpub.src=js_banimageUrl[numimage]; } setTimeout("AffichePub()",2000); } AffichePub(); (la valeur 2000 ci-dessus est le temps d'affichage de l'image, ici fixée à 20 secondes.) Tu nommes par exemple ton fichier en banniere.js, et à l'endroit de ta page ou tu souhaites que ces images défilantes soient affichées, tu colles : <script LANGUAGE="javascript SRC=../banniere.js"></SCRIPT> Ainsi tu centralises toute la fonction dans un fichier à part que tu peux modifier à souhait chaque fois que tu veux ajouter une image, et non remettre les mains dans chaque page où elles s'affichent.
  17. Bonjour tout l'monde Rapport à l'excellent article sur l'utilité du htaccess, j'ai quelques questions pour ce paragraphes : Bon je suppose que ce htaccess devrait être placé à la racine du répertoire en question, dans le cas du déplacement d'une page spécifique d'un répertoire par exemple ou dans le cas d'un déplacement de répertoire. A ce moment on emploie un url relatif. Mais ne peut-on pas centraliser toutes ces infos dans un seul htaccess à la racine du domaine afin de s'aléger la tâche en terme d'organisation ? (et utilise alors des url absolus). C'était ze first question. La seconde : "Pour déplacer un répertoire : RedirectPermanent /ancien http://www.domaine.tld/nouveau/ Il est important de noter que dans le cas dutilisation de la directive RedirectPermanent, la nouvelle adresse de page ou de répertoire doit être une URL complète." C'est mon cas. En changant dhébergement j'en ai profité pour y ouvrir un subdomain pour chaque site indépendant alors qu'avant j'employais simplement la création de répertoire pour chaque nouveau site. En créant un subdomain (exemple : http://lenouveausite.mondomaine.net), celui-ci est considéré comme un site à part entière par les spider et indexé avec son pagerank à lui et tout ça. Enfin, je crois... Bref, l'indexation pré-déplacement centralisée dans la bdd des spiders pour chacune des pages de l'ancien répertoire devrait normalement, avec ce htaccess, aboutir à une redirection d'indexation du nouveau sous-domaine. Ca suppose de laisser quelques tmps l'ancien répertoire en ligne, avec son htaccess, le temps que les spiders passent et procèdent à l'index du nouveau site déplacé. Mais combien de temps conserver ce répertoire vie et son htaccess, approximativement ? Ca fait pas très propre dans l'arborescence ftp d'avoir pleins de répertoires vides ... Troisième question : il est bien spécifié dans le tuto que manipuler le htaccess de la racine du domaine est délicat dans le cas d'extenions frontpage activées. Mais il y a une nuance que je ne trouve pas : mon hébergement est sous unix et j'ai demandé à avoir l'extension frontpage, même si je ne m'en sers pas. Alors est-ce aussi délicat dans le cas d'avoir des extensions frontpage possibles mais non utilisées que dans le cas d'extensions vraiment utilisées ? Je veux dire, moi je m'en sers pas.... Mais je ne sais pas trop ce qu'il en est de la config de mon hébergeur par rapport à ça, si lui s'en sert ou si cela change la donne quant à la configuration de mon espace pour ses serveurs. Encore une : avec cet hébergement je suis sur cPanel, avec lequel j'utilise la création de sous-domaines mais aussi les redirections permanentes. C'est sympa les applications puissantes et automatiques mais on se retrouve souvent avec des fichiers de config dans lesquels on a jamais mis le nez, forcément, l'application s'en occupe et automatise la chose. C'est le cas pour moi, je vois un htaccess à la racine de mon public_html que j'ai ouvert et qui indique une redirection permanente pour un sous-domaine que j'ai en effet crée. Hormis le fait que je n'en comprends qu'une partie et pas certains renseignements (ça a l'air plus omplexifié que ce qu'enseigne le tuto), je me demande : i je modifie ce htaccess pour ajouter de nouvelles infos à l'attention des moteurs par exemple, si j'ajoute des redirections etc, ça fonctionnera, certes, mais sans conflit avec cPanel ? Et le jour où j'emploierai de nouveau cPanel pour cegenre d'action, est-ce que ç ne va pas écraser les lignes de code que j'ai entré manuellement auparavant ? En résumé, je trouve le codage des htaccess assez pratique et même très clair à comprendre, mais dès que c'es mis en association avec une application qui se charge de l'encoder aussi, je m'interroge sur les conflits possibles. D'autant plus que je n'ai jamais vraiment trouvé de tuto francophone détaillant bien l'usage de cPanel, ses astuces et ses nuances, hormis quelques pages de FAI parfois qui font de blles paraphrases (d'ailleurs ça ferait un bel article sympathoche sur webmaster hub). Exemple : ... Merci pour vos lumières, confirmations et tout ça...
  18. Non parce que c'est ce registrar qui est censé s'en occuper via les infos que je lui ai fournies. Or il y a eu cafouillage un peu entre les infos que j'ai fournies et mon ouverture de compte chez ce registrar. Donc ça se passe pas dans le cPanel... mais pourquoi ci-dessus on me parle d'une identification par login/pass chez mon registrar pour modifier ça ?
  19. Quand je demande ça, je suppute que ça se passe dans le panel administrateur qui est cpanel pour moi hein... Faut me dire si moi être dans l'erreur
  20. J'en déduis que tu t'es servi de dotclear pour peaufiner tes connaissances en php dans un codage initial assez propre... ?
  21. Bonsoir et merci, sur mon nouveau registrar, je suis sur cpanel. Tu sais où ça se trouve cette histoire ?
  22. Topic rapide mais efficace Je trouve que le plus dur reste encore de ne pas céder à la tentation du faire croire que/alors que ... Je veux dire que le webmaster qui penche plutôt pour le codage à la main perso, sauf s'il maitrise assez bien le php (ou autre langage dynamique côté serveur), peut être tenté d'utiliser certaines solutions tout en un comme des script tout fait (php contact, livre d'or etc) : il les imbriquent dans ses pages intitialement codé de sa main car il ne sait pas faire ces script là lui-même, et lorsqu'il a un plantage ou une faille il retombe dans le même cercle vicieux que les application CMS dédiée avec l'avantage du support communautaire en moins, c'est à dire qu'il administre un site dont il ne comprend que la moitié du fonctionnement, et l'autre moitié le laisse sur la touche... On peut certes penser qu'employer des script pré-codé permet aussi d'apprendre avec illustration : en regardant le source et l'architecture de ces outils provenant d'autrui, on se met à tenter son propre script etc. Mais là je suis plutôt sceptique : d'abord parce que celui qui a mis en ligne son script gratuitement à l'attention de la communauté avait pour but de proposer un outil qui fonctionne avant tout, il a donc pu utiliser quelques astuces php de son cru que le débutant ne comprendra pas ou qui le déroutera, ensuite parce que tous les script ne se valent pas, même parmi les plus simple, ç cause de la richesse du langage php et/ou tout simlement du fait qu'aucun codeur n'est parfait et l'un trouvera toujours mieux à faire dans un script que l'autre. A partir de là, si vous êtes d'accord avec c'te réflexion, je pose la question : la seule solution 'propre' est-elle que travailler le php soi-même depuis le début (le <? quoi ...), et donc demeurer dans l'obligation d'attendre de longs mois, voire plus, avant d'oser mettre un site en ligne ?..
  23. Bonjour, je m'explique : J'avais un nom de domaine enregistré pour la toute première fois par un registrar tout en un (domaine + disque). Le whois a toujours undiqué, en gros : enregistré par 'registrar' pour 'moi', ce qui semble logique puisque j'ai passé le relai à un prestataire qui s'en est occupé. Aujourd'hui, j'ai changé d'hébergeur pour une offre similaire (nom + espace) mais il distingue les deux dans l'offre : et un whois sur mon domaine devient anarchique : - le registrar administratif reste l'ancien hébergeur; il est aussi le "technical contact" - le "biling", celui qui a procédé au traitement de mon paiment, porte un nom différent de mon nouvel hébergeur (ça je le savais) - le "contact information" : c'est moi, mais sous l'adresse que j'avais renseignée lorsque j'étais chez mon ancien hébergeur au début. Depuis j'ai déménagé cinq fois... Ma question est : - puis-je modifier moi-même ces info ? Ou demander à ce que ça soit fait. - Puis-je, avant tout, les mettre à jour (comme mon adresse ou mon nom, tout ça je veux le changer en fait), et aussi puis-je renseigné ds infos à ma sauce ? Exemple, au lieu de renseigner le nom de la compagnie en 'moi.com' je préfèrerais 'moi compagnie' etc etc... Merci pr vos lumières (NB : j'ai utilisé principalement cet outil http://www.geektools.com/whois.php pour vérifier mon whois)
  24. Oui suite à mon post j'ai persisté dans quelques recherches et framasoft par exemple m'apprend que nVU ou Scite je crois intègre tidy le nettoyeur-pourfendeur de code... C'est déjà ça mais une question persiste et une autre se révèle : 1) Comment accepter des éditeurs html payants, réputés et tout ça, qui ne respectent pas eux-mêmes tout ça ?... Je m'interroge sur le lien entre les "décideurs" des standards du web et les développeurs de ces programmes. 2) Tidy semble plebiscité (est-ce le seul qui vaille le coup ?), est-il précisément configurable lors de ses opérations de nettoyage ? Je veux dire, parfois, on connaît ses propres repères dans son code source et quand un nettoyeur passe par là, ça devient le chaos pour reprendre le dessus... aucun webmaster n'apprécie, je suppose, une intrusion trop sévère dans son code amoureusement écritet pianoté sans savoir ce qu'il va s'y passer... Subsidiaire : vous conseillez quel éditeur HTML pour être au plus près des standards du web lorsqu'on applique des opérations automatique (mon exemple de l'insertion d'image) ? Pour le moment, j'ai surtout accroché sur la fiche descriptive de nVU qui va de concert avec l'esprit du naviguateur de mozilla.
  25. Bonjour, voilà je m'interroge sur les raccourcis des editeurs html les plus généraux ou populaires : par exemple moi j'utilise webexpert. Bon, illustration : je veux insérer une image dans mon document, je m'emmerde pas à taper le tout à la main (src= etc...), bien que je bosse mon document en mode source j'emploie le raccourci du programme bien utile en terme de gain de temps, qui me permet d'aller chercher mon image dans un répertoire adéquat et insère comme un grand les balises de base. Comme attribut, je lui applique un alignement absmiddle de mise en forme dans la balise; le hic c'est que c'est pas autorisé par la charte de qualité du markup langage. Validator W3 : Or mon questionnement est le suivant : je mets au défi quiconque de connaître par coeur et en temps réel l'intégralité, et en détail, des standards réels du markup langage. C'est très long et ça évolue... Enfin si quelqu'un relève le défi je l'applaudis d'avance, mais en ce qui me concerne je n'ai pas le temps de travailler ça pour tant de détails; j'en connais une certaine partie pour ne pas faire de grossière erreurs mais l'intégralité... Or ce sont des options proposées par de grands éditeurs html. Alors comment savoir si un code est propre alors même que l'éditeurs le considère comme utilisable ?! Y'a comme un décalage là entre la philosophie de la validation du html transitionnel et la technique de pleins de logiciels, non ? Au plaisir de vous lire
×
×
  • Créer...