Testez la nouvelle version de LinuxFr.org

Posté par  (site web personnel) . Édité par Benoît Sibaud. Modéré par Florent Zara.
Étiquettes :
40
9
nov.
2010
LinuxFr.org
Le site LinuxFr.org existe depuis 12 ans et a connu de nombreuses versions et évolutions. La version actuelle fonctionne avec templeet (NdM: lien éditée en 2021 pour pointer vers la version archive.org de l'époque) et est devenue difficile à faire évoluer pour diverses raisons (peu de contributeurs, absence de documentation, écosystème de templeet quasi-inexistant, etc.).

J'ai donc décidé, début 2009, de réécrire LinuxFr.org en Ruby on Rails. Commit après commit, cette nouvelle version a commencé à prendre forme. Je suis maintenant arrivé à un point où je souhaite qu'elle soit visible publiquement.

Oh, je sais, il reste encore du boulot : la charte graphique n'est vraiment pas réussie, il manque encore des fonctionnalités du site existant, il reste probablement beaucoup de bugs, etc. Mais je pense que vous, lecteurs, pouvez plus que jamais contribuer à améliorer cette version.

Pour cela, vous pouvez :
  • Tester cette version à plus grande échelle et remonter le maximum de bugs avant le passage en production (plus de détails en seconde partie) ;
  • Vérifier que les contenus importés depuis le site existant sont corrects. Cela consiste à vérifier que le contenu est présent, en entier et que son balisage HTML est le même que celui du site actuel ;
  • Nous aider à adapter la charte graphique à ce nouveau site. En effet, le graphisme n’est pas le fort de l’équipe qui gère le site. Et comme nous ne sommes pas des ingrats, nous y mettons les moyens et nous lançons un concours pour déterminer le prochain design du site. Au menu : un HTC Desire et une tablette sous Android, un hébergement dédié et du matériel pour Geek. Tous les détails dans la dépêche dédiée au concours !
  • Packager pour Debian la dernière version de webalizer que nous utilisons pour nos statistiques web.


Merci pour votre soutien et implication ! La nouvelle version fonctionne globalement comme l'ancienne, mais pas tout à fait. Par exemple, écrire des contenus ne se fera plus directement en HTML, mais passera par Markdown, une syntaxe wiki. D'autres fonctionnalités sont manquantes, mais devraient arriver bientôt. C'est, par exemple, le cas des statistiques.

Mais que vous soyez confronté à un bug ou qu'une fonctionnalité soit manquante, vous êtes encouragés à nous le dire, en créant une entrée sur github : https://github.com/nono/linuxfr.org/issues.

Un point important à savoir est que les deux versions utilisent des bases de données séparées et qui ne seront pas resynchronisées. Pour commencer, j'ai importé la base de données du site existant dans le nouveau site (via un script maison). Vous pouvez donc utiliser vos comptes sur la nouvelle version. Mais si vous faites un changement sur une version, il n'impactera pas l'autre version.

Le jour où la version Rails deviendra la version officielle qui servira http://linuxfr.org/, j'utiliserai la base de données du site existant (version templeet) pour importer les données. La base de données de alpha.linuxfr.org sera alors détruite. Vous êtes donc encouragés à ne rien publier sur alpha sans en garder une copie chez vous. D'une part, la pérennité de cette version alpha n'est pas assurée. D'autre part, dans un futur plus proche, le site comporte des bugs et le contenu pourrait être perdu à cause de ceux-ci.

Aller plus loin

  • # Bravo !

    Posté par  . Évalué à 10.

    Y'a plus qu'à tester !

    Merci...
  • # https - ajout fonctionalité

    Posté par  (site web personnel) . Évalué à 6.

    Lorsqu'on s'authentifie, il pourrait basculer sur https pour forcer un peu les personnes à l'utiliser en https et non en http.
    • [^] # Re: https - ajout fonctionalité

      Posté par  (site web personnel) . Évalué à 4.

      Je me permet de me contenter de citer la news :
      Mais que vous soyez confronté à un bug ou qu'une fonctionnalité soit manquante, vous êtes encouragés à nous le dire, en créant une entrée sur github : https://github.com/nono/linuxfr.org/issues.

      Après, il est vrai qu'en parler ici peut initier un débat...
      • [^] # Re: https - ajout fonctionalité

        Posté par  (site web personnel) . Évalué à 10.

        J'ai eu l'idée et j'ai fais le commentaire vite fais sans réfléchir.

        Je viens d'aller sur github, il faut encore créer un compte... Personnellement, je sature de cette obligation de créer des comptes à droite et à gauche.
        • [^] # Re: https - ajout fonctionalité

          Posté par  (site web personnel) . Évalué à 1.

          Si tu ne souhaites pas créer de compte sur github (ce que je peux comprendre), je t'encourage à créer une entrée sur le tracker actuel: https://linuxfr.org/tracker/.
        • [^] # Re: https - ajout fonctionalité

          Posté par  (site web personnel) . Évalué à 2.

          Je viens d'aller sur github, il faut encore créer un compte... Personnellement, je sature de cette obligation de créer des comptes à droite et à gauche.

          Je comprends le sentiment, mais je crois que tu ne regretteras pas d'avoir créé un compte sur github. C'est vraiment un site sympa.
          • [^] # Re: https - ajout fonctionalité

            Posté par  . Évalué à 3.

            Github me fait l'impression d'être le MySpace des geeks.

            Il me rebute par sa façon d'exacerber tous les défauts de Sourfeforge en matière de communication sur les projets hébergés.

            Github est un site fait par des hackers pour des hackers qui refusent de communiquer avec les non-hackers.

            Pour ces raisons je ne veux pas me créer de compte dessus ni même visiter les pages hébergées.

            BeOS le faisait il y a 20 ans !

            • [^] # Re: https - ajout fonctionalité

              Posté par  . Évalué à 2.

              Visiblement faut pas dire du mal de Github, icite.
            • [^] # Re: https - ajout fonctionalité

              Posté par  . Évalué à 3.

              Hop je vais faire mon relou, je ne vois pas l’intérêt par rapport à gitorious qui lui utilise un logiciel libre (après d'un point de vu personnel, je trouve gitorious plus joli et j'ai un compte sur les deux).

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: https - ajout fonctionalité

            Posté par  . Évalué à -2.

            On peut récupérer les sources ?
            Non, bon bin sans moi alors.

            Sur l'autre news :
            http://linuxfr.org//2010/11/09/27372.html
            Il est indiqué qu'il faut aller sur InDefero pour le concours de CSS.
            Est-ce qu'il est envisagé de migrer sur cette forge bien sympathique, faite par un ptit gars qui traîne par ici et surtout libre ?
            • [^] # Re: https - ajout fonctionalité

              Posté par  (site web personnel) . Évalué à 0.

              On peut récupérer les sources ?
              Non, bon bin sans moi alors.


              J'en conclus que tu n'utilises pas Google?
              • [^] # Re: https - ajout fonctionalité

                Posté par  . Évalué à 2.

                Ca ne répond pas à ma question.

                Qu'est-ce qui est mieux sur Github par rapport à InDefero et qui serait indispensable ?

                C'est une vraie question.
                • [^] # Re: https - ajout fonctionalité

                  Posté par  . Évalué à 2.

                  Je crois que j'ai trouvé la raison de cet engouement:


                  Ce site est développé en Ruby on Rails.


                  http://fr.wikipedia.org/wiki/GitHub

                  Dommage qu'on puisse pas récupérer les sources, vraiment ! Pour une fois que du RoR a l'air de tenir la charge, quoique personne ne peut le prouver du coup.
                • [^] # Re: https - ajout fonctionalité

                  Posté par  . Évalué à 1.

                  Je vois que Git est hébergé dessus aussi.
                  Vivement qu'il nous refassent le coup de Bitkeeper en fermant leur plateforme après un rachat par Oracle (Atlassian, le propriétaire de JIRA vient déjà d'acquérir Bitbucket). Linus nous sortira vite fait une jolie forge aux petits oignons.

                  :O)
                  • [^] # Re: https - ajout fonctionalité

                    Posté par  . Évalué à 2.

                    Une forge écrite en C et administrable en ligne de commande ?

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: https - ajout fonctionalité

                      Posté par  . Évalué à 3.

                      Ça, c'est si c'est Stallman qui s'en occupe, ça sera un mix de C et de LISP, et ça tournera dans Emacs. Rien que d’y (Emacs) penser, ça me déprime.

                      Depending on the time of day, the French go either way.

                • [^] # Re: https - ajout fonctionalité

                  Posté par  (site web personnel) . Évalué à 3.

                  Qu'est-ce qui est mieux sur Github par rapport à InDefero et qui serait indispensable ?

                  C'est une vraie question.


                  Je ne connais pas bien inDefero, mais je viens d'aller faire un tour dessus, et il me semble qu'il n'y a pas l'aspect social de github. On aime ou on aime pas, mais github est un peu le facebook de l'open source, avec plein d'outils pour voir ce que font les autres, les trucs en vogue du moment... Perso je trouve que ça donne des idées et qu'on trouve plein de projets et d'idées sympa.
                  • [^] # Re: https - ajout fonctionalité

                    Posté par  . Évalué à 2.

                    N'étant pas inscrit sur Facebook non plus j'ai un peu du mal à comprendre.
                    Tu pourrais développer avec un exemple précis.

                    Parce que je ne vois que les features classiques des forges récentes.

                    Suivi de bugs
                    Suivi des commits par projet, user, ...
                    Code review
                    Browsing de source
                    Recherche de projets
                    Timeline
                    ...

                    que tu trouveras ici:
                    http://indefero.net/tour/

                    Si tu me parles des petits gadgets "add to Facebook", "retweet" and co, ca me parait mince.
                    • [^] # Re: https - ajout fonctionalité

                      Posté par  (site web personnel) . Évalué à 4.

                      Un exemple parmi d'autres : tu peux "watcher" un projet ou une personne, et tu es informé des derniers commits ou des dernières actions de cette personne.

                      De cette manière tu peux suivre les développements sur un projet, découvrir les projets qui intéressent tes amis, etc.
                  • [^] # Re: https - ajout fonctionalité

                    Posté par  (site web personnel) . Évalué à 8.

                    La vraie question est : Peut-on jouer à Farmville sur GitHub ?

                    L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: https - ajout fonctionalité

      Posté par  (site web personnel) . Évalué à 3.

      Deux questions :

      1) Pourquoi vouloir forcer les gens à passer en https ?
      2) Si tous les utilisateurs de linuxfr authentifiés voire non-authentifiés consultaient le site linuxfr.org en https l'infrastrucuture pourrait-elle le supporter ?
      • [^] # Re: https - ajout fonctionalité

        Posté par  (site web personnel) . Évalué à 1.

        Parce que 99% des utilisateurs utilisent le même mot de passe partout.

        Parce que la DST ne se gène certainement pas pour construite une base de données de tous les identifiants qui trainent sur le net

        Ensuite, coté charge du serveur, je ne sais pas quel est le surcoût du https.
        • [^] # Re: https - ajout fonctionalité

          Posté par  (site web personnel) . Évalué à 2.

          "Parce que 99% des utilisateurs utilisent le même mot de passe partout." => Tu fais juste en sorte que le formulaire de login soit vers du https. Pas besoin de forcer les gens à rester en https lorsqu'ils sont authentifiés. Tu parlais peut être juste de la partie authentification en elle-même mais je ne suis pas sûr.
          • [^] # Re: https - ajout fonctionalité

            Posté par  . Évalué à 8.

            Et on se retrouve dans le cas ou Firesheep va aller récupérer tout les cookies d'authentification. Du coup n'importe qui peut aller sur ton compte sans connaître ton mot de passe. Il peut découvrir ton email si tu le cache, et bien d'autres choses encore...
        • [^] # Re: https - ajout fonctionalité

          Posté par  (site web personnel) . Évalué à 2.

          >Parce que la DST ne se gène certainement pas pour construite une base de données de tous les identifiants qui trainent sur le net

          heu et comment fait la DST pour sniffer ton mot de passe ?
          • [^] # Re: https - ajout fonctionalité

            Posté par  . Évalué à 7.

            Ils ont le nez creux.
          • [^] # Re: https - ajout fonctionalité

            Posté par  . Évalué à 1.

            Ils font comme tout le monde. Y'a régulièrement des sites qui se font attraper par la presse/blogosphère parce que le fichier des identifiants/mots de passe a été piraté / publié sur un réseau P2P / vendu par un vilain pirate Russe (ou Bulgare à la rigueur).

            Comme la plupart des gens (j'irais pas jusqu'à 99%) utilisent en effet le même identifiant/mot de passe partout, ben bingo. Et la DST peut donc faire pareil que tout le monde.
            • [^] # Re: https - ajout fonctionalité

              Posté par  (site web personnel) . Évalué à 2.

              et donc en quoi le fait que ça soit en https change quelque chose ?

              que tu me dise que mon admin/fai peut sniffer mon mot de passe qui passe en clair en HTTP oui, que la DST puisse le faire, vu le chemin que prennent les paquets, ça m'etonne.
          • [^] # Re: https - ajout fonctionalité

            Posté par  . Évalué à 4.

            Ils ont recruté JL Delarue?
    • [^] # Re: https - ajout fonctionalité

      Posté par  . Évalué à 2.

      Pour se bouffer une grosse page rouge sous firefox ou chrome parce que le certificat de linuxfr n'est pas valide ?
  • # Par curiosité

    Posté par  (Mastodon) . Évalué à 10.

    Quels sont les arguments qui ont motivé la réécriture complète du site plutôt que l'utilisation d'un CMS existant ?
    • [^] # Re: Par curiosité

      Posté par  . Évalué à 0.

      tu as deja utiliser un CMS du marché ?

      je pense que non ^^ (en tous cas pas au point de devoir les faire rentrer dans le moule de tes besoins)
      • [^] # Re: Par curiosité

        Posté par  (Mastodon) . Évalué à 3.

        Perdu.

        Et il n'est pas plus compliqué de faire un module pour un CMS bien fait que de refaire un CMS complet.

        Sauf qu'en s'appuyant sur un CMS, tu profites de l'expérience de toute une communauté.

        Et qui va faire un audit du code du nouveau dlfp pour vérifier qu'il n'y a pas de failles ?
        • [^] # Re: Par curiosité

          Posté par  (site web personnel) . Évalué à 8.

          Les moules sont près à s'occuper de cette tâche ingrate et à débusquer les XSS injections possibles. Elles ont une certaine expérience dans le sujet /o\

          L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

        • [^] # Re: Par curiosité

          Posté par  (site web personnel) . Évalué à 9.

          Ca a été développé sur Ruby On Rails. Ce type de framework est une sorte d'architecture de site déjà validé sur une multitude de projets dans lequel on code juste ses spéficificités métier.
          • [^] # Re: Par curiosité

            Posté par  (site web personnel) . Évalué à 5.

            Et la marmotte...

            L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

        • [^] # Re: Par curiosité

          Posté par  (site web personnel) . Évalué à 7.

          Si c'est beaucoup plus compliqué. Les CMS existant ne vont satisfaire que 50% au mieux de tes besoins sur un site un peu pointu comme DLFP.

          Avec un CMS existant, soit tu as identifié des extensions existantes qui satisfont tes besoins et tu estime que tu n'a pas énormément de modifications à faire pour être à peu près satisfait du résultat, soit tu passe ton chemin.

          Mais si c'est pour empiler une douzaines d'extensions pour lesquelles tu n'a aucune assurance en ce qui concerne l'avenir en terme de maintenance, ça vaut pas le coup de partir sur un CMS.

          On estime que dans le cas d'un CMS comme Joomla!*, ce sont les extensions qui présentent le plus gros risque pour la sécurité du site. Le coeur du CMS étant lui patché très régulièrement et rapidement après découverte des failles, mais ce n'est pas du tout le cas de la plupart des extensions.

          Si tu veux par exemple refaire DLFP avec Joomla! il va te falloir empiler les extensions : forum, commentaires, captcha, réecriture d'url, tracker, tribune etc.
          Et encore...il va falloir modifier chacune d'entre elle, pour peu qu'elles existent (genre tribune, je doute), puis maintenir tes modifications en suivant les mises à jour des extensions.

          * Je prend Joomla! comme exemple parce que c'est celui que je connais le mieux.
    • [^] # Re: Par curiosité

      Posté par  . Évalué à 10.

      Les mêmes qui ont motivé celle du passage de Dacode à Templeet, j'imagine. Développer est un plaisir aussi grand qu'administrer, même s'il y a beaucoup de gens pour qui c'est une notion étrange, visiblement.
      • [^] # Re: Par curiosité

        Posté par  . Évalué à 3.

        Est-ce qu'il existe des archives sous Dacode, dans le cloud?

        Nostalgie.... quand tu nous tiens.
      • [^] # Re: Par curiosité

        Posté par  (site web personnel) . Évalué à 2.

        Développer c'est bien mais il ne faut pas pour autant que ça devienne un truc élitiste comme Templeet que plus personne ne maintenait.

        Bon, je suppose que plus de monde connait RoR mais forcément on profite moins de ce qui peut se faire ailleurs en codant son propre CMS qu'en utilisant un CMS connu.

        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

        • [^] # Re: Par curiosité

          Posté par  (Mastodon) . Évalué à 7.

          Bah et puis (en plus de ce qu'explique le dev principal dans le commentaire après, et le rappel sur plaisir juste avant) y a aussi, que franchement quant même, DLFP mieux que la Maison Blanche ;) Leur CMS à eux, ça a quant même plus de gueule :))
          (et puis maintenant que drupal est utilisé par la maison blanche on peux aisément comprendre que tout les commits soient examiné à la loupe)

          ps à propos des mdp du https, de la dst du serve & protect, toussa, un peu plus haut. il me semble avoir vu passer y a longtemps (pas vérifié avec ce post, j'capte trop mal le wifi du voisin dans ma piaule, pas la patience) du TLS v1.1. Donc bon si c'est toujours ça avec un peu de patience et qq machines ça doit être faisable. Là encore, notion de plaisir et de jeu toussa

          ps 2, question :
          Pourquoi ne pas faire en deux fois ?
          Perso je trouvera ça "trop classe" d'avoir exactement le même design les premiers temps. Toute l'infra a basculé sur version RoR, et paf on a rien vu :))
          Deuxième temps, faire évoluer la css.
          • [^] # Re: Par curiosité

            Posté par  . Évalué à 6.

            Pourquoi ne pas faire en deux fois ?
            Perso je trouvera ça "trop classe" d'avoir exactement le même design les premiers temps. Toute l'infra a basculé sur version RoR, et paf on a rien vu :))
            Deuxième temps, faire évoluer la css.


            Ben, d'abord parce que c'est long. La dernière C.S.S. que j'ai faite m'a pris 80 heures de boulot à la louche, ensuite parce qu'on sait que le provisoire devient presque toujours définitif, au bout d'un moment. Personne n'aime se taper deux fois le même boulot. Si, en plus, c'est purement participatif, c'est du temps perdu qu'on aurait pu passer à peaufiner le premier travail.

            Pour répondre plus précisément à ta question, il est pratiquement impossible de migrer directement les anciens thèmes sur la nouvelle version du site, surtout s'ils sont un peu « tordus », c'est-à-dire si les C.S.S. utilisent des astuces pour faire des mises en page non prévues par le code H.T.M.L. initial.

            Ensuite, objectivement, un gros travail, il faut que ça se voit : refaire toute l'infrastructure d'un back-end, c'est un plaisir d'initié. Seuls tes collègues directs peuvent en témoigner – et encore ! Par contre, quand tu changes la C.S.S. en choisissant une charte graphique complètement différente de l'ancien système, là, tu as l'impression d'avoir acheté une voiture neuve. On a même l'impression, au moins au début, que le système marche un peu mieux. :-)
    • [^] # Re: Par curiosité

      Posté par  (site web personnel) . Évalué à 10.

      Bonne question :-)

      Il faut voir que j'ai commencé la réécriture il y a presque 2 ans et il faut donc tenir compte du fait que j'ai fait le choix en fonction de ce qui se faisait à l'époque et non pas de ce qui se fait maintenant.

      Mon langage de prédilection est le Ruby, j'ai donc commencé par regarder s'il y avait des CMS en Ruby qui pouvaient convenir. À l'époque, il n'y avait rien de vraiment probant (et encore aujourd'hui, les CMS en Rails, ce n'est pas vraiment ça).

      J'ai donc commencé à aller voir ailleurs. Dans beaucoup de cas, ça ne faisait pas grand chose des fonctionnalités demandés pour LinuxFr.org : la tribune, les commentaires sous forme d'arbre de discussions, différencier les nouveaux commentaires des commentaires déjà lus, etc. Du coup, quitte à devoir tout recoder, je préfèrais partir sur du Ruby on Rails plutôt qu'un CMS existant dans notre langage que je ne maitrise pas forcément aussi bien.

      Après, il y a deux ou trois CMS qui auraient pu convenir. Je me rappelle surtout du cas de Drupal. J'avais commencé à regarder la chose et avais eu l'occasion de participer à un apéro Drupal (IIRC, c'était une des rencontres qui a permis la création d'une communauté Drupal française, réunie maintenant sur drupalfr.org).

      J'ai donc pu avoir des retours de gens qui utilisaient Drupal couramment, voir qui contribuaient au développement. Et ces retours m'avaient fortement refroidis. Je ne me souviens plus précisément des propos, mais c'étaient du genre : tiendra pas la charge ; moi, j'attendrais la prochaine version de Drupal ; faudra sûrement sacrifier quelques fonctionnalités ; etc.

      Bref, à l'époque, le choix le plus sûr m'avait paru Ruby on Rails que je maitrisais bien. Si je devais refaire ça aujourd'hui, je procéderais de la même façon mais je ne suis pas sûr que la décision finale serait la même.
      • [^] # Re: Par curiosité

        Posté par  . Évalué à 2.

        Tu crois que ta décision finale serait quoi si tu la faisais aujourd'hui ? Et pour quelles raisons principales ?

        Je pose la question car je suis aussi développeur RoR et ça me semble intéressant de rester aussi ouvert/informé ce qui se fait "à coté" et des points forts de chacun !

        Félicitations en tout cas, pour le peu que j'ai pu regarder c'est du bon boulot, il n'est pas impossible que j'essaye de m'investir mais je manque un peu de temps libre pour l'instant.

        Merci.
      • [^] # Re: Par curiosité

        Posté par  . Évalué à 8.

        drupalfr.org, ça ne serait pas une redirection de DLFP qui remplace Templeet par Drupal, Microsoft par SPIP et Apple par Wordpress ?

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Par curiosité

        Posté par  (site web personnel) . Évalué à 0.

        > (et encore aujourd'hui, les CMS en Rails, ce n'est pas vraiment ça).

        il y a Foregeos : http://www.forgeos.com et le code sur github https://github.com/webpulser/forgeos_cms
        • [^] # Re: Par curiosité

          Posté par  (site web personnel) . Évalué à 2.

          Oui, il y a en a beaucoup, mais aucun ne sort du lot.

          Si on prend l'exemple de Forgeos, il sert à faire des sites statiques (pas de notions d'utilisateurs, seuls les admins peuvent écrire des contenus), il n'est pas maintenu (pas de commit depuis plusieurs mois), le code fait peur à voir.

          Pour les sites statiques, je recommande plutôt d'aller voir Locomotive : http://www.locomotiveapp.org/.
          • [^] # radiantcms

            Posté par  . Évalué à 2.

            Un autre cms sympa en RoR est radiantCMS(http://radiantcms.org/). Sans doute un des CMS les plus configurables (ce qui est à la fois un avantage et un inconvénient selon ce que l'on recherche) et très bien maintenu. Son principe est de ne faire que le strict minimum pour un cms mais de le faire bien. La communauté est très active. Il y a des webcasts très bien foutu montrant comment l'exploiter(http://radiantcms.org/) .

            Par contre, il a le même défaut que tu as énoncé pour jumla mais en plus prononcé : il est indispensable d'utiliser les extensions pour pouvoir faire un site et donc on prend un risque sur la pérennité des extensions...
            • [^] # Re: radiantcms

              Posté par  (site web personnel) . Évalué à 2.

              Je connais bien RadiantCMS. Il est utilisé par Ruby France et ruby-lang.org, 2 sites où il m'arrive d'écrire du contenu.

              Ça marche pas mal, mais je ne suis pas fan de la manière dont il organise le contenu. L'interface d'administration est aussi assez mal foutue à mon goût. Par exemple, sur ruby-lang.org, il faut s'armer de patience si on veut éditer une des news anglaises car il y en a beaucoup, que l'interface peut mettre plusieurs minutes à se charger et que la navigation n'est pas optimale.
  • # Tribune

    Posté par  . Évalué à 9.

    Deux questions :
    - Pourquoi faut il obligatoirement s'authentifier pour aller sur la tribune ?
    - Quelle est l'url du backend de la tribune ?
  • # Bravo

    Posté par  . Évalué à 10.

    Tu a réussi a faire un truc encore plus moche qu'avant, pourtant c'était pas gagné d'avance.
    • [^] # Re: Bravo

      Posté par  (site web personnel) . Évalué à 5.

      C'est vrai que c'est moche, et je dirais même que c'est normal pour une version de développement. Il faut juste porter les thèmes courants (ou en créer d'autres) une fois que tout est fini et qu'on est sûr que les modèles ne changeront pas trop.
      • [^] # Re: Bravo

        Posté par  (site web personnel, Mastodon) . Évalué à 5.

        D'où la présence du concours : http://linuxfr.org/2010/11/09/27372.html
        • [^] # Re: Bravo

          Posté par  . Évalué à 3.

          Ahah, rooooooh si on peut plus rigoler :p
        • [^] # Re: Bravo

          Posté par  (site web personnel) . Évalué à 10.

          D'ailleurs c'est tellement moche que personne n'est démotivé pour le concours. Il n'est pas possible de faire pire.
          • [^] # Re: Bravo

            Posté par  . Évalué à 10.

            Je trouve le nouveau site tellement laid, tellement vilain que j'ai cru au début que c'était un de mes sites. C'est dire.
            • [^] # Re: Bravo

              Posté par  . Évalué à 7.

              Les blocs de code en jaune fluo, ca pique les yeux !
          • [^] # Re: Bravo

            Posté par  . Évalué à 2.

            C'est pas ce que disaient les gens du site web de Debian avant de commetre la nouvelle version en travaux ?

            BeOS le faisait il y a 20 ans !

    • [^] # Re: Bravo

      Posté par  . Évalué à 8.

      C'est marrant, j'ai moinser ce commentaire. Puis je suis allé voir le site béta... désormais je m'en veux d'avoir moinser :D
    • [^] # Re: Bravo

      Posté par  . Évalué à 3.

      C'est tout bugé sur seamonkey 1.1.8.
      C'est compatible qu'avec les navigateurs récents ?

      Le rendu n'est pas le même avec ou sans javascript sur un firefox récent.

      PS : pour créer un bug report sur github, il faut un compte. C'est lourd...
      • [^] # Re: Bravo

        Posté par  . Évalué à 1.

        Je pense qu'il utilise HTML 5.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Bravo

      Posté par  . Évalué à 5.

      Moche ? pas vraiment.
      Ça fait plutôt interface à la FisherPrice ou pour les mal voyants.
    • [^] # Re: Bravo

      Posté par  (site web personnel) . Évalué à 6.

      Le design actuel du site est très bien.

      Justement, il sait se faire oublier, et c'est une des principal règle ne matière de design web : marquer l'identité du site, présenter une ergonomie actualisée, rester le plus neutre possible pour éviter le plus possible toute réaction de rejet due au design.
  • # expressivité

    Posté par  . Évalué à 9.

    il n'est plus possible d'utiliser le soulignement et les textes barré, ce qui permettait plus d'expressivité dans les commentaires. Il n'y a pas moyen d'utiliser l'ancienne version voire du html direct plutôt que markdown ? Ou alors d'utiliser des syntaxes wiki plus complètes, genre creole ?

    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: expressivité

      Posté par  (site web personnel) . Évalué à 10.

      Ni les listes. Il manque < ul > dirait les moules :)

      L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

      • [^] # Re: expressivité

        Posté par  (site web personnel) . Évalué à 3.

        Ah si les listes (numérotées ou pas) c'est possible.
        • [^] # Re: expressivité

          Posté par  (site web personnel) . Évalué à 4.

          Ah oui mais c'est pas dispo dans la toolbar. C'est dommage.

          L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: expressivité

      Posté par  (site web personnel) . Évalué à 5.

      Je ne souhaite pas qu'il y ait plusieurs syntaxes wiki sur le nouveau site. C'est plus compliqué techniquement et surtout, ça ne va pas être pratique du tout pour les relecteurs qui vont devoir éditer des dépêches dans différentes syntaxes.

      Je n'ai pas non plus envie de laisser les gens éditer du HTML. Pour avoir passé pas mal de temps à examiner les contenus pour les importer dans la version RoR, on a une quantité assez impressionnante d'HTML non valide. Il y a des gens qui ne savent pas écrire du HTML et qui font donc ce qu'ils peuvent. Mais la plus grande source d'erreurs vient de typos : un guillemet au mauvais endroit sur un attribut href, une balise fermante , des balises pas fermées, fermées deux fois, mal fermées, fermées mais pas ouvertes, des balises ; la liste est longue.

      Maintenant, sur le choix de la syntaxe wiki, je préfère la syntaxe creole. C'était même elle qui était utilisée aux débuts de la version RoR. Mais quand les AMR ont découvert la première version, ils ont été relativement d'accord pour dire que la syntaxe creole n'est pas assez connue et qu'il faudrait utiliser une syntaxe plus populaire.

      J'ai tenu un temps puis je me suis rangé à leur avis au début de l'année (janvier ou février). Il y a une discussion, qui a tourné au vote entre markdown et mediawiki. Au final, markdown a gagné d'une voix (quelque chose comme 10 à 9).
      • [^] # Re: expressivité

        Posté par  . Évalué à 6.

        c'est vraiment bête que je n'ai pas vu cette discussion, car j'aurais carrément voté contre markdown pour creole, qui est plus raisonné et permet beaucoup plus de possibilités.

        "Pas assez connu". Il y a beaucoup de projets de qualités qui sont évincé justement à cause de ça. Il y a aussi le coup de "on ne développe pas ce programme sous linux parce que ce n'est pas assez connu par rapport à windows".

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: expressivité

          Posté par  . Évalué à 8.

          et tant que j'y suis, plutôt que de faire des sondages sur la taille du sgueg de l'indentation des espaces, sur les habitudes de microblog ou sur ce qu'on préfère boire quand on a trop chaud, ça aurait peut-être été mieux de faire un sondage sur ce que les gens préfèrent avoir comme syntaxe wiki (d'un autre côté, c'est possible aussi que cela soit "le plus connu" qui aurait gagné)

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

          • [^] # Re: expressivité

            Posté par  . Évalué à 3.

            j'ai oublié la fin de la phrase, je voulais dire "ce que les gens préfèrent avoir comme syntaxe wiki pour la nouvelle version de linuxfr'.

            Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

            • [^] # Re: expressivité

              Posté par  (Mastodon) . Évalué à 2.

              quelque soit la syntaxe wiki, tant qu'elle convient à patrick_g à vous :)
              • [^] # Re: expressivité

                Posté par  (site web personnel) . Évalué à 5.

                Quelle que soit la syntaxe moi je fais toujours des tonnes d'erreurs de balises et ce sont les relecteurs qui se tapent du boulot derrière pour réparer :-(

                Enfin on verra bien comme ça se passe pour la prochaine news noyau. Je me suis fait mon template markdown, j'ai la coloration syntaxique markdown dans Gedit. Je suis paré !
                • [^] # Re: expressivité

                  Posté par  . Évalué à 3.

                  Les nouvelles possibilités devraient vraiment améliorer la lisibilité des grosses dépêches comme celles du noyau (pouvoir vraiment hiérarchiser l'information), mais je n'ai pas vu dans markdown comment reproduire la table des matières que tu utilise d'habitude.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: expressivité

                    Posté par  (site web personnel) . Évalué à 1.

                    C'est sur que sans table des matières, cela va être plus lisible ;-)
                  • [^] # Re: expressivité

                    Posté par  (site web personnel) . Évalué à 4.

                    Markdown ne propose rien pour faire ça de base. Par contre, l'implémentation de markdown utilisé ici (discount) permet de faire ça. Toutes les dépêches assez longues auront automatiquement une table des matières sans que l'auteur n'ait rien à faire.
      • [^] # Re: expressivité

        Posté par  (site web personnel) . Évalué à 5.

        Bin faut pas accepter le HTML utilisateur tel quel et il faut le passer à la moulinette pour fermer les tags manquantes et virer ce qui faut pas afin d'obtenir un truc valide.

        Sinon pour la syntaxe wiki, le jour où vous allez migrer sur un autre truc, ça va pas être galère ? Et la migration de l'existant actuel en syntaxe wiki ça donne quoi ? J'ose pas imaginer les scripts de migration.

        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

      • [^] # Re: expressivité

        Posté par  (site web personnel) . Évalué à 2.

        Voilà un exemple de ce que cela donne quand on laisse des gens éditer du HTML : http://validator.w3.org/check?uri=http%3A%2F%2Flinuxfr.org%2(...) (si un modéro en a le courage, ce serait bien de corriger).
        • [^] # Re: expressivité

          Posté par  . Évalué à 3.

          ça n'a rien à voir, ce sont des exemples avec des lettres clés en html qui bloquent (&, < etc), c'est pas trop étonnant d'avoir ça.

          Et avec templet, c'est pas du vrai html, c'est redigéré par la suite, pour la dépêche j'ai dû bidouiller pour que ça s'affiche à peu près correctement. Je dis juste ça au cas où tu aurais insinué que l'export html de txt2tags ne valide pas en temps normal.

          et juste comme ça, la page d'accueil de la beta ne valide pas non plus (oui, c'est le contenu d'un journal qui donne une des erreurs, comme quoi...)

          http://validator.w3.org/check?uri=http%3A%2F%2Falpha.linuxfr(...)

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

          • [^] # Re: expressivité

            Posté par  (site web personnel) . Évalué à 2.

            hmmm il y avait tout de même cette erreur :
            Line 239, Column 6: character data is not allowed here

            </li>Nouveau nom de domaine txt2tags.org et nouveau wiki pour échanger des rece…

            j'avais déjà remarqué que la gestion de l'ullification ne semblait pas complète dans tes dépêches générées avec txt2tag, mais je ne sais pas si c'est la sortie directe ou l'édition ultérieurement faite qui en était la cause ;-)

            (bon après pour les &lt; et autres &amp; ou &nbsp; c'est un peu la grouillle dans templeet)
            • [^] # Re: expressivité

              Posté par  . Évalué à 2.

              l'ullification fonctionne bien, c'est parce qu'on est obligé de tout remodifier après génération du document html (ou en utilisant un filtre, ce que j'ai fait dans cette dernière version), sinon ça saute une ligne à chaque fois entre chaque li à cause de templeet

              Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

              • [^] # Re: expressivité

                Posté par  (site web personnel) . Évalué à 2.

                Pourrais-tu envoyer un exemple de sortie ? je crois me rappeller du manque de <ul> de temps en temps ou de </li>, ce qui ne s'explique pas par des CR surnuméraires supprimés. Le plus simple serait d'avoir une sortie dédiée linuxfr comme je l'avais fait sur http://demoll.tuxfamily.org/linuxfr/NewsLinuxFr
                par exemple http://demoll.tuxfamily.org/linuxfr/NewsGagnantsSeptembre201(...) avec http://demoll.tuxfamily.org/linuxfr/NewsGagnantsSeptembre201(...)
                • [^] # Re: expressivité

                  Posté par  . Évalué à 2.

                  un exemple de sortie : http://textallion.googlecode.com/hg/samples/presentation.htm(...)

                  Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

                • [^] # Re: expressivité

                  Posté par  . Évalué à 2.

                  Plutôt que de générer du « linuxfr », il serait plus pérenne de générer du markdown je pense, non ?

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: expressivité

                    Posté par  (site web personnel) . Évalué à 2.

                    Ce site n'est pas pérenne, c'est simplement une facilité pour travailler à plusieurs sur des dépêches. Bon ok, j'utilise un wiki depuis au moins 2005 et j'avais je crois ajouté cette fonctionnalité de conversion vers la "syntaxe" linuxfr au wiki vers fin 2007, mais bon...;-)

                    J'espère que le wiki intégré à la nouvelle version nous permettra d'effectuer du travail collaboratif sur des dépêches, il y a une organisation à trouver et ajouter un lien "transformer en dépêche" en gardant les auteurs initiaux ;-) Cela mériterait des compléments à http://linuxfr.org/tracker/879.html voire ouvrir une nouvelle suggestion :) (il y avait bien eu une proposition "d'inviter" le rédacteur en tant que relecteur pour compléments - je ne l'ai pas retrouvée :/ - même si je crois plus au mode de fonctionnement "à la Firehose" de /. ou à la conversion de journaux en dépêches comme nous faisons déjà, avec plus ou moins de bonheur).
                  • [^] # Re: expressivité

                    Posté par  . Évalué à 2.

                    la version svn de txt2tags permet maintenant de générer du markdown, la cible s'appelle "md".

                    http://txt2tags.googlecode.com/svn-history/r418/trunk/sample(...)

                    Ça semble pas mal fonctionner en mode "markdown extra" ici :
                    http://michelf.com/projets/php-markdown/banc-d%27essai/

                    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

                    • [^] # Re: expressivité

                      Posté par  (site web personnel) . Évalué à 3.

                      Dans ikiwiki, l'extension pour le markdown est le mdwn, c'est peut être plus parlant que juste md.
                      • [^] # Re: expressivité

                        Posté par  . Évalué à 2.

                        c'est vrai que c'est plus parlant, j'avais mis mdwn au début, et ça a été modifié sur le svn depuis.

                        Est-ce que vous auriez une référence indiquant ce qui est préféré ? La plupart des discussions que j'ai vu indiquent les 2 à égalité.

                        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: expressivité

      Posté par  . Évalué à 2.

      Tu peux insérer directement du html dans du markdown normalement. Certaines implémentations de markdown étendent la syntaxe de base (pandoc, discount, php-markdown et peut-être d'autres que je ne connais pas) et ajoutent tout spécialement la possibilité de créer des tableaux moins reloutement qu'en html (à la txt2tags en fait) mais plus rarement le souligné ou barré.

      Quelle implémentation de markdown est utilisée au fait?
  • # Supair

    Posté par  . Évalué à 6.

    J'ai installé la version de développement avant-hier, dans le but de voir ce que je pouvais faire du cotés du design. J'aime bien faire des choses inutiles :D

    Le concours me motive encore plus :-)

    Au passage, ça faite une belle liste de dépendances, je vous souhaite bien du courage pour la maintenance.

    Envoyé depuis mon lapin.

  • # soit dit en passant

    Posté par  (site web personnel) . Évalué à 10.

    Suis très content qu'une nouvelle version arrive ...
    Suis curieux de voir la suite ...

    Mais ... pour être une vielle moule de dlfp. Je me rappel des trolls de l'époque. Quand fabien défendait son templeet, et son design, justement optimiser pour faire face aux surcharges ...

    Et là, faire ça en RoR, qui n'est justement pas réputé pour tenir la montée en charge (tweeter et sa baleine). (après il suffit de rajouter des machines ;-)
    Je suis dubitatif.

    Suis curieux de voir quand tout le monde, et les milliers de robots s'acharneront sur dlfp en live, aux heures de pointes.
    • [^] # Re: soit dit en passant

      Posté par  . Évalué à 7.

      Boarf, ils suffira de louer des serveurs virtuels aux heures de pointe.

      Qu'est-ce que c'est beau le cloud computing. Nan jrigole…

      Envoyé depuis mon lapin.

    • [^] # Re: soit dit en passant

      Posté par  . Évalué à 3.

      > Je me rappelle des trolls de l'époque. Quand Fabien défendait son
      > templeet, et son design, justement optimisé pour faire face aux
      > surcharges ...
      > Et là, faire ça en RoR, qui n'est justement pas réputé pour tenir la
      > montée en charge (tweeter et sa baleine). (après il suffit de rajouter
      > des machines ;-)

      Justement, l'assoce a changé (deux fois ? Je ne sais plus) de serveur grâce à la générosité d'un paquet de monde, depuis l'époque où Fabien bossait sur Templeet. Loi de Moore aidant, la capacité du serveur à absorber la charge est probablement est moins un problème, d'autant que le traffic reste stable si ma mémoire est bonne.
      • [^] # Re: soit dit en passant

        Posté par  (site web personnel) . Évalué à 2.

        oui, mais le "nb de serveurs actuels" ne pourra peut être pas héberger un RoR en lieu et place du templeet actuel ...
        (c'est ce que je voulais dire, en qq sorte)

        il faudra peut être donner plus, pour acquérir plus (de serveurs)
        • [^] # Re: soit dit en passant

          Posté par  . Évalué à 4.

          Oui enfin faut revenir sur terre comparer la charge de linuxfr et de tweeter ;)
    • [^] # Re: soit dit en passant

      Posté par  (Mastodon) . Évalué à 5.

      Et là, faire ça en RoR, qui n'est justement pas réputé pour tenir la montée en charge (tweeter et sa baleine).

      Ça permet de vendre des goodies : http://blog.makezine.com/archive/2010/11/fail_whale_hat.html
      • [^] # Re: soit dit en passant

        Posté par  . Évalué à 2.

        L'asso' va devenir riche ! À quand les bureaux DLFP dans un immeuble de la défense ?

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # L'icone ?

    Posté par  (Mastodon) . Évalué à 9.

    Peut-être changer la favicon pour mieux distinguer les deux versions quand on a 42 onglets ?
  • # Typos trop grandes

    Posté par  (site web personnel) . Évalué à 3.

    Moi j'aimais bien les petits typos (comme actuellement). Je supporte pas les gros caractères... :(
  • # webalizer

    Posté par  (site web personnel) . Évalué à 7.

    Pour info je suis en contact avec le mainteneur debian de webalizer (c'est un monsieur très occupé) et j'ai déjà un package dans un coin. Je peux éventuellement faire un peu de ménage et le mettre à dispo sur mon site.

    De toute façon vu que debian est en freeze il faudra attendre la release pour que ça sorte dans unstable avant d'envisager un backport pour stable.

    Une question: est-ce que vous utiliser le script track_hist pour construire un historique de plus d'un an ? par-ce-que ce truc relève plus du hack que d'autre chose et j'aimerais bien le virer !
    Donc si personne ne s'en sert ça m'arrangerait ;)
    • [^] # Re: webalizer

      Posté par  (site web personnel) . Évalué à 4.

      Chouette.

      On n'utilise pas webalizer sur plus d'un an. Pas d'utilisation de track_hist. On utilise juste jdresolve avec webalizer pour avoir une base de données des résolutions DNS.

      Merci d'avance.
  • # Question

    Posté par  . Évalué à 3.

    Ce n'est pas un bug mais je me posais cette question: est-il possible que le retour en arrière dans l'historique du navigateur soit annihilé d'une manière ou d'une autre lorsqu'on a posté un commentaire?
    Sous templet, ça aurait évité moult doublons.

    Sinon, bravo pour le boulot. C'est moche mais bravo.
    Ça va remuer un peu le bouchot.
    • [^] # Re: Question

      Posté par  (site web personnel) . Évalué à 5.

      > Ce n'est pas un bug mais je me posais cette question: est-il possible que le retour en arrière dans l'historique du navigateur soit annihilé d'une manière ou d'une autre lorsqu'on a posté un commentaire ?

      Je ne suis pas sûr de comprendre ce que tu veux dire par "annihiler le retour arrière", mais si tu postes un contenu puis que tu appuies sur le bouton retour arrière, le contenu ne sera pas reposté. Rien de bien magique, j'utilise la bonne vieille technique que l'on appelle parfois Post-Redirect-Get.
  • # Vous pensiez y échapper...

    Posté par  . Évalué à 7.

    Et bien non ! La CSS opensuse est déjà disponible pour linuxfr on ruby on rails :
    [http://bmo-perso.pagesperso-orange.fr/linuxfr/alpha/opensuse(...)]

    C'est pas encore tout à fait fini donc si vous voyez des défauts, n'hésitez pas à me les signaler.

    Par contre, je viens d'essayer et je n'arrive plus à changer de css, un bug ? ça marchait pourtant ça...
  • # Bravo Bruno!

    Posté par  . Évalué à 10.

    Bravo a toi Bruno, c'est un super boulot!

    C'est aussi une super idée le concours de design, comme ca ca évitera trop de décollements rétiniens aux moules francophones ^_^
  • # karma

    Posté par  (site web personnel) . Évalué à 10.

    Je ne vais pas crier à l'injustice mais mes 20 avis passent à 5 sur la nouvelle version. J'imagine donc que le système de karma a été revu en profondeur.

    Qu'en est-il exactement ?
    • [^] # Re: karma

      Posté par  . Évalué à 2.

      Peut-être que tu n'avais que 5 avis au moment de la copie de la BDD ?

      Un point important à savoir est que les deux versions utilisent des bases de données séparées et qui ne seront pas resynchronisées.
      • [^] # Re: karma

        Posté par  (site web personnel) . Évalué à 4.

        non non, moi ça fait un bout de temps que j'ai plus de 30 avis à donner et je suis aussi tombé à 5.
    • [^] # Re: karma

      Posté par  (site web personnel) . Évalué à 2.

      Oui, le système de karma a été simplifié.

      Ce que l'on appelle le karma sur la version templeet correspond généralement aux XP, un score qui évolue à coup de + ou de- au fil du temps (exemple : une personne dont la dépêche est acceptée gagne 50XP). Mais parfois, ça sert aussi à désigner la note moyenne des commentaires sur 15 derniers jours (exemple : tu n'as pas assez de karma pour poster un journal).

      Au final, les règles sont compliquées et même nous, admins, ne sommes pas sûrs de toujours comprendre comment cela fonctionne (en fait, pour ma part, je suis même de ne pas tout y comprendre).

      Du coup, le système a été refait mais il va me falloir du temps pour l'ajuster.
  • # Acces mobile

    Posté par  . Évalué à 9.

    Bonjour,

    Un truc qui serait chouette c'est d'avoir un accès conçu pour les mobiles quand on moule depuis la boulangerie.

    Actuellement les bandeaux sont verticaux et il n'y a que peux de place sur un mobile (Iphone, Blackberry, etc).

    J'aimerais beaucoup pouvoir afficher la page et pouvoir accéder aux dépêches (en entier!) et aux journaux et pouvoir afficher les commentaires si j'en ai envie.

    C'est prevu un truc adapte aux résolutions <480px ?

    Polytan
    • [^] # Re: Acces mobile

      Posté par  (site web personnel) . Évalué à 5.

      Va falloir utiliser les propriétés de CSS3 kivonbien pour faire ça.

      L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: Acces mobile

      Posté par  . Évalué à 2.

      ouai faudra porter la CSS N97 car je l'utilise actuellement dans 90% des cas (oui j'ai bcp de train!)
  • # HTML 5?

    Posté par  . Évalué à 1.

    On peut lire un peu partout que le W3C insiste sur le fait que HTML5 est à l'état de draft et pas prêt pour la production.
    Qu'est-ce qui vous a motivé à franchir le pas?
    • [^] # Re: HTML 5?

      Posté par  (site web personnel) . Évalué à 8.

      > On peut lire un peu partout que le W3C insiste sur le fait que HTML5 est à l'état de draft et pas prêt pour la production.

      Oui et non, la position du W3C est plus élaborée que ça. Par exemple, à Paris Web, 2 membres du W3C ont fait une présentation autour d'HTML5 et nous ont encouragés à nous y mettre.

      La spec est encore en draft pour un certain temps, mais la spec couvre énormément de choses dont certaines sont déjà très matures et utilisables. Dans certains cas, la spec HTML5 est même beaucoup plus proche du fonctionnement des navigateurs existants que les précédentes specs, car les navigateurs ne faisaient pas ce qui est écrit dans HTML 4 ou XHTML (pour de bonnes raisons) et HTML5 est venu documenter cet état de fait.

      D'autres parties sont plus récentes mais se dégradent très bien (HTML5 forms par exemple).

      Enfin, il y a des parties à éviter car elles ne sont pas implémentées dans les navigateurs actuels et ne se dégradent pas bien (un exemple : les attributs sandbox et seamless des iframes).

      > Qu'est-ce qui vous a motivé à franchir le pas ?

      Il y a déjà plein de choses que l'on peut utiliser dans HTML5 sans problème et qui sont de réelles avancées. Ce serait vraiment dommage de s'en priver.
  • # Félicitations et bon courage

    Posté par  (site web personnel) . Évalué à 2.

    Salut,

    Refaire un site from scratch est assimilable à de la folie ou à la possession d'une bonne paire de co.... oudes.

    Bon courage, pour cette migration vers RoR, c'est bien parti en tout cas pour être une réussite.

    Tchuss

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.