L'objectif de SPIP reste toujours le même : proposer un moyen simple de créer un site web, tout en restant souple et très fonctionnel.
Parmi les principales nouveautés, on retrouve :
- un espace d'administration complètement refondu, sur le plan graphique et ergonomique,
- la prévisualisation d'un article avec les squelettes publics
- la gestion de l'historique des modifications dans un article
- un nouveau gestionnaire de documents attachés à un article ou une rubrique
- l'ajout de fonctionnalités intéressantes en mode client-serveur, par exemple un correcteur orthographique et un générateur LaTeX. Des serveurs d'analyse orthographique et de rendu LaTeX sont fournis par la communauté.
Mais aussi beaucoup de modifications qui seront moins évidentes pour l'utilisateur, comme par exemple le nouveau compilateur de squelettes qui gagne beaucoup en souplesse, des traductions mises à jour, et une meilleure conformité W3C.
La procédure de mise à jour est très simple, et fonctionne bien manifestement.
Un énorme bravo à toute l'équipe de développement de SPIP, qui nous apporte un outil très puissant, très souple mais aussi très simple d'utilisation.
Aller plus loin
- Annonce de la sortie (0 clic)
- Procédure de mise à jour (0 clic)
# c'est moi ou la procédure de mise à jour est pour le moins cavalière ?
Posté par Rodolphe Mosca (site web personnel) . Évalué à 3.
[^] # Re: c'est moi ou la procédure de mise à jour est pour le moins cavalière
Posté par Denis (site web personnel) . Évalué à 2.
Je ne vois rien dans l'annonce qui indique une incompatibilitée avec des squelettes existants ...
[^] # Re: c'est moi ou la procédure de mise à jour est pour le moins cavalière
Posté par Rodolphe Mosca (site web personnel) . Évalué à 2.
fichier habillage par exemple...
[^] # Re: c'est moi ou la procédure de mise à jour est pour le moins cavalière
Posté par R4f . Évalué à 10.
Disons que pour la plupart des fichiers (c'est à dire les squelettes, en ce qui nous concerne), SPIP est vraiment bien fait, car il ne fournit que des fichiers -dist.html, dont le comportement est annulé si on crée un fichier du même nom sans le -dist.
Ex. : un fichier article-dist.html est fourni (comme exemple) ; on peut remplacer l'affichage des articles en créant un fichier article.html. C'est ce fichier article.html qui sera pris en compte pour l'affichage des articles, au lieu de l'ancien article-dist.html.
De ce fait, lorsque SPIP est ré-installé, il écrase article-dist.html mais laisse intact ton article.html, fait maison. Bien joué, non ?
Pour ce qui est de habillage.css, c'est une des rares exceptions. Donc, comme d'hab', il faut faire une sauvegarde avant de ré-installer SPIP... Précaution qu'il est inutile de rappeler, bien sûr ! ;-)
[^] # Re: c'est moi ou la procédure de mise à jour est pour le moins cavalière
Posté par Denis (site web personnel) . Évalué à 5.
Pour tes fichiers CSS, spip 1.8 en contient 5 à la racine qui seraient effectivement écrasés:
habillage.css, impression.css, spip_admin.css, spip_style.css et typographie.css
Il est donc important de ne pas les écraser si tu as fait des modifs dessus que tu voudrais garder.
# et agora ?
Posté par ccomb (site web personnel) . Évalué à 7.
Ou bien est-ce qu'on est finalement en présence d'un vrai fork ?
[^] # Re: et agora ?
Posté par carlo . Évalué à 4.
En clair, le SIG voulait un outil avec de vrais procédures de "workflow"/validation de documents, et l'équipe de SPIP ne voulait pas changer le système actuel.
SPIP-Agora est donc bien un fork qui aboutira peut-être au "backports" de fonctionnalités vers SPIP (canal historique ;-) mais certainement pas (sauf gros changement) à une fusion des deux à un moment ou à un autre.
carl0:
[^] # Soyons clair
Posté par Jul (site web personnel) . Évalué à 1.
1) de «vrais procédures» tu peux expliquer ce que cela veut dire ?
2) peux tu nous donner tes source ?
Le SIG a fait un fork non maintenu, réinventer la roue, forker est une démarche hostile et stupide en logiciel libre. On appréciera le comportement de certains soit disant défenseurs du libre dans l'administration ; il semble que les administrations aiment à réinventer la roue (syndrôme NIH) les licences (CECILL), et forker (webCT95, spip-agora, les distros-«édus»). Je me dis que l'administration serait moins dangereuse pour le libre si elle était sous windows.
En plus ça marche moins bien que spip spip-agora, fun non ?
http://www.neokraft.net/blog/2004/06/17/515-comparaison-spip-spip-a(...)
[^] # Re: Soyons clair
Posté par carlo . Évalué à 4.
en gros, avec plus de niveaux de droits possibles que les seuls admins ou rédacteurs,
on le voit d'ailleurs sur le wiki http://spip-contrib.net/spikini/Agora2Spip(...) :
Proposition intégrée dans SPIP-AGORA : Plus de niveaux de validation
Avis SPIP : Non, ce n'est pas dans la philosophie de SPIP
J'ai entendu ces explications par un représentant de clever age (la ssii qui a, il me semble, participé au dev de spip-agora) lors d'une présentation sur les LL.
C'est également expliqué sur leur site http://www.agora.gouv.fr/article64.html(...)
Il me semble que c'est cette raison principale (celle du circuit de validation) qui a entrainé le fork. L'équipe de dev de SPIP ne voulant pas changer ce principe de fonctionnement de SPIP (celui d'origine, qu'on peut retrouvé sur le site de uzine : http://www.uzine.net/article1331.html(...) )
dans ce cas, ne t'inquiète pas l'administration est encore beaucoup (trop) sous windows ! ;-(
[^] # j'ai du mal avec le mot «vraies» dans vraies procédures
Posté par Jul (site web personnel) . Évalué à 6.
La philosophie de SPIP est de faciliter la publication, et je trouve la procédure déjà un tantinnet compliqué à expliquer à des béotiens bien que pertinente. Ainsi, j'ai du mal à voir le bénéfice d'avoir un outil plus compliqué et l'intérêt **réel** organisationnel et non **politique** que cela représente.
Le but est de produire du contenu au plus simple. Si les gens ne peuvent travailler ensemble dans la vraie vie, le patch informatique ne sera de toute façon qu'un cauthère sur une jambe de bois.
On sait qu'un programme est proche d'être abouti non quand on rajoute des fonctionnalités (gadgets) mais quand on en enlève à mon avis ; le véritable progès réside non l'apport d'un plus grand nombre de fonctionnalités mais dans la pertinence de ces dernières. En ceci, je trouve que l'équipe SPIP en refusant un process compliqué a montré sa maturité.
[^] # Re: j'ai du mal avec le mot «vraies» dans vraies procédures
Posté par Nap . Évalué à 8.
Les profils d'accès sont une notion universellement répandue. Je ne vois vraiment pas ce qui cloche la dedans. Je respecte le choix des devs de spip d'avoir voulu garder un modèle simple, mais je comprends parfaitement les besoins des clients ayant motivé le fork.
Dans ces cas là on peut aussi chercher à rendre le système plus souple, avec des regroupements de profils et de tâches, qui peuvent être affinés si besoin.
En ce qui concerne l'expression "plier les outils informatiques", je trouve que ça fait moins mal que "plier les utilisateurs", à part à un informaticien qui a du mal à imaginer que quelqu'un a pu penser différemment de lui...
[^] # Re: j'ai du mal avec le mot «vraies» dans vraies procédures
Posté par Jul (site web personnel) . Évalué à 3.
Ce projet était parti pour être un fiasco et c'était prévisible. (c'est certes simple de ma part de prédire le passé). Il y avait à la base une incompatibilité évidente entre le projet SPIP (publier simplement) et ce que voulait le client (une complexification du projet) ... le logiciel libre ne peut pas résoudre tous les problèmes, et notamment la mauvaise conduite du chantier informatique. Qu'il s'agisse de libre ou pas, la MOAS et la MOE sont passées à coté du sujet.
Au final, on ne fait pas boire un âne (SPIP) qui n'a pas soif, et certains se condamnent à faire un fork qui se fera éclipser par le projet upstream. C'est quoi l'intérêt ? Est-ce le coeur de métier de l'amdinistration d'être un éditeur de logiciel non pérennes ?
Il faut autre chose que publier du code sous GPL pour faire du logiciel libre : http://www.libroscope.org/Liberer-les-logiciels(...)
Sinon, en ce qui concerne le pliage, je pense que le métier de l'informaticien n'est ni d'aller dans le sens de l'utilisateur ou de la machine, mais d'avoir le sens de la mesure en essayant de proposer des situations où le "pliage" tant au niveau humain qu'informatique est minimal.
Et dans ma boîte on voit a priori :
- que faire simple ça demande plus de réflexion que de faire compliqué ;
- que faire simple apporte bien plus en terme de résultat ;
- que faire compliqué impressionne plus facilement ;
- que faire compliqué permet de facturer plus.
Donc on essaie toujours de faire au plus simple car on fera toujours trop compliqué.
[^] # Re: j'ai du mal avec le mot «vraies» dans vraies procédures
Posté par Nap . Évalué à 4.
[^] # Re: j'ai du mal avec le mot «vraies» dans vraies procédures
Posté par Croconux . Évalué à 6.
Il ne s'agit pas forcément de faire rentrer les utilisateurs dans un modèle mais en tant que fournisseur, on a un devoir de conseil. Il y a souvent une énorme divergence entre l'acheteur (celui qui choisit le produit) et les utilisateurs. Ces derniers ne sont en général pas des power users et veulent "que ça marche". Le decidor, lui, veut un produit qui fait le café. Il est souvent nécessaire de faire prendre conscience au boss que ce qu'il demande est une usine à gaz qui ne va pas dans le sens des utilisateurs.
Pour ce qui est de faire "plier les outils informatique", en général ça ne pose pas de problème d'adapter les outils si le fonctionnement de la boite est un minimum logique. La où on a de gros problèmes, c'est sur les boites "historiques", des boites munies d'innombrables niveaux hierarchiques, de processus de décisions avec allers retours d'un service à l'autre, etc (pensez aux administations). Là, au lieu de commencer par rationnaliser tout ça, on demande à l'informatique de s'adapter au bordel ambiant et de ne sortout pas changer l'existant. Informatiser ce n'est pas seulement installer des ordinateurs. Si l'activité ne tient pas compte du passage à l'informatique on abouti à des systèmes comme les sites de beaucoup d'administations qui permettent juste de téléchager les PDF à imprimer et à donner au guichet habituel. On a installé des systèmes mais on a pas revu les procédures. Il faut toujours passer par n guichets (n > 2 dans tous les cas) et le formulaire doit toujours être traité par plusieurs personnes.
[^] # Utilisateurs VS Outils Informatiques
Posté par Manuel Da SILVA . Évalué à 5.
Mais je ne peux qu'être d'accord sur l'expression "plier les outils informatiques", c'est à l'IHM de s'adapter et en aucun cas l'utilisateur...
Pour revenir sur les différents "niveaux" de validation (au delà du simple admin / contributeur), il est évident que dans un projet un temps soit peu important (c'est à dire, intégrant un nombre important de "contributions"), un classement de "droit" est nécessaire ; par exemple, donner un droit de "validation" sur une UNIQUE rubrique permet de soulager l'interface d'administration et d'apporter de la simplicité à cet utilisateur... et inversement limité les droits d'un contributeur sur une partie / theme / rubrique permet de simplifier sont travaille.
Ne pas confondre simplicité du concept (dualité entre validateur / contributeur) et simplicité d'utilisation !!!
Pour s'en convaincre, il suffit d'observer un utilisateur devant son "panel" de boutons et de ne pas savoir ou cliquer pour écrire sa petite brève dans la rubrique de sa matière !
[^] # Re: j'ai du mal avec le mot «vraies» dans vraies procédures
Posté par R4f . Évalué à 4.
On fait quand même tourner SPIP à La Poste (sur le site http://www.laposte.fr(...) ), donc je trouve que tu exagères ! ;-)
Bon, il a fallu ajouter un niveau hiérarchique à SPIP, et permettre d'ajouter des logos en Flash (beurk... ;-), donc un mini-fork, mais c'est passé sans trop en faire une uzine à gaz...
[^] # Re: Soyons clair
Posté par reno . Évalué à 8.
Ce qui est prècisement le cas ici, donc je ne vois pas en quoi c'est un problème.
[^] # Re: Soyons clair
Posté par François Becker (site web personnel) . Évalué à 4.
[^] # Re: Soyons clair
Posté par Nap . Évalué à 5.
[^] # Re: Soyons clair
Posté par mickabouille . Évalué à 10.
C'est bizarre, il me semble que l'on parle de forks hostiles et de forls non-hostiles pourtant. Ça doit bien vouloir dire quelque chose.
Pour moi, un fork c'est un peu comme une autre branche de développement. Au début, la plupart des architectures "autres" de Linux pouvaient être considérées comme des forks, jusqu'à ce qu'elles fusionnent (d'ailleurs, certaines sont toujours développées à part je crois).
Des fois c'est plutôt "on n'a pas le temps de le faire, faites de votre côté si vous pouvez, on verra peut-être plus tard si on peut récupérer votre boulot".
Et il y a bien sûr les forks stupides et hostiles. Mias faut pas se focaliser là dessus. D'autant que ça dépend du point de vue. Pour certains, le fork X.org est hostile (pour ceux de Xfree86). Pour la plupart, c'est le seul choix raisonnable. Encore heureux qu'on puisse forker.
>les distros-«édus»
J'appelle pas ça un fork moi. Souvent, ce sont des projets à l'intérieur de distribs (debian-edu), ou le travail de volontaires de l'administration *sans couverture de l'administration*, correspondant à des besoins spécifiques.
Faut pas être trop chatouilleux là dessus
[^] # Re: Soyons clair
Posté par Jul (site web personnel) . Évalué à 5.
Voilà une remarque à l'emporte pièce que j'aurais pas du sortir. Ta réponse est exacte.
Je devrais peut être plutôt dire que le fork est une arme de disuasion qui affaiblit les projets forkant et forker et qui n'es pas à utiliser à la légère. Ce serait bien que ce ne soit pas le premier réflexe des administrations.
Pour les trucs d'édu quand je parcours le web francophone je me dis qu'il faut plutôt dire que la communauté de l'enseignement et assimilée est très active (sympa, ext2, debian-edu). Je le dis avant qu'on me le fasse remarquer :)
J'ai écrit le précédent commentaires en étant de mauvaise humeur. C'est pas une raison pour dire des bêtises en manquant de nuance, mais je demande les circonstances atténuantes.
[^] # Re: et agora ?
Posté par R4f . Évalué à 7.
Objectif : intégrer sous forme de contrib les apports d’AGORA
http://spip-contrib.net/spikini/Agora2Spip(...)
[^] # Re: et agora ?
Posté par carlo . Évalué à 2.
carl0:
# Juste une coquille
Posté par Limousy Francis . Évalué à 1.
# Restriction d'accès à la zone publique
Posté par Pior . Évalué à 2.
J'ai réussit à le faire tant bien que mal sur un site, mais ça demande des manipulations plutôt inattendues pour Spip qui est, par ailleurs, très simple à mettre en place...
Même si ce n'était pas prévu pour l'utilisateur final, cela serait pratique que le moteur offre cette possibilité...
Mis à part cette petite complainte, je dis un grand merci à toute l'équipe de Spip, pour cet outil merveilleux :)
[^] # Re: Restriction d'accès à la zone publique
Posté par R4f . Évalué à 8.
Xprotector sera désormais ton ami ! http://xprotector.sourceforge.net/(...)
Xprotector est un programme en PHP pour créer et gérer des rubriques restreintes SPIP . On peut également gérer des utilisateurs qui ont accès à ces rubriques.
Ah, quand même une personne qui fait un commentaire sympa ! ;-)
# Conformité W3C
Posté par Pierre Jarillon (site web personnel) . Évalué à 7.
On ne peut qu'en féliciter les mainteneurs de SPIP. Cette déclaration contraste singulièrement avec les déclarations faites par Arno "W3C go home !" sur Uzine en septembre 2003. On ne peut que s'en réjouir car le respect des normes est le début de l'interopérabilité.
[^] # Re: Conformité W3C
Posté par tuiu pol . Évalué à 2.
La non-conformité des pages générées par SPIP est (était?) le seul point noir de ce logiciel en ce qui me concerne .. a essayer pour ceux qui ne connaissent pas.
[^] # Re: Conformité W3C
Posté par Jul (site web personnel) . Évalué à 10.
http://www.joelonsoftware.com/items/2004/04/22.html(...)
En général, il y a un excès pour certains qui regardent les pages aux W3C validator, au lieu de se poser la question de tester voir si elles sont «accessibles» en utilisant leur cervelle personnelle voir en les testants en condition (logiciel de lecture, brouteur texte, ou braille). Car le web est fait pour être lu et écrit par des humains au final handicapés ou non.
(NB l'orthographe, le respect de la typographie, l'organisation du contenu, le style sont pour moi des critères essentiels «d'accessibilité». Bizarrement, j'ai l'impression que la plupart des geeks s'en foutent, je me trompe ?)
Si les fanas du validator avaient utilisé leur cervelle, ils se seraient rendu compte que la conformité au W3C html stricte pour spip pouvaient être considérées comme du plaquage or sur une démarche de rendre la publication sur le web plus simple. Ce qui était une démarche d'accessibilité globale bien aboutie ; le but même du projet.
Quand spip était vers la fin (spip 1.7) faussement accusé de générer du code non conforme au validator (libroscope servait de démo, et j'ai vu passé les robots), j'ai rarement vu sur les forums linuxfr ou entendu dans diverses réunions en ville écrit : «ooops, je me suis trompé, ça passe le W3C et merci», mais plutôt : «ça pue SPIP, ça passe pas le W3C validator». Non seulement c'était faux, mais en plus ces commentaires passaient à coté de l'essentiel : ils ont réussi à rendre la publication et les contenus factuellement plus accessibles à tous : lecteurs et rédacteurs. Et qui plus et, ils ont encouragés des bonnes pratiques de lisibilité (organisation du contenu autre qu'en mode «en fil à la /.», typo, utilisation des CSS ...)
Moi, je m'en fous je suis pas développeur spip, mais je me dis qu'à leur place je l'aurais eu mauvaise et qu'il manque à certains ce que les grecs appellent le sens de la mesure.
[^] # Re: Conformité W3C
Posté par tuiu pol . Évalué à 1.
[^] # Re: Conformité W3C
Posté par Éric (site web personnel) . Évalué à 4.
<b>hello<p><i>world</b> !</i> tu interprêtes ça comment ? où met tu le gras ou met tu l'italique ? un moteur qui analyse ça n'est pas si simple. Si en plus tu veux l'analyser de la même façon que MSIE (c'est à dire pour faire court "comme l'auteur le veut") tu vas galerer pas mal à reproduire la logique d'erreur de MSIE et les bugs ou choix arbitraires non documentés qui vont avec.
Faire un moteur laxiste c'est très loin d'être simple, ne pas faire d'erreur syntaxique c'est déjà permettre d'analyser les pages avec des moteurs génériques SGML/XML. Et là une erreur syntaxique c'est quasi aussi gênant que 150 : la page ne passe pas, point final.
Certes la validité syntaxique n'est pas un aboutissement en soi, certes il y a bien d'autres points (certains aussi importants, certains largement plus), mais non promouvoir une validité complète n'est pas simplement de l'extrémisme.
> Car le web est fait pour être lu et écrit par des humains au final
> handicapés ou non.
Parce que bon ... justement NON :
- sauf quelques geeks le contenu Web n'est pas créé à la main
- et même parmi les geeks, le contenu Web n'est pas lu par les humains.
Le Web c'est lu/écrit/manipulé par des machines, pas par des humains, c'est bien tout le problème. Et les machines elles ont besoin d'une validité suivant une syntaxe connue et définie.
[^] # Re: Conformité W3C
Posté par Cali_Mero . Évalué à 0.
<i>Parce que bon ... justement NON :
- sauf quelques geeks le contenu Web n'est pas créé à la main
- et même parmi les geeks, le contenu Web n'est pas lu par les humains.</i>
Il faudrait, pour bien comprendre la portée de tes assertions, définir clairement le "contenu web" dont tu parles. Car le circuit de l'information sur le web est très loin de se limiter à machine > machine.
La production de contenu à vocation de publication, en HTML, se fait bien à la main (avec souvent le concours d'un éditeur wysiwyg pour la mise en forme, ou une conversion automatisée en HTML à partir de texte brut).
La consultation de code HTML n'est pas sérieusement envisageable avec autre chose qu'un parseur SGML relativement tolérant aux erreurs dans le but d'une présentation à un être humain par tout moyen.
On a donc bien l'humain en tête et en bout de chaîne non ? Certes, des machines servent d'intermédiaire, une responsabilité plus lourde pesant sur le navigateur du client final.
En revanche, ton point de vue retranscrit la raison d'être de XML et XHTML, et illustre aussi les problématiques d'indexation des pages web dans les moteurs de recherche. Le traitement par une machine est là clairement un objectif voulu dès la création, et la validité syntaxique est alors nécessaire et vérifiable.
Un spider de moteur de recherche pouvant être assimilé grosso-modo à un lecteur aveugle, il est clair qu'il aura plus de facilité à analyser du contenu fortement structuré, obéissant à la grammaire standard définie, qu'une soupe de tags dans l'esprit de ton exemple (<b>hello<p><i>world</b> !</i>).
[^] # Re: Conformité W3C
Posté par Éric (site web personnel) . Évalué à 4.
Absolument pas. Tout ce dont je parle est autant vrai en HTML/SGML qu'en XHTML/XML. Respecter les règles de syntaxe du format est aussi important dans l'un que dans l'autre.
> On a donc bien l'humain en tête et en bout de chaîne non ? Certes,
> des machines servent d'intermédiaire, une responsabilité plus
> lourde pesant sur le navigateur du client final.
L'humain ne manipule pas le HTML, l'humain manipule ce que la machine a compris et lui renvoie. C'est pour ça qu'il est important que la machine comprenne bien. C'est pour ça aussi qu'il faut avoir une syntaxe correcte.
Si la machine doit faire des acrobaties et se plante, l'humain se plantera aussi. Le HTML et les formats sont destinés à des machines et uniquement à des machines. Et respecter des règles non floues est primordial pour une machine.
Dans tes exemples, un navigateur, un outil WYSIWYG, un outil de conversion à partir de texte brut, ce n'est pas ce que j'appelle un humain, ce sont bien des machines.
> Car le circuit de l'information sur le web est très loin de se limiter à machine > machine
Certes, il faut "humain > machine > HTML/HTTP > machine > humain". Le HTML/HTTP est lu/écrit par des machines et uniquement par des machines. Le fait qu'il y ai des humains en bout de chaine n'y change rien : ça doit être relisible correctement et simplement par une machine, ça doit respecter le format.
[^] # Re: Conformité W3C
Posté par Antoine . Évalué à 3.
Du point de vue d'un internaute fraîchement arrivé, peut-être.
Mais bon, il y a dix ans, tout le monde écrivait le HTML à la main, sans passer par le moindre éditeur WYSIWYG.
[^] # Re: Conformité W3C
Posté par briaeros007 . Évalué à 4.
Et ton browser il lis bien le html, donc dans usage "normal" (et non pas de debug ou de codage) je pense que l'on peux dire que l'humain ne manipule pas le html.
Je me demande juste comment on peux dire "finalement respecter le protocole c'est pas si grave".
Ce n'est pas parceque le cout de l'erreur est largement moins important dans ce cas la que dans d'autres que ce n'est pas un point a essaye de respecter.
[^] # Re: Conformité W3C
Posté par Antoine . Évalué à 4.
Je parlais d'écrire le HTML, pas de le lire.
Je ne répondais pas spécialement sur le respect ou non des normes, mais sur le préconçu totalement foireux que le HTML n'est pas fait pour des humains.
Au contraire, la syntaxe du HTML (et ses diverses tolérances) a été étudiée spécialement pour être pratique à manipuler par des humains. C'est ce qui a permis la floraison du Web bien avant l'apparition des usines à gaz type Dreamweaver & co. Pour quiconque a découvert le Web au milieu des années 90, c'est une évidence. C'est aussi ce que rappelle l'article d'Arno si on fait abstraction de ses égarements rhétoriques.
J'ajoute qu'aujourd'hui encore, il est souvent nécessaire ou commode d'éditer le HTML à la main (par exemple quand on écrit des squelettes SPIP... ou pour d'autres outils de templates ;-)).
[^] # Re: Conformité W3C
Posté par Éric (site web personnel) . Évalué à 4.
Le HTML a des règles, des règles pas forcément aussi verbeuses que le XML, mais il n'est pas plus tolérant aux erreurs de syntaxe. Ce qui est tolérant c'est (éventuellement) le lecteur, pas le format.
(note: Le problème de la validité ça impacte celui qui lit le code, pas celui qui l'écrit. Et celui qui lit, c'est bien toujours une machine)
[^] # Re: Conformité W3C
Posté par Antoine . Évalué à 3.
Les pages valides passent aussi différemment partout, et pour cause : c'est dans la nature du HTML de laisser beaucoup de latitude au navigateur ainsi qu'à l'utilisateur (choix des polices, de la taille de la fenêtre, etc.)
Si tu comprends les standards du Web, tu sais comme moi que l'objectif du HTML n'est absolument pas de parvenir à un rendu identique partout. Seulement que le contenu soit lisible et que son rendu respecte à peu près les intentions de celui qui a composé la page.
et qui demandent des moteurs de plusieurs Mo juste pour afficher un "hello world" en vert sur fond bleu
Argument non-démontré jusqu'à ce jour... Les moteurs font plusieurs Mo parce qu'il y a des choses très complexes à traiter (imbrications de tables avec des tonnes d'attributs différents et parfois incompatibles, etc.). Un "hello world", même écrit dans un HTML laxiste, peut être rendu correctement par un Lynx ou un Dillo.
D'ailleurs j'aimerais bien que quelqu'un compile un jour Gecko en enlevant le support de ces tolérances. Il serait intéressant de voir si cela réduit tant que ça l'empreinte mémoire du navigateur, et si cela améliore significativement les performances. Je n'en suis pas convaincu.
Le problème de la validité ça impacte celui qui lit le code, pas celui qui l'écrit
??? Si tu considères qu'il faut écrire du code valide, il est évident que le problème de la validité impacte aussi celui qui écrit le code.
[^] # Re: Conformité W3C
Posté par Éric (site web personnel) . Évalué à 2.
> l'objectif du HTML n'est absolument pas de parvenir à un rendu
> identique partout.
Et tu sais aussi probablement très bien que je ne parle pas du problème d'avoir un rendu différent, mais plutot des différences de tolérance et d'interprétation des erreurs. Si on se contentais des différences de choix d'affichage, mon boulot serait énormément plus simple.
> Argument non-démontré jusqu'à ce jour...
> Un "hello world", même écrit dans un HTML laxiste, peut être rendu
> correctement par un Lynx ou un Dillo.
Discutes avec quelqu'un qui développe un "vrai" navigateur, tu vas voir. Demandes à ton lynx d'interpréter les pages avec erreur "comme MSIE" (ben oui, parce que le principe de la tolérance c'est bien si tout le monde est tolérant de la même façon), tu vas voir les nuits blanches que tu vas passer.
> Si tu considères qu'il faut écrire du code valide, il est évident que
> le problème de la validité impacte aussi celui qui écrit le code.
Si tu écris du code invalide ça ne te gênera pas toi, ça gênera celui qui essayera de le relire. Et puis non, on parle bien de spip là non ? le concept même de spip c'est que c'est l'outil qui écrit ce HTML. Pour l'auteur que Spip fasse du valide ou pas, ça ne change rien à ses manipulations
[^] # Re: Conformité W3C
Posté par Antoine . Évalué à 4.
Heu non, ça c'est phpNuke & co. Le concept de SPIP, c'est que c'est le webmestre qui confectionne ses squelettes HTML lui-même (bien sûr il y a des squelettes par défaut, qui d'ailleurs sont aux normes !).
[^] # Re: Conformité W3C
Posté par Manuel Da SILVA . Évalué à -1.
L'humain ne manipule pas le HTML... peut être pas mais ma synthèse vocale OUI
[^] # Re: Conformité W3C
Posté par nojhan (site web personnel, Mastodon) . Évalué à 4.
À mon avis, cet article visait surtout les facheux qui pestaient sans savoir, et ne pronait en rien un retour à la balkanisation.
[^] # Re: Conformité W3C
Posté par Éric (site web personnel) . Évalué à 4.
# Et le LDAP?
Posté par Swirly . Évalué à 1.
J'espère que ça viendra bientôt dans SPIP ça.
Voila, bonne journée, et quand même bravo aux développeurs.
@tchow
[^] # Re: Et le LDAP?
Posté par Denis (site web personnel) . Évalué à 2.
Le support LDAP -> http://www.spip.net/fr_article1910.html(...)
[^] # Re: Et le LDAP?
Posté par Swirly . Évalué à 3.
Ce qui manque, c'est de pouvoir s'authentifier sur le LDAP sans qu'il y ait redondance des informations et que le caractère de rédacteur puisse être associé à un groupe dans le LDAP (un groupe posix ou un groupofnames).
De façon à pourvoir gérer les rédacteurs de la même façon que tout le reste des fonctions dans une société ou un établissement scolaire : par des infos dans le LDAP.
Et ça, pour l'instant, ça n'existe pas encore dans SPIP.
Mais ceci dit, SPIP est une bonne solution .
Tchow
# Enfin...
Posté par okhin . Évalué à 1.
Par contre, il n'y aurais pas moyen de faire des fichiers *-dist.css, un peu comme pour les squelettes, afin de ne pas avoir à sauvegarder les ficheirs *.css et donc de préserver la mise en page?
[^] # Re: Enfin...
Posté par nojhan (site web personnel, Mastodon) . Évalué à 4.
# SPIP vs Mambo ?
Posté par Guillaume Vauvert (site web personnel) . Évalué à 2.
J'utilise un peu Mambo, et il me semble très bien fait, surtout parce qu'il autorise l'ajout de fonctionalités via des modules et des composants. Bien sûr, une telle souplesse se paie et Mambo me semble très lourd.
Quelqu'un connait-il suffisament les deux pour nous en donner une comparaison ?
[^] # Re: SPIP vs Mambo ?
Posté par dawar (site web personnel) . Évalué à 4.
On y retrouve la même possibilité que dans SPIP, faire un site qui ne ressemble pas forcément a l'éternel deux/trois-colonnes.
[^] # Re: SPIP vs Mambo ?
Posté par gloups . Évalué à 5.
C'est un besoin classique mais ce n'est pas forcement le domaine de SPIP.
SPIP est orienté publication éditoriale, il permet donc de traiter la structure globale du site et permet d'intégrer du contenu non lié à une page mais catégorisé. Le site se chargeant de permettre l'accès au contenu. (La première grosse référence SPIP est le monde diplo et cela montre bien l'objectif de SPIP.)
C'est une approche fondamentalement différentes dans la manière de gérer le contenu.
[^] # Re: SPIP vs Mambo ?
Posté par Cyril PIERRE de GEYER (site web personnel) . Évalué à 4.
A mon sens Spip est un outil tres facile a prendre en main et il permet de faire vite et bien un site éditorial.
Son système de cache permet d'avoir des performances excellentes.
Par contre des qu'il s'agit de faire des squelettes ca demande un peu de temps.
De plus je me suis trouvé assez vite limité par les extensions existantes.
Pour Mambo je le connais depuis moins longtemps mais j'ai particulièrement apprécié la dernière version (4.51 ?). L'interface est tres agréable et il existe de nombreuses possibilités.
Par contre c'est assez fouilli et pas evident de s'y retrouver. Il m'arrive souvent de chercher qq minutes pour retrouver une rubrique.
Au niveau des utilisateurs je préfère la gestion de SPIP qui est plus simple.
A mon sens Mambo est plus orienté site communautaire/CMS et spip est excellent pour les sites de publications qui n'ont pas besoin de fioritures.
D'autres retours ?
# Migration : 5 minutes chrono
Posté par Cyril PIERRE de GEYER (site web personnel) . Évalué à 2.
Aucun soucis ...
Chapeau les gars !!!!
Cyril
[^] # Re: Migration : 5 minutes chrono
Posté par Nap . Évalué à 2.
sinon pour ta signature, tu peux faire un vrai lien tu sais :)
[^] # Re: Migration : 5 minutes chrono
Posté par Lafrite . Évalué à 1.
Backup toujours, moins de morts par jour.
# Perso, ça m'a tout pêté
Posté par Gohar . Évalué à 1.
Je n'ai donc qu'un mot à dire : prudence!
[^] # Re: Perso, ça m'a tout pêté
Posté par Gohar . Évalué à 1.
Je sais, je peux ne m'en prendre qu'à moi, mais que mes mésaventures servent aux moins à d'autres: PRUDENCE !!!
[^] # Re: Perso, ça m'a tout pêté
Posté par Gohar . Évalué à 1.
[^] # Re: Perso, ça m'a tout pêté
Posté par NiCoS . Évalué à 1.
Mes squelettes .html et ma feuille de style.css sont à la racine du site et cela fonctionne très bien pour mes trois sites SPIP...
As-tu vérifié que :
1/ tous les fichiers transférés étaient bien transférés (mode binaire parfois à mettre dans ton client ftp)
2/ que tu n'as pas une variable définie pour dossier_squelettes ou je sais pas quoi dans /ecrire/inc_version.php3 il me semble
le répertoire dist ne sert que à contenir les squelettes *-dist.html fournis par SPIP.
bien sur tu avais fait une sauvegarde de ta base et de tes fichiers 1.7 avant de faire la mise à jour... donc no souci pour repasser en 1.7...
et puis pour les éventuels bugs, il y a les listes spip et spip-dev...
[^] # Re: Perso, ça m'a tout pêté
Posté par Gohar . Évalué à 1.
Hé ben moi, j'en ai un et j'ai dû placer les squelettes dans /dist pour que ça marche à peu près. Mes squelettes liés à des fichiers.php3 personnalisés (article_xxx.php3) ne fonctionnent toujours pas. Certains liens html ont aussi sauté, va savoir pourquoi…
1/ Oui
2/ Oui
Plus chez moi.
Bien sûr. Sauf qu’à part créer une autre base, je vois pas comment restaurer la base sauvegardée. Spip me l’interdit. Big souci.
Yep. Mais c’est pas mal de le dire ici aussi pour que je sois pas le seul à me faire avoir. Et j’estime qu’une version qui contient autant de modifs aurait dû s’appeler 2.0 . Je me serais méfié.
[^] # Re: Perso, ça m'a tout pêté
Posté par NiCoS . Évalué à 1.
Moi je passe que via des dumps sql et non pas le système de restatuation/backup de spip ;-)
[^] # Re: Perso, ça m'a tout pêté
Posté par NiCoS . Évalué à 2.
Un nouveau paquet (estampillé avec le même nom) a été diffusé
A lire d'abord : http://article.gmane.org/gmane.comp.web.spip.devel/26188(...)
[^] # Re: Perso, ça m'a tout pêté
Posté par Gohar . Évalué à 1.
[^] # Re: Perso, ça m'a tout pêté
Posté par NiCoS . Évalué à 1.
[^] # Re: Perso, ça m'a tout pêté
Posté par Gohar . Évalué à 0.
http://www.destination-linux.org/(...)
[^] # Re: Perso, ça m'a tout pêté
Posté par NiCoS . Évalué à 0.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.