Différences avec WordPress
Flexweg CMS reprend les concepts familiers de WordPress (posts, pages, catégories, tags, menus, thèmes, plugins, hooks) mais le modèle d'exécution est radicalement différent. Si vous venez de
Flexweg CMS reprend les concepts familiers de WordPress (posts, pages, catégories, tags, menus, thèmes, plugins, hooks) mais le modèle d'exécution est radicalement différent. Si vous venez de WordPress, voici ce qui est conservé, ce qui change, et pourquoi.
Ce qui est conservé
- Posts et pages : deux types de contenu distincts, le post a une catégorie principale (URL
<catégorie>/<slug>.html), la page vit à la racine (<slug>.html) - Catégories et tags : la catégorie principale d'un post pilote l'URL ; les tags sont juste des filtres
- Menus : assemblés dans l'admin, rendus dynamiquement sur le site public (via
menu.json+ un petit loader runtime du thème) - Thèmes et plugins : à la WordPress — installables / désinstallables à chaud, registries de hooks (
addFilter,addAction) - Brouillon vs publié : un post brouillon n'est pas sur le site public, publier upload le fichier
- Médiathèque : pipeline d'image multi-variantes (vignette, taille moyenne, original) en WebP
Ce qui change vraiment
Pas de serveur applicatif sur le frontend public
WordPress génère chaque page à la requête (PHP + MySQL) ou via un cache. Flexweg CMS publie un site strictement statique : chaque URL est un fichier HTML déjà sur disque. Pas de WP-Admin sur le frontend, pas de session PHP, pas de plugin qui tourne à la requête.
Conséquence : tout ce qui était « plugin frontend » dans WordPress (commentaires, paniers de paiement temps réel, pages personnalisées par utilisateur) devient soit :
- côté navigateur via un loader runtime du thème (recherche, hide-on-scroll, menus, ...)
- géré par un service tiers que vous intégrez via un embed
- impossible dans le modèle Flexweg CMS — c'est un compromis assumé
L'admin tourne dans le navigateur
WordPress charge /wp-admin/ depuis le serveur PHP. Flexweg CMS charge /admin/ qui est une SPA React déjà sur disque. Avantage : pas de version PHP à maintenir, pas de mise à jour critique à appliquer en urgence. Inconvénient : pas de connexion sans tiers — l'admin doit s'adosser à Firebase Auth OU à l'API Auth SQLite du backend Flexweg.
Deux backends de données interchangeables
WordPress = MySQL. Flexweg CMS = Firebase ou SQLite intégré. Le choix se fait à l'installation. Tout le code admin (services, hooks de publication, plugins) est strictement le même au-dessus du dispatcher — vous pouvez basculer plus tard.
Publication = upload
WordPress sauvegarde en base, le serveur sert. Flexweg CMS sauvegarde en base ET upload le fichier HTML rendu sur Flexweg. Conséquence : chaque clic sur Publier fait trois choses (sauvegarder, rendre, uploader). Si l'API Flexweg est en panne, vous ne pouvez pas publier — mais le site public reste en ligne avec la dernière version uploadée. C'est le bon compromis.
Les hooks sont typés et orientés publication
WordPress a wp_head, the_content, etc. Flexweg CMS a page.head.extra, post.html.body, etc. — typés TypeScript, déclenchés au moment de la publication (pas à la requête). Voir la référence des hooks.
Pas de mises à jour automatiques côté public
WordPress vous demande de cliquer sur « Update » après chaque release. Flexweg CMS sépare l'admin (que vous mettez à jour en uploadant un nouveau dist/admin/) du contenu public (statique sur disque). Aucun script ne tourne en arrière-plan sur le frontend.
Faut-il migrer ?
- Site éditorial / vitrine / blog / portfolio sans personnalisation par utilisateur : oui, Flexweg CMS est plus rapide, moins cher, plus simple
- Site e-commerce avec stock temps réel : non, Flexweg CMS n'est pas un Magento
- Site très dynamique avec utilisateurs connectés : non, c'est hors modèle
Pour les sites où Flexweg CMS est adapté, le gain est massif : plus de plugins à mettre à jour en urgence, plus de PHP à patcher, plus de base à sauvegarder côté public.