Publish It Yourself : un nouveau CMS "autogéré"

Posté par  (site web personnel) . Modéré par patrick_g.
Étiquettes :
13
28
sept.
2009
PHP
Croisement entre les Digg-likes et les systèmes de publication ouverte tels qu'utilisés par le réseau Indymedia, Publish It Yourself est une application web conçue pour propulser des sites communautaires où les utilisateurs créent et gèrent eux-même le contenu.

Les utilisateurs, enregistrés ou non, peuvent publier sur le site des articles riches (images, vidéos, son, HTML). Ceux ayant un compte décident via un système de vote lesquels iront en première page.

Cette toute première version publique dispose entre-autre d'un système de commentaires (avec support des Gravatars), d'un classement des articles par tags (avec support des triple tags), d'une protection anti-spam, d'un système de thèmes, d'une interface traduisible, de pages personnelles pour les utilisateurs enregistrés prenant la forme de blogs, et de flux Atom.
Un soin particulier a été porté sur l'optimisation de l'application pour que les pages qu'elle génère soient bien référencées : urls expressives, titres uniques, microformats, ...

Publish It Yourself est distribué sous licence AGPL v3. Publish It Yourself est écrit en PHP à l'aide du framework symfony. Le code Javascript utilise jQuery et l'affreux thème de base (avis aux graphistes...) est compatible (x)HTML_5.

Ce n'est que le tout début du cycle de développement de ce logiciel et il contient probablement de nombreux bugs. Si vous en découvrez, merci de les reporter !
Une démonstration est en-ligne, les sources sont disponibles via la page GitHub du projet.
Les contributions sont toujours les bienvenues !

Par la suite, les fonctionnalités qui viendront sont un moteur de recherche interne, le support de la géolocalisation et d'un calendrier pour les articles qui s'y prêtent, ainsi que l'arrivée d'une interface d'administration minimaliste pour que les éditeurs des communautés puissent supprimer du contenu (ex : article manifestement illégal mettant en jeu la responsabilité de l'hébergeur).

Pour la petite histoire, son nom est un clin d'oeil au mouvement Do_It_Yourself.

Aller plus loin

  • # Quelques remarques

    Posté par  . Évalué à 3.

    Je n'ai pas pu beaucoup testé car je suis sur une machine qui rame sévère (même pour une bête page HTML). Je commenterais donc deux petites bricoles...

    Je me disais juste que c'était dommage d'avoir utilisé des tableaux juste pour le formulaire de connexion, ce ne sont pas des données tabulaires affichées :(

    Sinon, pour les dates, quitte à utiliser (X)HTML5 autant utiliser l'élément [time] plutôt qu'[abbr].

    • [^] # Re: Quelques remarques

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

      Tu as raison pour les tableaux. Pour l'instant c'est la sortie par défaut du framework de formulaire de symfony qui est utilisée... et elle génère des tableaux. Une sortie liste est également disponible, je ferais la bascule prochainement !

      Le remplacement de abbr par time est plus problématique. La spécification du format hAtom n'a pas encore était mise à jour afin de permettre l'utilisation de cet élément en lieu et place du date-time design pattern. Il semblerait que ça va arriver... mais en attendant j'ai bien peur que certains moteurs de recherche sachant tirer partie des microformats (Yahoo! BOSS en particulier) ne soient plus à même de le faire suite à ce changement.

    • [^] # Re: Quelques remarques

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

      En quoi un formulaire de connexion n'est pas une donnée tabulaire. Pour moi c'en est. Une liste de couple nom/valeur.

  • # bonne idée

    Posté par  . Évalué à 1.

    ça fait un petit moment que j'ai moi aussi cette idée en tête, mais pourquoi diable avoir utilisé propel ??

    • [^] # Re: bonne idée

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

      Parce-que ça simplifier le développement, quelques plugins symfony utilisés par ce projet sont en fait des "Propel behaviors" dont les équivalents pour Doctrine n'ont pas encore toutes les fonctionnalités.
      Également parce-que quand j'ai commencé ce projet, Doctrine n'était pas encore l'ORM par défaut de symfony (il ne l'est toujours pas mais ça arrive) et avait de gros problèmes de performances face à Propel.

      • [^] # Re: bonne idée

        Posté par  . Évalué à 1.

        La plupart des plugins symfony sont une blague et inutilisables en prod, d'ailleurs doctrine me semble bien plus complet en ce qui concerne les behaviors (nested sets entre autre...)

        Pour avoir utilisé les 2 (propel de la 0.6 de sf jusqu'à la 1.0) & doctrine depuis la 1.1, je peux te dire que jamais je ne reviendrai à propel, la syntaxe est ignoble, on a facilement 20 à 30 lignes de code supplémentaires pour une même query réalisée avec doctrine et les possibilité sont bien en deça...

        en ce qui concerne les performances, tout vas bien depuis longtemps (si on n'envoie pas la collection d'objets directement à la vue évidemment...)

Suivre le flux des commentaires

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