Journal Envie de pomper?

Posté par plagiats le 01 janvier 2005 à 16:49.

Étiquettes : aucune

jan.

2005

http://www.pompage.net/(...) est un site francophone de ressources pour un web propre.

Sa formule vient de changer, et ca claque: Alors qu'il s'agissait de la parution mensuelle d'une traduction d'articles sur les standards, maintenant pompage s'annonce comme une centralisation des articles (également traduits ailleurs).

Les articles seront publiés "au fil de l'eau" comme l'annonce pompage, avec pour objectif de "publier plus souvent!". Le site est magnifique, très professionnels, que du bon.

Je n'aurais que deux reproches à adresser à la nouvelle version du site:

Elle ne passe pas au validateur (et ca, ca fait tâche):
http://validator.w3.org/check?verbose=1&uri=http%3A//www.pompag(...)

Dans la partie contact, il n'y a pas d'indication sur un éventuel chan irc ou une adresse e-mail (pour ceux qui ne veulent pas passer par le formulaire).

En tout cas, bravo pompage, et merci!

Un pompage, des plagiats.

# pas de validation, mais...

Posté par Beurt le 01 janvier 2005 à 17:23. Évalué à 6.

1. Elle ne passe pas au validateur (et ca, ca fait tâche):
http://validator.w3.org/check?verbose=1&uri=http%3A//www.pompag(...))

Je pense que c'est dû à l'utilisation de Spip qui produit du code qui n'est pas valide XHTML (seulement HTML 4.01 transitionnal, et encore pas toujours toujours...).

Toutefois, je me faisais la remarque que pour un site sous Spip, c'est assez exemplaire: liens intelligibles (pas sous forme de requête php du type truc.php3?id_article=42), et code plutôt propre (à vue de nez, le validateur dit autre chose).
Si les auteurs passent par ici j'aimerai bien savoir quels filtres/fonctions/add-ons/manips et même éventuellement patches ils ont appliqués à Spip pour obtenir ce joli résultat.
- [^] # Re: pas de validation, mais...
  
  Posté par Maillequeule le 01 janvier 2005 à 19:17. Évalué à 6.
  
  Cela ressemble à la fonctionnalité "URL propres" de la prochaine version de Spip (1.8), mais avec une variante ... (tout est dossier, et non pas fichier).
  
  Plus de détails ici sur le Spikini (l'extension Wiki pour Spip) :
  http://lab.spip.net/spikini/UrlsPropres(...)
  
  Et une mise en oeuvre ici :
  http://www.libroscope.org/(...)
  
  J'ajoute la liste des nouveautés de la version 1.8 :
  http://lab.spip.net/spikini/ListeDesNouveautes(...)
  
  Ca fait déjà pas mal de lecture :)
  
  M
  - [^] # Re: pas de validation, mais...
    
    Posté par Beurt le 01 janvier 2005 à 19:53. Évalué à 4.
    
    Merci !
    Mais justement ce n'est pas cette option URL propre-là. Sans doute l'un des autres systèmes proposés sur spip-contrib (mais lequel ?).
    Pour ce qui est du HTML plus propre, je m'étais demandé s'ils n'utilisaient pas la beta de Spip 1.8 qui promet des balises fermées et plus sémantiques (strong à la place de b, etc...).
    D'ailleurs, Spip 1.8 promet vraiment ! (sauf l'aspect de la nouvelle interface privée qui si elle est pratique devient vraiment moche. Voir Spip-contrib qui fonctionne avec la beta de spip pour ceux qui seraient intéressés.). Mais à la vue du code, il y a sans doute un filtre en plus (à moins que les articles soient stockés en HTML...).
    - [^] # Re: pas de validation, mais...
      
      Posté par Stéphane Deschamps (site web personnel) le 03 janvier 2005 à 10:30. Évalué à 4.
      
      Mais justement ce n'est pas cette option URL propre-là. Sans doute l'un des autres systèmes proposés sur spip-contrib (mais lequel ?).
      C'est du fait-maison, assez simple. Je dois encore écrire la doc... En gros c'est une RewriteRule basée sur un champ extra de spip, et del'autre côté une fonction generer-urls spécifique.
      Pour ce qui est du HTML plus propre, je m'étais demandé s'ils n'utilisaient pas la beta de Spip 1.8 qui promet des balises fermées et plus sémantiques (strong à la place de b, etc...).
      Là encore, on a fait simple : le HTML nécessaire est tellement complexe qu'aucun CMS ne pourrait le livrer sans le taper. C'est donc ce qu'on fait du HTML standard qu'on restitue sans conversions, en entourant dans l'admin de SPIP chacun de nos articles des balises <HTML> et </HTML>.
      Mais à la vue du code, il y a sans doute un filtre en plus (à moins que les articles soient stockés en HTML...).
      Gagné :)
- [^] # Re: pas de validation, mais...
  
  Posté par Ramso le 01 janvier 2005 à 19:59. Évalué à -2.
  
  > Je pense que c'est dû à l'utilisation de Spip qui produit du code qui
  > n'est pas valide XHTML
  
  Tiens il y a besoin de faire du XHTML maintenant pour passer au validateur ?
  
  De toute façon, ces attaques gratuites contre Spip sont mesquines. Si l'interface par défaut ne vous plaît pas, changez-en. Ce n'est pas la peine de rabacher un vieux troll pour rabaisser ce pauvre Spip. La gueule des URL ensuite est un problème de PHP qui se règle avec Apache.
  - [^] # Tu devrais garder ton calme
    
    Posté par Beurt le 01 janvier 2005 à 20:31. Évalué à 7.
    
    Désolé de t'avoir mis en colère, mais le troll vient de toi.
    
    Je ne rabaisse pas Spip, c'est au contraire une application que j'apprécie beaucoup. Je ne vois pas pourquoi cela m'empêcherait d'en pointer les défauts.
    
    Dans la version 1.7.2 (stable) de Spip, la validation HTML 4.01 n'est pas systématique (notamment à cause d'un problème -connu- de balises qui ne sont pas fermées). Et ne peut valider le XHTML (ce qui est dommage pour un logiciel dans lequel tout le reste tend à séparer le fond de la forme).
    Spip me plaît, et il me plaira encore plus quand j'aurai trouvé un moyen de lui faire produire un code XHTML valide. C'est peut-être pour la version 1.8 (à voir...)
    
    Pour finir sur l'aspect des URL (pour lequel il y a aussi de l'évolution dans la version 1.8, voir le post de Maillequeule: http://linuxfr.org/comments/516050.html#516050(...)) cela peut-être corrigé par des manips au niveau d'Apache ou du .htacces, etc... (voir spip-contrib), mais ce serait plus pratique si s'était géré par Spip (d'ailleurs on a rarement la main sur le serveur de son hébergeur).
  - [^] # Re: pas de validation, mais...
    
    Posté par renaud le 03 janvier 2005 à 18:15. Évalué à 1.
    
    "La gueule des URL ensuite est un problème de PHP qui se règle avec Apache."
    
    Faux, enfin, pour avoir des URL vraiment propres, il faut faire abstraction des id des éléments : rubriques, articles. Pour avoir moi même fait un système de ce genre qui rendait ROOT/rubrique/[sous-rubrique/*]article, je peux te dire qu'il faut mettre les mains dans SPIP pour y arriver : je ne vois pas comment faire un vrai truc correct sans stocker des clés pour ces éléments, et donc modifier l'admin et la bdd.
    Bref, oui y'a RewriteRule, mais ce n'est pas suffisant.
    - [^] # Re: pas de validation, mais...
      
      Posté par Stéphane Deschamps (site web personnel) le 03 janvier 2005 à 23:25. Évalué à 0.
      
      Je te dis que je vais faire un article -- et que je n'ai pas touché au noyau de spip ni à la BDD.
      
      Simplement un champ extra et une rewrite rule vers une requête mysql vers ledit champ extra :)
      - [^] # Re: pas de validation, mais...
        
        Posté par renaud le 03 janvier 2005 à 23:49. Évalué à 1.
        
        Ben le champ extra, tu le stock bien ? Et comment tu le renseigne si tu touche pas à l'admin de SPIP ? Si c'est juste généré, ça me plait pas :)
        Ou peut-être que ces champs extra sont une fonctionnalité de spip ? En tout cas il n'y avait rien de tel sur ma version : une 1.6 à l'époque, je crois.
  - [^] # Re: pas de validation, mais...
    
    Posté par Mathieu Pillard (site web personnel) le 04 janvier 2005 à 01:02. Évalué à 2.
    
    La gueule des urls, ca peut aussi se regler avec PATH_INFO et autres directement en php. Ca permet de se passer de ce gros lourd de mod_rewrite, donc c'est rarement une bonne idée de au moins le proposer en option... C'est generalement plus flexible, plus leger, bref, parfait pour les petites faims!
    - [^] # Re: pas de validation, mais...
      
      Posté par renaud le 04 janvier 2005 à 02:21. Évalué à 2.
      
      Non, je ne suis pas d'accord. Oublions tout de suite les les serveurs Web non-apache où, effectivement, tu as raison.
      
      Pour les autres, il n'y a pas de raison d'utiliser PHP pour faire ça : Apache est déjà lancé, tourne, avec ses processus et son sac à main. Il est prêt, il est chaud, il n'attend qu'une chose, c'est qu'on lui demande de faire ce boulot qu'il réalise superbement, très vite (plus que PHP), avant lui et peut en profiter pour régler d'autres problèmes d'un coup. (tout ça pour peu qu'Apache soit bien configuré, mais c'est un autre problème, celui de l'hébergeur)
      
      Avec ta technique, tu va conserver le nom du script d'accès dans l'URL, ce qui n'est pas le but du jeu, ou alors, tu vas utiliser le directoryIndex, ce qui, soit te contraint à avoir ton accueil en PHP, soit à modifier les directives apache (tant qu'a faire...) D'ailleurs, est-ce que ça ne pose pas de problème dans ces cas là, au-dit apache ?
      
      mod_rewrite va te permettre de gérer les parties PHP et non-PHP de ton site d'un seul coup, ce qui n'est pas négligeable.
      
      Enfin, question : les pages de spip ne sont-elles pas misent en cache ? Si oui, je crois (mais je ne suis pas sur) que le cache stocke le contenu analysé (donc le rendu html) des pages. Ce système n'interfère-t-il pas avec le gain de vitesse que ce cache doit apporter ?
      
      voilà, je crois (je me trompe peut-être) des raisons d'utiliser mod_rewrite plutôt que PHP pour ça. Bien sûr, si mod_rewrite n'est pas disponible...
      - [^] # Re: pas de validation, mais...
        
        Posté par Mathieu Pillard (site web personnel) le 05 janvier 2005 à 13:21. Évalué à 2.
        
        Demande a des admins de sites mutualisés: mod_rewrite est une horreur, un monstre niveau ressources, et je ne parle meme pas des eventuels problemes de boucles dus a des rewrite foireux. C'est un outil incroyable qui fait le café, mais j'en connais qui n'ont qu'une envie, c'est que ca disparaisse de leur serveur vite fait :-)
# Mais si!

Posté par Tobu le 02 janvier 2005 à 02:07. Évalué à 3.

Ca valide; j'ai essayé quelques pages au hasard (la page de garde et des articles) et elles sont OK.
L'honneur est sauf.
- [^] # Re: Mais si!
  
  Posté par nicoprog le 02 janvier 2005 à 08:47. Évalué à 3.
  
  La page qui ne validait pas (lien du journal), ce valide maintenant :)
# Alors pompons !

Posté par kd le 02 janvier 2005 à 11:44. Évalué à 5.

J'allais régulièrement sur pompage.net pour y lire quelques articles. Et j'avoue que là, je trouve le site très joli.

Il n'est pas fréquent de trouver un site qui finalement n'est pas principalement d'une couleur. Ici, il y a du rouge, du bleu et du vert sur la même page, ce qui fait qu'on ne s'ennuie pas.

L'ancien design du site était monocolore, et la couleur choisie était le beige. Tout était beige marron, pas de blanc + gris + beige, mais beige + beige foncé + autres couleurs pour les fioritures. C'était beaucoup moins plaisant à lire. Et encore heureux que je ne déteste pas le beige !

Maintenant, c'est plutôt joyeux et léger à première vue mais tout en restant très agréable à lire.
# Yet another ZenGarden

Posté par Gabriel le 03 janvier 2005 à 01:07. Évalué à 5.

Juste pour signaler aux amoureux des css, xhtml et du zengarden un design qui n'est pas dans les designs officiels du celébrissime site:
Il s'appelle: "Geocities 1996". Il est ... mortel !
Pas (encore) dans la liste des designs officiels mais c'est bien un des meilleurs!! (avec, à mon avis, le no99, le 100, et qq autres bien sûr, dont un avec un couteau qui déchire la page et qui est à couper le souffle - mais j'ai plus le nombre)

http://zengarden.20megsfree.com/(...)

Les explications de l'auteur: http://brucelawson.co.uk/index.htm#garden(...)
- [^] # Re: Yet another ZenGarden
  
  Posté par gaston1024 le 03 janvier 2005 à 09:10. Évalué à 6.
  
  celui-ci est en effet très bon : http://www.csszengarden.com/?cssfile=/099/099.css&page=0(...)
  
  et voici le couteau en question :
  http://www.csszengarden.com/?cssfile=http://adjustafresh.com/zen/mo(...)

Suivre le flux des commentaires

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