Carnet Wiki

SPIP versus Wordpress

SPIP-Contrib :: Carnet Wiki :: Recherche :

SPIP versus Wordpress

En évitant les guerres de religions -fréquentes dans ces comparaisons-, lister les points forts de SPIP par rapport à Wordpress pour un décideur.

Fonctionnalités

FonctionsSPIPWordpress
Multilinguisme Natif Plugin souvent incomplet
Multi-auteur Natif (y compris visiteurs) Plugins
Multi-moteur SGBBD Natif Aucun
Multi-sites (ferme..) Plugin d’aide Intégré
requêtes complexes
multi-tables
SPIP gère les multi-requetes et multi-tables en cache WP n’a qu’une boucle post : il n’est pas prévu pour gérer plusieurs requêtes, à fortiori plusieurs bases
Cookies Aucun  ???
Déménagement

de serveur / URL

Facile (juste une méta, à reconfiguration automatique) Souvent délicat, il faut intervenir en base

(les plugins stockent les permaliens « en dur »)

Contenu Objets éditoriaux en arborescence structurée Des articles(posts) rattachés à des catégories
Rédaction Séparation Fond / Forme,Wysiwyg limité natif, raccourcis d’édition Wysiwyg (ergonomie, facilité) mais HTML complet [1] en base (difficile à gérer en cas d’évolution de syntaxe)
Organisation / Présentation Séparation Thèmes graphiques / Squelettes le « thème » définit le graphisme et tous les modes de présentation & navigation
Surcharge de
personnalisation
le concept de surcharge (remplacer un fichier originel) est générique à la totalité du produit (y compris les fonctions _dist) La pratique des thèmes-enfant(peu courante) permet un unique niveau de surcharge
Sécurité des
personnalisations
le concept de surcharge (dupliquant un fichier originel) est limité aux squelettes HTML (le php reste celui du « core ») http://spippourlesnuls.fr/597 WP propose directement les sources php à la modification par l’administrateur dans un éditeur intégré
Menus automatique par les boucles sur contenu (plugins de définitions directes) manuels : à associer aux contenus à chaque modification
Performance : Cache Natif, permet une installation sur un serveur mutualisé Plugin
Performance front-end :
compression JS / CSS
Natif (option de config.) Plugin
Plan & Sitemap Natifs (y compris robots.txt et .htaccess ) plugin obligatoire
Flux RSS &iCal squelettes natifs plugins spécifiques
Macros de
rédaction-articles
modèles (extensibles en simple HTML) shortcodes (à définir par php)
Autorisations et accès plugin de zones d’accès restreint, extensibilité du modèle d’autorisation rôles d’auteurs, et souvent gestion des accès aux tables, par les noms des tables en base
Modèle de développement intégré au core excroissances pures
Extensions Intégrables au framework plugins spécifiques
contrôle qualité la communauté suit les plugins la foultitude de plugins complexifie le choix
Sécurité ces suivi et modèles CVT/normes de codage fiabilisent les plugins la fréquence d’usage de WP ne justifie pas les fréquentes mise-à-jour de sécurité publiées
Intégration plugins les plugins ont un ordre d’installation fixé, et coopèrent avec les memes bases de bibliothèque la co-existence de multiples plugins souvent indispensables est rapidement problématique...
Intégration programmée toutes les extensions bénéficient automatiquement du cache programmations spécifiques à adapter
Courbe d’apprentissage Atypique, mais très progressive (sans nécessiter le php) Facilité initiale, mais ensuite... un mur php
Réalisation intégrée La plupart des Sites SPIP ne nécessitent aucun plugin pour être réellement « exploitables » Nécessité de multiplier les adjonctions de plugins pour obtenir un résultat fonctionnel.

A compléter ....

Eco-système

A compléter ....

Quelques références...

[1Attention au syndrome « Arbre de Noël » : se dit d’un site aux colorations extravagantes introduites dans les textes, avec un éditeur acceptant tous les codes HTML..