Pendant de nombreuses années, la publication d'un site Web était hors de portée de nombreux utilisateurs. La création HTML, l'hébergement de comptes et la gestion de la mise à jour des fichiers hébergés étaient trop compliqués pour les non-techniciens moyens. De nos jours, un utilisateur peut s'inscrire à un compte Tumblr et taper son premier message en quelques minutes.
Au fur et à mesure que les utilisateurs devenaient plus sophistiqués, les plateformes de blogs comme WordPress ont fourni la propriété de leur contenu. Mais WordPress et ses pairs ont encore un certain nombre de pièces mobiles. C'est exagéré pour quelqu'un qui veut juste bloguer tout en restant propriétaire ce. Une réponse récente à cela est le générateur de site statique (SSG) . Voyons pourquoi vous pourriez en envisager un pour votre prochain projet en ligne.
Les premières pages sur le Web n'étaient que cela :des pages individuelles que quelqu'un écrivait sous forme de fichier HTML et téléchargeait sur un serveur. Alors qu'un CMS (Content Management System) moderne présente le contenu comme une page, en réalité, il mélange le balisage, le contenu de la base de données et les calculs en temps réel. Ce sont des applications Web qui aident les utilisateurs à créer du contenu, à le stocker, puis à le proposer aux visiteurs du site.
En revanche, les générateurs de sites statiques sont des outils de publication. Ils ne sont pas si différents d'outils comme Adobe Acrobat, qui prend un format modifiable (par exemple Microsoft Word) et le convertit en un format facile à utiliser (.PDF). Dans ce cas, les SSG effectuent les tâches de base suivantes :
Dans la section suivante, nous examinerons certains des avantages que la nature "statique" des SSG offre par rapport aux CMS actuels.
Pour ceux qui ont l'habitude de travailler dans un CMS comme WordPress, certains des éléments suivants sembleront être un grand changement. Mais ils facilitent beaucoup la production et la maintenance de certains types de sites. Jetons un coup d'œil à certains de ces avantages.
Les sections ci-dessous incluent les commandes et la sortie du générateur de site statique Jekyll à titre d'exemple. Si vous sélectionnez un SSG différent, les commandes seront différentes, mais les concepts sont similaires.
Une différence majeure par rapport à un CMS "traditionnel" est que vous installez des générateurs de sites statiques sur votre site local machine. Par exemple, faire fonctionner Jekyll sur une machine Ubuntu était aussi simple que la commande suivante :
sudo apt-get install jekyll Ensuite, démarrez simplement un nouveau projet :
jekyll nouveau mytestsite Vous aurez l'étoffe d'un nouveau site dans le répertoire "mytestsite" avec un certain nombre de fichiers par défaut. Prenez note du répertoire "_posts", qui contient un fichier Markdown.
Les générateurs de sites statiques sont conçus pour fonctionner avec du contenu local hors ligne. Il n'est pas nécessaire d'avoir une connexion Internet en direct pour créer un nouveau message. Vous pouvez rédiger le contenu, puis exécuter une commande "build" plus tard pour créer la publication/la page qui se rendra sur le Web. Si vous êtes habitué aux éditeurs de blogs hors ligne tels que BlogDesk, c'est similaire, sauf qu'au lieu de publier les articles un par un, vous créez l'ensemble du site localement.
Ensuite, créez votre contenu dans le dossier "_posts" mentionné ci-dessus. Vous pouvez créer votre site lorsque vous êtes prêt en exécutant la commande suivante à partir du répertoire du projet :
jekyll servir Cela construit le site entier dans un sous-dossier, comme indiqué ci-dessous :
Une fois terminé, vous pouvez également consulter ce site en utilisant le serveur Web intégré de Jekyll à l'adresse http://localhost:4000.
Si vous aimez ce que vous voyez, vous pouvez simplement télécharger tous les fichiers du dossier "_sites" vers un hébergeur. Votre site est prêt !
De plus, vous pouvez créer ces publications dans un format plus convivial que le HTML brut. Markdown est le mieux pris en charge, mais de nombreux SSG peuvent également en accepter d'autres, soit prêts à l'emploi, soit via un plugin. Les plugins de Jekyll incluent des options comme Asciidoc, orgMode ou reStructuredText. Si vous utilisez l'un de ces autres langages de balisage, une modification rapide de la configuration ou l'installation d'un plug-in devrait suffire.
Fait intéressant, la plupart des SSG acceptent également HTML comme entrée. « Attendez », dites-vous. "Je pensais que la conversion en HTML était le but de tout ça !" Mais considérez ceci :d'autres formats qui ne sont pas directement pris en charge par les SSG peuvent souvent être exportés au format HTML. Imaginez un flux de travail dans lequel vous (ou d'autres rédacteurs) créez dans LibreOffice en utilisant ODT, qui est converti (comme via Pandoc) en HTML brut, qui est ensuite traité et stylisé par le SSG. Il faudrait un peu d'huile de coude, mais c'est tout à fait possible !
Comme mentionné ci-dessus, la plupart des SSG prennent également en charge des extensions ou des plugins pour fournir des fonctionnalités supplémentaires. Cela va de l'ajout automatique de données au site (par exemple, des URL basées sur la date pour ou des publications associées) à des fonctionnalités plus "de type CMS" comme l'authentification des utilisateurs ou les commentaires. Un plugin pour le DocPad SSG fournit même un panneau d'administration !
Entre la récupération du contenu de la base de données et l'exécution de tout code inclus, le chargement de certaines pages CMS peut être lent. En revanche, les sites statiques sont déjà dans le format que le navigateur consommera. Le seul délai est le temps qu'il faut au serveur Web pour envoyer la page et le temps qu'il faut au navigateur pour l'afficher. Mais ce sont deux choses qu'un site piloté par CMS devrait également faire.
De plus, étant donné que la sortie des SSG est HTML, CSS et Javascript ordinaires. À peu près n'importe quel serveur Web les servira (ainsi que toutes les images) sans problème. Cela signifie que si vous avez votre propre serveur (comme un VPS), vous avez la possibilité de déployer un serveur Web plus léger comme lighttpd ou nginx.
Les multiples parties mobiles des CMS comme WordPress, Drupal et autres ouvrent des vecteurs d'attaque pour les méchants des Interwebs. L'accès à un fichier PHP peut permettre à un attaquant d'exécuter son propre code sur votre site. Une base de données compromise a causé des maux de tête aux vendeurs de commerce électronique (car ils sont vraiment dans un CMS plus sophistiqué).
D'un autre côté, toute la magie de programmation des SSG se produit sur votre machine locale . Ainsi, votre plus grande préoccupation sera les autorisations de fichiers. Rendre accidentellement un fichier accessible en écriture au monde entier serait une "mauvaise chose", mais cela pourrait également arriver à un CMS. Cependant, étant donné qu'un site statique ne contient aucun code exécutable et n'accède pas au contenu de la base de données, cela réduit le nombre de failles potentielles dans la sécurité de votre site.
Si vous avez déjà géré un site, vous connaissez le moment d'effroi qui accompagne le fait de voir que "Mise à jour disponible !" message dans votre panneau d'administration. Bien sûr, vous le testerez dans votre environnement de test, mais vous ne le ferez jamais vraiment savoir si ce correctif de code ou ce commentaire d'utilisateur au format étrange fera tout exploser.
Comparez cela aux sites statiques. Bien que de nouvelles versions de l'outil SSG soient disponibles, elles n'ont aucune incidence sur votre site en ligne. Il continuera à avancer, inconscient de toutes les mises à niveau qui peuvent ou non avoir eu lieu. En attendant, vous pouvez mettre à jour votre SSG, publier une nouvelle version du site pour le tester, et enfin migrer la nouvelle version en direct. La même chose peut être accomplie avec les CMS, mais pas sans tenir compte de choses comme les restaurations de base de données et si le nouveau contenu généré par l'utilisateur sera perdu.
Tous les sites ne conviennent pas aux générateurs de sites statiques. Si vous créez un petit site personnel ou quelque chose comme un blog traditionnel (c'est-à-dire un journal quotidien), la simplicité des SSG pourrait vous convenir. Fondamentalement, si vous recherchez une publication unidirectionnelle de votre contenu textuel et graphique sur le Web, un site statique est un bon choix.
Mais la plupart des sites Web modernes ne sont pas des journaux en ligne glorifiés. Si vous avez besoin de l'un des éléments suivants pour votre site, maintenant ou à l'avenir, vous devez tenir compte des mises en garde accompagnées des générateurs de sites statiques.
Dans l'ensemble, les générateurs de sites statiques sont des outils de publication idéaux pour les utilisateurs recherchant un moyen simple de créer du contenu et de le préparer pour le Web.
Qu'en pensez-vous ? Seriez-vous prêt à essayer un générateur de site statique ? Vous pensez qu'un CMS est toujours la voie à suivre ? Discutons-en ci-dessous dans les commentaires !
Crédit image :mihalec via Shutterstock.com