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

Fonctionalités

|Fonctions|SPIP|Wordpress|
|Multilinguisme|Natif|Plugin souvent incomplet|
|Multi-auteur|Natif (y compris visiteurs)|Plugins|
|Multi-moteur SGBBD|Natif| Aucun|
|Multi-sites (ferme..)|Plugin d’aide |Fonctions|SPIP|Wordpress |
|Multilinguisme|Natif|Plugin souvent incomplet |
|Multi-auteur|Natif ( y compris visiteurs)|Plugins |
|Multi-moteur SGBBD|Natif | Intégré Aucun |
|requêtes |requetes 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 requetes , à 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] |
|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 pas de Wysiwyg natif , les raccourcis | Wysiwyg ( ergonomie , facilité ) mais HTML 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|
|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|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 fiabilise 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.|