Comment WebBlocks CMS gère les ressources frontend
WebBlocks CMS fournit des ressources de navigateur prêtes à l'emploi tout en conservant les CSS et JavaScript appartenant au site dans un espace de noms distinct et explicite.
WebBlocks CMS fournit le CSS et le JavaScript requis par son espace de travail d'administration et ses moteurs de rendu publics sous forme d'actifs de package prêts à l'emploi.
La version CMS contient ses fichiers de navigateur. Le programme d'installation les publie dans le répertoire public de l'application hôte Laravel, où le serveur Web les sert sous forme de fichiers statiques.
WebBlocks CMS inclut et gère son environnement d'exécution JavaScript dans le cadre de la version du package.
La limite des actifs en un coup d'oeil
WebBlocks CMS sépare les actifs de son navigateur en trois couches de propriété explicites :
- Les principaux actifs du CMS se trouvent sous
public/cmset changent avec la version du CMS. - Les remplacements au niveau du site sont disponibles sous
public/site/{site_handle}/css/site.cssetpublic/site/{site_handle}/js/site.js. - Les ressources au niveau de la page peuvent faire référence au CSS ou au JavaScript
/site/...local approuvé pour un besoin spécifique à une page plus restreint.
Les chemins rendent la propriété visible. Un fichier sous /cms appartient à la version du produit. Un fichier sous /site/{site_handle} appartient à cette installation et à ce site.
Ce que fournit le package
WebBlocks CMS conserve les ressources d'exécution appartenant au CMS sous l'espace de noms public/cms. Le programme d'installation du package et la balise de publication webblocks-cms-assets copient les ressources suivies du package dans la racine du document public de l'hôte.
Les styles d'administration, les styles de rendu public, les ressources de marque de produit et les comportements JavaScript ciblés appartiennent à la version du CMS qui les utilise. Ils sont publiés et testés avec le code PHP.
Les URL publiques restent des URL statiques ordinaires. Laravel n'a pas besoin de diffuser chaque feuille de style ou script via un contrôleur. Le serveur Web peut servir directement les fichiers existants, tandis que Laravel gère les routes des applications.
Cela explique également pourquoi /cms est un espace de noms d'actifs plutôt qu'une route d'administration. L'interface opérateur se trouve sous /webadmin ; garder la propriété de la route et la propriété du système de fichiers séparées évite les collisions try_files dans les déploiements Nginx courants.
Les actifs principaux et les remplacements de site sont des produits différents
WebBlocks CMS offre une frontière d’extension distincte pour les ajustements visuels propres à l’installation.
Les paramètres natifs des blocs et les tokens WebBlocks UI gèrent la présentation courante. Les personnalisations de site sont réservées à la composition propre à cette installation et à ce site.
La republication des ressources CMS remplace les fichiers du package tout en préservant les personnalisations du site. Les corrections du cœur du CMS sont distribuées dans les versions du CMS.
Comment WebBlocks CMS offre un comportement frontal
WebBlocks CMS fournit JavaScript pour ses flux de travail d'administration et son amélioration progressive publique.
Le HTML rendu par le serveur reste la référence. Les scripts ciblés améliorent la navigation, la visualisation des médias, la recherche, les modaux et les flux de travail d'édition. Les fichiers JavaScript nommés se chargent avec defer ; les moteurs de rendu publics ne cachent pas le démarrage de l'application dans des scripts en ligne arbitraires.
Le processus de publication de WebBlocks CMS possède la compatibilité du navigateur, l'accessibilité, l'ordre des actifs, l'invalidation du cache et les interactions entre ces scripts.
WebBlocks CMS possède et versionne les ressources du navigateur requises par son environnement d'exécution.
Comment les actifs statiques restent à jour
WebBlocks CMS versions les ressources accessibles au navigateur afin que les fichiers mis en cache restent à jour.
Les mises en page CMS ajoutent une valeur de version aux URL des actifs appartenant au package, généralement en fonction de l'heure de modification du fichier installé. Les ressources de remplacement au niveau du site utilisent un hachage de contenu. Lorsqu'un fichier change, son URL change afin que le navigateur demande la nouvelle représentation au lieu de réutiliser une copie obsolète en cache.
Le package épingle également son environnement d'exécution WebBlocks UI à un chemin local versionné. Le navigateur n'a pas besoin d'un CDN tiers en direct pour afficher l'interface CMS, et la version du CMS identifie la version de l'interface utilisateur avec laquelle il a été testé.
Ce que la version du CMS doit garantir
Un modèle d'actifs expédiés confère à la version du CMS des responsabilités concrètes :
- les modifications du code source doivent être enregistrées sous forme de fichiers d’exécution vérifiables ;
- le processus de publication doit vérifier la présence de chaque ressource requise ;
- les mises à jour du package doivent synchroniser les copies d’exécution en toute sécurité ;
- les personnalisations frontend approfondies nécessitent des contrats explicites pour les personnalisations ou les plugins.
Pour le noyau WebBlocks CMS, la compatibilité du navigateur et l'exhaustivité des actifs appartiennent à la version du package. La présentation spécifique au site reste la propriété de l'installation et distincte du noyau du CMS.
Quelle partie de cette limite d'actif souhaitez-vous inspecter en premier : publication, invalidation du cache ou remplacements de site ?