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
| Fonctions | SPIP | Wordpress |
|---|---|---|
| Multilinguisme | Natif | Plugin souvent incomplet et casse-tête |
| Typographie | Natif et de qualité | 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 », et mélangent tout, textes et illustrations) |
| 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 le HTML complet est stocké en base, pas forcément nettoyé (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
- SPIP pas de publicité, pas de trackers ou mouchards, pas de plugins payant ou premium
- SPIP n’appartient à personne (pas de société ou de fondations)
- la communauté (essentiellement francophone) apporte un suivi des plugins
- les plugins SPIP ont un mode d’intégration bien défini, renforçant leur qualité
Quelques arguments en faveur de SPIP :
- Maîtrise budgétaire, on sait dès le départ combien on paie pour les plugins (0€), alors qu’avec Wordpress, un plugin gratuit essentiel peut souvent devenir payant par la suite. Par exemple, pour un thème Wordpress payant, il faut repayer à chaque update sans savoir précisément ce que contient l’update.
- les plugins SPIP sont sur un dépot git centralisé, ce qui permet une meilleure collaboration des dev
- Réactivité de l’équipe de développement en cas de problème de sécurité,
- Wordpress et Elementor demandent beaucoup de ressources serveur, ce qui élimine une bonne part des hébergeurs (notamment un ovh mutu de base !)
- Plugin ODT2PIP permettant de saisir tranquillement un article au format ODF et de le balancer sur SPIP images et tableaux inclus, (j’ai fait un modèle et un tutoriel au cas où),
- Travail de l’article avec le mode « modification du contenu » à gauche et le rendu à droite qui permet un meilleur travail de correction.
- la souplesse du système de boucle : pas d’affichage en l’absence d’article publié,
une page ne se modifie que si un article est trouvé dans une boucle.
- simplicité du système de filtrage : par exemple affichage sans aucune programmation avec {titre_mot=lemotclé}, ou avec le critere age
PS je ne sais pas si c’est toujours le cs mais le cache de WP n’était pas intégré au noyau, mais à des extensions. Il y a donc perte de souplesse et de rapidité
pour s’amuser à la gestion du cache sous WP cf la complication https://kinsta.com/fr/blog/vider-cache-wordpress/ à comparer avec le bouton « Maintenance/Vider le cache »
Quelques références...
- Discussion 2023
- Avantages & inconvénients de WP