Version 20 — Avril 2020 — 183.82.xx.xx
En évitant les guerres de religions -fréquentes dans ces comparaisons-, lister les points forts de SPIP par rapport à Wordpress pour un décideur.
| 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 | 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 ....
A compléter ....
Quelques références...