Quand choisir Silverstripe pour un projet de contenu

Une personne qui rédige doit pouvoir modifier une page sans toucher aux fichiers PHP. Un développeur doit pouvoir organiser le contenu sans tout faire rentrer dans un grand champ de texte. Le CMS doit répondre aux deux besoins.

C’est ce qui m’intéressait dans Silverstripe. Il associe une interface de gestion de contenu à un framework PHP. Mon article original présentait surtout cette combinaison. Elle reste utile à comprendre avant de choisir cet outil pour un projet.

Relier le contenu à la logique du site

Prenons un site avec des pages classiques, un répertoire de projets et les profils des personnes qui y participent. Chaque projet peut avoir un titre, une date, une description et des liens vers plusieurs profils.

Je voudrais que ces relations existent dans le modèle de contenu. Demander à la personne qui rédige de les maintenir en recopiant du HTML ajouterait du travail et des risques d’erreur.

Silverstripe propose un ORM, des templates et des points d’extension avec son CMS. Son framework peut aussi être utilisé seul. C’est donc une piste lorsque le site demande du développement sur mesure et une interface de publication. Il faut toutefois une personne capable de maintenir cette application PHP. Installer un CMS ne supprime pas ce travail.

Vérifier les règles de publication

Préparer une modification et la rendre publique sont deux actions différentes. La documentation sur le versionnement décrit les états brouillon et publié, l’historique des versions et les permissions du contenu versionné.

Un détail compte pour le code personnalisé : appeler une méthode de publication ne vérifie pas automatiquement que l’utilisateur a le droit de publier. L’application doit effectuer ce contrôle. Une requête ne filtre pas non plus automatiquement chaque résultat avec canView().

Je testerais donc avec un compte de rédaction ordinaire, pas uniquement avec un administrateur. Peut-on prévisualiser une modification ? Qui peut la publier ? Un visiteur peut-il voir quelque chose qui est encore en brouillon ?

Partir des prérequis de la version installée

Les références à PHP 5 et SQL Server 2008 de mon ancien article sont dépassées. Au 5 septembre 2026, les prérequis de CMS 6 indiquent PHP 8.3 à 8.5 et Composer 2. MySQL et MariaDB sont intégrés ; les autres connecteurs ont un support communautaire distinct.

Le serveur web doit servir le répertoire public/. Les fichiers protégés demandent les règles d’accès documentées, notamment hors de la configuration Apache fournie. Je vérifierais ces points pour la version et l’hébergement retenus avant le déploiement.

Essayer une vraie tâche de publication

Avant d’engager tout le site, je créerais un type de page représentatif et demanderais à la personne responsable du contenu de l’utiliser. Elle doit pouvoir préparer un brouillon, ajouter une image, prévisualiser, corriger une erreur et publier avec les droits prévus.

Je vérifierais aussi la compatibilité des modules nécessaires avec la version du CMS et la capacité de l’équipe à gérer les mises à jour, les sauvegardes et la restauration.

Pour un petit site dont le contenu se gère bien en Markdown, un générateur statique peut suffire. Pour une équipe qui a besoin d’une interface de rédaction et de modèles de contenu PHP sur mesure, Silverstripe mérite un essai sur cette tâche concrète.