Après des mois de développement, nous sommes heureux de vous présenter la dernière version de SPIP. SPIP est un système de publication francophone sous PHP/MySQL permettant à tout un chacun de construire un site Web sans se préoccuper des détails techniques. Par rapport à d'autres CMS comme daCode ou le célèbre trucNuke, il met l'accent sur la facilité d'utilisation (installation, interface de gestion), la richesse des fonctionnalités (templates, correction typographique...), et les performances (système de cache à deux niveaux). La liste des spécificités de SPIP est trop longue pour la détailler ici (voir l'annonce des nouveautés pour un petit aperçu).
Je rajoute un lien vers daCode parce qu'il faut bien faire un peu de lèche, et que le système de modération des forums est génial.
Aller plus loin
# SPIP is good
Posté par Olivier Martineau . Évalué à 10.
La personalisation est super facile (heuresement parce que le modèle de base est ... bof!)
[^] # Re: SPIP is good
Posté par nicolas cartron . Évalué à 10.
j'utilise la version 1.3.2 pour Squirrelmail-fr.org (http://www.squirrelmail-fr.org(...)).
Et le résultat est plutôt joli, le système de squelettes, mélange de code HTML et de balises SPIP (syntaxe très simples) est très facile à appréhender.
Bravo en tout cas.
Et je trouve plutôt sympa de la part de linuxfr de passer la news (ben oui, SPIP, c'est un concurrent de dacode ! ;)
[^] # Re: SPIP is good
Posté par yves-laurent allaert . Évalué à 10.
[^] # Re: SPIP is good
Posté par john howard . Évalué à -2.
N'empeche, ca aurait pu faire un beau troll dacode vs SPIP, mais j'ai cru voir une news avec windows, on va pouvoir se consoler ;)
# Petite précision...
Posté par core . Évalué à -6.
"trucNuke" s'appelle en fait PhpNuke (voir http://www.phpnuke.org(...)) et en est à sa version 6.0 je crois. Pour l'avoir utilisé, je pense que SPIP est très adapté pour les petits sites à mettre en place très rapidement, phpnuke quant à lui est assez aussi simple et rapide à mettre en oeuvre mais est plus dédié aux très gros sites multilingues, et il comporte un nombre impressionant de modules aussi divers que variés.
Par contre je ne sais pas s'il y a un système de cache dans phpnuke, ce qui est pourtant un gros atout.
[^] # Re: Petite précision...
Posté par Pascal Terjan (site web personnel) . Évalué à 10.
Sans compter ce que je pense de son auteur mais je vais éviter de devenir trop méchant.
[^] # Re: Petite précision...
Posté par Guillaume Rousse (site web personnel) . Évalué à 10.
Tu veux dire que les trous de sécurité sont mal codés ? Les développeurs ne respectent vraiment plus rien de nos jours :-)
[^] # Re: Petite précision...
Posté par Éric (site web personnel) . Évalué à 10.
sisi, phpnuke c'est pour les gros sites.
D'ailleurs n'importe quel site perss devient un gros site niveau ressource si on met phpnuke dessus :)
</troll>
-1 car je vais pas être le seul à le dire
[^] # Re: Petite précision...
Posté par core . Évalué à 3.
Pour l'anecdote, il faut savoir que F. Burzzi a appris le PHP & le SQL au fur et à mesure qu'il a développé PHPNuke! Pour avoir suivi le code de très près au fil des versions, je peux vous dire qu'il a admirablement progressé :-)
[^] # Heuuuuu
Posté par Moby-Dik . Évalué à 1.
Si ce n'est pas le cas, je ne vois pas comment il pourrait "tenir la charge" pour une page du genre http://www.phpnuke.org/(...) chez un hébergeur bon marché. C'est une simple question de bon sens et de poids en ressources : sur une page d'accueil PHPNuke, il faut une bonne tripotée de requêtes SQL pour afficher toutes les boîboîtes.
[^] # Re: Heuuuuu
Posté par Anonyme . Évalué à -6.
[^] # Re: Heuuuuu
Posté par Anonyme . Évalué à -5.
Je parle de vrai charge en test, hein, des trucs du genre 4000 utilisateurs simultanés avec requêtes aux BDD, pas des tests avec ab quoi.
[^] # Re: Heuuuuu
Posté par Moby-Dik . Évalué à -3.
Et puis ce serait intéressant d'avoir des termes de comparaison avec d'autres solutions.
[^] # Re: Heuuuuu
Posté par Anonyme . Évalué à -2.
Les benchs faits étaient plus stressants que la réalité (2 à 3 fois), et Apache plantait lamentablement comme une grosse loutre bourrée à la bière, même customizé à donf les manettes.
[^] # Re: Heuuuuu
Posté par Nicolas Boulay (site web personnel) . Évalué à -1.
Il m'avait parler du site du festival de Cannes, de mémoire il avait aussi 15M de hits/jour.
(et au fait, personne n'a tester apache+httpd ou apache+Tux, parait qu'en statique les perf font x2-4)
nicO
"La première sécurité est la liberté"
[^] # Re: Heuuuuu
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 2.
De toute manière il faut pas chercher, si ce n'est pas des pages statiques alors il faut un max de matos, là nous on tournait sur un bi PPro200...
[^] # Re: Heuuuuu
Posté par Éric (site web personnel) . Évalué à 1.
[^] # Re: Heuuuuu
Posté par Anonyme . Évalué à -2.
[^] # Re: Heuuuuu
Posté par core . Évalué à 2.
Ce n'est pas parceque tu vas avoir plein de requetes SQL que tu vas forcément avoir une mauvaise tenue à la charge. Ca dépend de la façon dont c'est implémenté.
Le cache est un système (souvent pratique) pour faire encaisser de fortes charges à un serveur, ou à compenser un système qui justement ne tient pas la charge.
Il faut savoir que les systèmes de cache peuvent (au moins) être de deux ordres sur un site Internet :
1) cache HTML des pages : l'utilisateur a "l'impression" d'utiliser un système dynamique mais en fait il visualise le résultat HTML qui est enregistré régulièrement sur le serveur à partir du contenu réellement dynamique PHP<->BD.
-> ce système permet d'éviter d'interpréter le PHP et d'effectuer toutes les requetes SQL à chaque fois qu'une page est interrogée (n'est-ce pas un système similaire qui est implémenté avec DaCode ?)
2) cache SQL : les requetes SQL les plus courantes sont mises en cache, ça évite d'avoir à interroger le système de BD à chaque fois si le résultat est toujours le même, et PHP n'y voit que du feu.
-> ce système économise les ressources bases de données qui sont souvent le principal facteur de charge d'un système web dynamique. Ce système est implémenté par défaut dans certaines bases de données comme Oracle, mais pas dans MySQL par exemple (peut-être dans des versions très récentes ?)
[^] # Re: Heuuuuu
Posté par Moby-Dik . Évalué à -5.
Pour le cache : ce qu'on te dit est justement que PHPNuke n'a pas de système de cache et regénère toutes les pages à la volée. Une demi-seconde incompressible pour chaque génération de page. Tu vois le problème ?
[^] # Re: Heuuuuu
Posté par core . Évalué à -3.
je ne récite pas ma leçon - je parle d'expérience, de choses que je n'ai pas apprises à l'école et j'explique, je pense que ça peut servir.
> mais je ne vois pas où on
> pourrait avoir un algo exponentiel dans un système de
> gestion de contenus.
Malheureusement si c'est mal programmé c'est le genre de choses qui peut arriver.
> Pour le cache : ce qu'on te dit est justement que PHPNuke > n'a pas de système de cache
Ce qui reste à vérifier pour la version 6.0.
> et regénère toutes les pages à la volée. Une demi-seconde
> incompressible pour chaque génération de page.
C'est totalement faux.
> Tu vois le problème ?
Oui : le pb c'est que tu n'as pas d'expérience de mise en oeuvre de _gros_ sites qui utilisent PHP/SQL et donc que tu parles de ce que tu connais mal.
J'ai monté un certain nombre de sites sur une base phpnuke et avec les versions récentes (5 et +) certains encaissent plus de 100 utilisateurs simultanés pendant plusieurs heures, sans charge extrème du serveur, et avec un temps d'accès inférieur à la seconde.
[^] # Discussion stérile
Posté par Moby-Dik . Évalué à 2.
Oui, effectivement, cette version n'est pas sortie. Je peux te parler de Windows 2005 aussi, qui soi-disant n'a pas de bug et est super performant. En attendant PHPNuke 5.6, la version actuelle, n'a pas de système de cache.
C'est totalement faux.
Dis, ça t'arrive de poster des affirmations argumentées ? Tu pourrais au moins sortir un bench, des mesures, une URL....
J'ai monté un certain nombre de sites sur une base phpnuke et avec les versions récentes (5 et +) certains encaissent plus de 100 utilisateurs simultanés pendant plusieurs heures, sans charge extrème du serveur, et avec un temps d'accès inférieur à la seconde.
C'est bien, tu as une URL à nous montrer ? Tous les sites de type Nuke que j'ai vus passer ont une tendance facheuse tendance à ramer, et ce d'autant plus qu'ils sont fréquentés. D'ailleurs je ne suis pas le seul à le dire, tu as bien dû voir qu'à peu près tous les intervenants du forum sont de cet avis. Du coup, une utilisation efficace de PHPNuke, on aimerait bien en avoir une preuve :-))
Note qu'un temps d'accès juste "inférieur à la seconde" c'est notoirement insuffisant si tu as plusieurs dizaines de milliers de consultations par jour. Et si toutes tes pages prennent plus d'une demi-seconde à générer et que tu as beaucoup de visites, ton hébergeur va te flinguer.
[^] # Re: Petite précision...
Posté par Antoine . Évalué à 9.
Plus exactement, il y a l'original et une nuée de forks qui s'en sont suivis (et ça continue...). Pour un aperçu de la galaxie des Nuke-like, voir le site http://www.kaintech.net/.(...)
Personnellement si j'avais besoin de fonctionnalités de type communauté, je prendrais plutôt daCode : code propre, système de cache, et système de votes/modération très sympathique. Les *-Nuke pour moi, c'est vraiment la foire aux machins en tout genre, c'est un gigantesque gloubiboulga incontrôlable et préhistorique.
[^] # Re: Petite précision...
Posté par core . Évalué à 10.
A coté de ça je ne suis pas sectaire, je n'ai rien contre DaCode, mais je préfère présenter des arguments, des faits, que de rentrer dans des querelles partisanes sans fondements.
# mise à jour 1.3.2 --> 1.4.0
Posté par Sebastien . Évalué à 10.
L'interface d'admin a d'ailleurs été entierement refaite. Très clean, mieux organisée (plus hierarchisée, présence de raccourcis...) c'est un vrai bonheur.
Mon thème est resté le même après la mise à jour.
Seul truc bizarre, les petits triangles tournants pour ouvrir et fermer les fils de discussion à la suite des articles ont disparus... A chercher.
http://digitalfox.homeip.net/~journal/(...)
Merci aux developpeurs de Spip.
# et en Chine ?
Posté par Zorro (site web personnel) . Évalué à -1.
# système de cache de SPIP
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
Donc, une page souvent inchangée sera recalculée (pour rien) plusieurs fois par jour. Une page mis à jour mettra une heure pour apparaitre en ligne à moins d'invalider le cache à la main.
Je ne comprends pas l'interret d'une telle méthode. Pourquoi ne pas générer directement les pages lorsqu'elle sont publié et fournir sur le site publique directement du html statique bien plus rapide que le système d'indirection. Le dynamique n'a à prioris pas d'interret dans ce cas !
Surtout que les forums ont l'air de fonctionner de cette manière. Si quelqu'un pouvait le lever ce mystère.
(sinon le système de template à l'air sympa !)
nicO
"La première sécurité est la liberté"
[^] # Re: système de cache de SPIP
Posté par Anonyme . Évalué à 1.
Le système de cache SPIP est expliqué dans la doc, mais je retrouve plus le lien. D'après ce que je me souviens, tu donnes une durée de vie à ta page avant regénération (une heure, une journée, une minute) selon ce que tu veux qu'elle fasse.
Si une modif intervient sur la page, le cache n'est pas invalidé et la modif sera donc effective à partir du délai.
Par contre, il y a des actions qui invalident le cache. Typiquement, un post dans le forum.
[^] # Re: système de cache de SPIP
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
On perd tellement de perf !
Il semble à prioris super simple de ne regénérer les pages que après un changement (si on veut limiter la taille du cache, on peut avoir besoin d'effacer et de recréer c'est le cas pour dacode qui est customisé pour chaque utilisateur mais pas SPIP).
"La première sécurité est la liberté"
[^] # Re: système de cache de SPIP
Posté par Anonyme . Évalué à -1.
[^] # Re: système de cache de SPIP
Posté par Nicolas Boulay (site web personnel) . Évalué à -1.
Le must pour éviter les gros coup de bourre serait de détecter les erreurs 404 pour générer les pages manquantes.
création si manquant + effacement si cache trop grand + page accéder en .html = un vrai cache.
[j'ai jamais dis que c'était simple à faire !]
"La première sécurité est la liberté"
[^] # Re: système de cache de SPIP
Posté par Anonyme . Évalué à -2.
Et non, il n'y a pas de page de dépendances.
[^] # Re: système de cache de SPIP
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Et pourquoi je serais compliqué ;p Disons que, pour la gestion des erreurs 404, templeete cherche à le faire mais ce n'est pas dis que des gusses comme free.fr l'autorise.
Je suppose qu'un site comme spip n'a pas des Go de pages même si elles sont toutes générées. Donc tout le site gagnerait tellement en perf à être 100% pure statique (facile x10, si j'ai bien suivi). La partie dynamique sert à gérer le site et la partie publique reste statique. On a même pas besoin d'un vrai système de cache (qui gère absence et taille du répertoire).
"La première sécurité est la liberté"
[^] # Re: système de cache de SPIP
Posté par Anonyme . Évalué à -1.
Niveau dépendance, oui, il y a dans la BDD.
AMHA, je trouve SPIP déjà assez compliqué comme ça pour ne pas le modifier sur ce niveau là. Le système fonctionne bien, il pourrait fonctionner mieux, mais peut-être au prix de développements qui ne sont pas nécessaires pour l'instant.
[^] # Re: système de cache de SPIP
Posté par Nicolas Boulay (site web personnel) . Évalué à -1.
C'est un test à faire mais entre .html et le cache de SPIP telle qu'il est, on doit pouvoir multiplier les perf par 2 ou 3 mini et voir beaucoup plus.
"La première sécurité est la liberté"
[^] # Re: système de cache de SPIP
Posté par Antoine . Évalué à 3.
Exact. Une page en cache sous SPIP prend 10 à 20 ms (mesuré avec ApacheBench). C'est probablement 10 fois plus qu'une page statique.
(désolé de ne pas faire de réponse plus longues, le serveur me jette :-(( )
[^] # Re: système de cache de SPIP
Posté par Anonyme . Évalué à 1.
[^] # Re: système de cache de SPIP
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Mais en quoi es-tu obliger de mettre ton index en php ?
A mon humble avis, les seul pages à avoir besoin d'être en php sont celle qui perm^te de générer les autres.
En gros, tu accèdes à www.tonsitespip.org/index.html qui propose un lien d'admin vers www.tonsitespip.org/ecrire/index.php pour faire les modifications.
Où est l'interaction des utilisateurs qui nécessitent vraiment un site 100% dynamique ? Même un forum n'a pas d'interret à être 100 % dynamique.
"La première sécurité est la liberté"
[^] # Re: système de cache de SPIP
Posté par john howard . Évalué à 3.
En gros, tu accèdes à www.tonsitespip.org/index.html qui propose un lien d'admin vers www.tonsitespip.org/ecrire/index.php pour faire les modifications.
tout a fait d'accord! Combien de fois suis-je tombe sur des pages web arborant fierement "a ete recode en php". Certaines pages totalement statiques sont "codees" en php, pk donc?
[^] # Re: système de cache de SPIP
Posté par Éric (site web personnel) . Évalué à 0.
Si ton site est à 90% des pages php sauf cas bien précis je préfère probablement mettre les 10% restant aussi avec l'extension .php histoire d'etre sur de ne pas etre bloqué dans les évolutions futures. Bon, ca dépend grandement du cas précis mais une page html au milieu de 10 php ca veut dire tout remodifier les liens si tu as besoin de la faire évoluer.
[^] # Re: système de cache de SPIP
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
Les pages html sont gérer à 100 % par tes pages dynamiques donc les modifiers est super facile.
La seul différence avec le système actuelle généralement utilisé est de générer la page à la modif et non à la demande.
"La première sécurité est la liberté"
[^] # Re: système de cache de SPIP
Posté par Anonyme . Évalué à 1.
Les forums. Sinon, il y a le cache. Tu vois, je finirais bien par te faire dire que tu es d'accord avec moi, tu y es presque là...
> Même un forum n'a pas d'interret à être 100 % dynamique.
Euh... si. Tu passerai pas un générateur de page HTML au moment du post? En PHP? Sur un serveur multiutilisateur comme un forum Web? Donc conccurent?
[^] # Re: système de cache de SPIP
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: système de cache de SPIP
Posté par Anonyme . Évalué à 0.
Tiens, comme ça, une question: comment tu évites qu'en cas de postage simultané, les 2 process qui gèrent ça écrivent en même temps la page de consultation?
[^] # Re: système de cache de SPIP
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Tu peux aussi ajouter une entrée à une base de donné qui gère ainsi la concurrence. Reste plus qu'à faire un "update" une bète fonction qui transforme BD -> HTMl (en gros le code qui habituellement appeler à chaque requète).
Bref, c'est complexe mais pas bien sorcier. C'est juste une bète partage de ressource.
"La première sécurité est la liberté"
[^] # Re: système de cache de SPIP
Posté par Anonyme . Évalué à 2.
Par contre, le coup de la génération de l'HTML par la BDD ou un process extérieur au serveur Web l'est.
A la limite, même le coup des sémaphores le fichier ça pourrait marcher, mais faudrait pas que ton site ait beaucoup de posts a gérer en même temps.
[^] # Re: système de cache de SPIP (1)
Posté par Antoine . Évalué à 4.
- il faut aussi recalculer la page consacrée à la rubrique contenant l'article
- il faut éventuellement recalculer la page consacrée à la rubrique parente, si le webmestre y affiche les articles des rubriques filles
- il faut éventuellement recalculer la page des mots-clés liés à l'article, des articles liés aux mots-clés à l'article
- etc.
[^] # Re: système de cache de SPIP (2)
Posté par Antoine . Évalué à 3.
En fait, le problème c'est que ces dépendances ne sont pas figées mais définies par les templates (squelettes) réalisés par le webmestre. Une analyse systématique des dépendances serait trop lourde. On a fait un compromis pour les forums : on y analyse les dépendances les plus communes.
[^] # Re: système de cache de SPIP (2)
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: système de cache de SPIP (2)
Posté par Antoine . Évalué à 3.
# SPIP roulèze
Posté par R4f . Évalué à 3.
Résultat : pas de HTML dans les articles, donc on contrôle plus facilement le rendu des articles et l'homogénéité du look. Avantage supplémentaire : on peut envoyer des articles par mail sans avoir à stripper du HTML, mais une syntaxe qu'on maitrise beaucoup plus.
Encore un atout : l'ajout d'images. On uploade, puis on a un tag à mettre dans son article pour insérer l'image...
À noter également : PhpNuke est un weblog avec des modules en pagaille, alors que SPIP est un système de publication en ligne. Pas le même but, même si certains galèrent à vouloir faire des pseudo-gestionnaires de contenu basés sur des Phpnuke-like... Je ne crois pas qu'on puisse retoucher un article après l'avoir écrit, sous PhpNuke, alors qu'avec SPIP c'est possible : les articles appartiennent à des utilisateurs.
[^] # Re: SPIP roulèze
Posté par Anonyme . Évalué à -3.
Perdu. Une fois l'article publié, seuls les administrateurs du site peuvent modifier l'article.
[^] # Re: SPIP roulèze
Posté par R4f . Évalué à 2.
Non, ils peuvent le remettre «en cours d'édition», ce qui nécessite de savoir qui a écrit l'article, et qui est bien plus puissant qu'avec les PhpNuke où on ne sait pas qui a écrit quoi...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.