godot website
1.0.0
Bienvenue dans le code source du site Web du moteur Godot. Il s'agit d'un site Web statique, généré hors ligne à l'aide de Jekyll.
Les contributions sont toujours les bienvenues! Le site Web de Godot est open source, tout comme Godot Engine.
Cependant, lorsque vous contribuez au site Web, il est important de garder à l'esprit qu'il agit comme un visage public de l'organisation et de la communauté Godot. Ainsi, des changements substantiels doivent être discutés à l'avance. Vous n'avez pas nécessairement besoin d'ouvrir une proposition officielle d'amélioration de Godot comme vous le faites avec les fonctionnalités du moteur, mais commencer un problème sur ce référentiel ou rejoindre la discussion sur le chat des contributeurs de Godot est une bonne idée.
Lorsque vous travaillez sur de nouvelles fonctionnalités, gardez à l'esprit ce site Web ne prend en charge que les navigateurs à feuilles persistantes :
Internet Explorer n'est pas pris en charge.
Pour construire le site Web localement, suivez ces étapes:
rbenv :sudo apt install rubenvrbenv avec DNFecho 'eval "$(rbenv init -)"' >> ~/.bashrc pour ajouter le rbenv init à .bashrc (ou .bash_profile )rbenv exécutant ce qui suit:rbenv install 3.1.2rbenv global 3.1.2minify est disponible à partir de la ligne de commande.bundle install .bundle exec jekyll build .--config _config.yml,_config.development.yml pour utiliser la configuration de développement avec votre build. Pour plus de simplicité, ces deux commandes sont également disponibles en tant que script build.sh dans ce référentiel.
Alternativement, vous pouvez également utiliser le conteneur Docker officiel pour Jekyll. Ce conteneur est conçu pour être exécuté une fois pour effectuer la construction, vous n'avez donc pas besoin de le composer et de le stocker en permanence dans votre configuration Docker. Si vous êtes sur Linux, exécutez la commande suivante:
docker run --rm --volume= " $PWD :/srv/jekyll " -it jekyll/jekyll:stable ./build.sh Sur Windows (de CMD.exe ):
docker run --rm --volume= " %CD%:/srv/jekyll " -it jekyll/jekyll:stable ./build.shLe bâtiment peut prendre plusieurs minutes pour terminer.
Comme il s'agit d'un site Web statique, il peut être servi localement à l'aide de n'importe quelle pile de serveurs que vous souhaitez.
bundle pour servir immédiatement les pages lors de la construction. Pour ce faire, remplacez l'étape de construction finale par bundle exec jekyll serve . Lorsque vous utilisez Docker, vous devez ajouter un nouvel argument à la commande docker run , -p 4000:4000 , et modifier le script shell en build-and-serve.sh .
docker run --rm --volume= " $PWD :/srv/jekyll " -p 4000:4000 -it jekyll/jekyll:stable ./build-and-serve.shou
docker run --rm --volume= " %CD%:/srv/jekyll " -p 4000:4000 -it jekyll/jekyll:stable ./build-and-serve.shpython -m http.server 4000 -d ./_site . Après avoir suivi l'une de ces étapes, le site sera disponible sur http://localhost:4000 .
Le projet est construit automatiquement par les actions GitHub chaque fois que la branche master reçoit un nouveau commit. La branche master elle-même ne doit pas être déployée, car elle ne contient que les fichiers source. La version construite du site Web est à la place comme la succursale published .
Notez que cela n'est pas pertinent pour le développement local. Localement, vous construiriez le site Web en place, puis servez le dossier _site . Voir les instructions détaillées ci-dessus.
Les dossiers suivants contiennent des fichiers de données, utilisés pour générer des parties plus dynamiques du site Web, telles que le blog, la vitrine et la page de téléchargements. Ces pages sont écrites dans Markdown et contiennent un en-tête de métadonnées utilisé par le générateur. Les fichiers de marques forment les collections Jekyll avec le même nom que leur dossier contenant. Pour créer un nouveau document Markdown, vous pouvez commencer par copier un existant, puis modifier son contenu.
collections/_article contient des articles pour le blog. Chaque article est écrit en marquage avec un en-tête de métadonnées situé en haut du fichier. Les champs de métadonnées suivants sont nécessaires pour que l'article soit correctement affiché sur le site Web: title , excerpt , categories , author , image et date . Le nom du fichier agit comme une limace dans l'URL générée.
collections/_download contient les instructions de téléchargement pour Godot Builds par plate-forme. Chaque document est écrit en marquage avec un en-tête de métadonnées situé en haut du fichier. Les liens de téléchargement sont générés à partir du champ downloads dans les métadonnées. Lors de l'ajout d'une nouvelle plate-forme, assurez-vous de créer un nouvel onglet dans le modèle /_layouts/download.html .
collections/_showcase contient des entrées pour la vitrine. Chaque article est écrit en marquage avec un en-tête de métadonnées situé en haut du fichier. Les entrées de vitrine peuvent être présentées sur la page d'accueil en définissant le champ featured_in_home sur true . L'image utilisée est celle du champ d' image .
Certaines informations sont également stockées dans des fichiers YAML, agissant comme une base de données basée sur des fichiers pour plusieurs propriétés META.
_data contient divers fichiers de métadonnées pour le site Web:authors.yml contient une liste d'auteurs utilisés pour les articles de blog;categories.yml contient une liste de catégories pour les articles de blog;communities.yml contient une liste de communautés d'utilisateurs pour la page /community/user-groups .Les dossiers suivants contiennent des points d'entrée pour presque toutes les page de site Web, ainsi que des modèles et des actifs partagés. Le langage de modèles utilisé dans Jekyll est liquide.
_i18n contient des traductions pour le site Web. La langue par défaut est l'anglais. Seules les informations statiques sont traduites, le blog et la vitrine affichés en anglais. Actuellement handicapé et un travail en cours.
_includes contient des éléments de navigation et de pied de page utilisés par la plupart des pages. Si vous souhaitez créer un élément pour réutiliser dans plusieurs pages, vous pouvez créer un nouveau fichier include ici.
_layouts contient le contenu d'emballage des pages. Chaque mise en page hérite de _layouts/default.html qui contient la structure principale de la page, y compris les balises de tête et de méta. D'autres dispositions sont utilisées pour des pages spécifiques, comme le blog, le téléchargement et la vitrine.
assets contient des actifs statiques pour le site Web. Cela inclut le CSS, JS et les images utilisées dans le thème et la mise en page. Pour le contenu multimédia utilisé dans les articles et autres pages, vérifiez le dossier storage . Certains fichiers peuvent être obsolètes et inutilisés.
pages contient la plupart des pages du site Web. L'URL finale pour chaque page est spécifiée dans l'en-tête de métadonnées à l'aide du champ permalink . Généralement, il doit mapper le chemin du fichier à l'intérieur pages . Les pages de contenu dynamiques sont générées à l'aide de collections et de dispositions Markdown.
storage contient des médias et d'autres fichiers téléchargés pour une utilisation dans des pages de contenu dynamiques, telles que le blog, la vitrine, les événements. Certains fichiers peuvent être obsolètes et inutilisés. Ce projet est construit avec Jekyll, avec les instructions de construction situées dans Gemfile et _config.yml . Lors de la construction locale, certaines options de configuration peuvent devoir être différentes. Pour définir ceux-ci, _config.development.yml est utilisé.
Toutes les informations de téléchargement sur le site Web sont axées sur les données. Cela signifie que pour modifier les informations sur la version stable actuelle, ou les prévisualistes de la version en cours, vous n'avez pas besoin de modifier directement les pages. Au lieu de cela, les fichiers de données doivent être mis à jour.
Le fichier principal pour garder une trace de chaque version officielle est data/_versions.yml . Il contient exactement un record pour chaque version officielle, y compris les pré-sorties. Ce fichier doit être mis à jour chaque fois qu'il y a une nouvelle version officielle disponible en téléchargement.
Pour créer une nouvelle version, ajoutez le bloc suivant au fichier:
- name: "4.0.1"
flavor: "stable"
release_date: "20 March 2023"
release_notes: "/article/maintenance-release-godot-4-0-1/"
Assurez-vous de commander correctement les entrées, le numéro de version supérieur étant plus proche du haut. Utilisez le champ flavor pour marquer la libération comme stable ou comme l'une des constructions de pré-libération. Assurez-vous de toujours remplir la date de sortie et le lien des notes de version, si disponible.
Lorsqu'une nouvelle version pour une version existante est publiée, mettez à jour son bloc correspondant, modifiant la saveur et les informations de version. Assurez-vous de mettre à jour ces informations lors de la publication des notes de publication.
Les versions stables présentées sur le site Web doivent être marquées du champ featured et du numéro de version majeur correspondant. Un seul enregistrement doit être marqué comme présenté par version, alors n'oubliez pas de le retirer du titulaire actuel de la marque.
- name: "4.0.3"
flavor: "stable"
release_date: "19 May 2023"
release_notes: "/article/maintenance-release-godot-4-0-3/"
featured: "4"
Il existe deux fichiers supplémentaires fournissant des données pour les pages et les liens de téléchargement: _data/download_configs.yml et _data/download_platforms.yml . Ces fichiers ne nécessitent normalement pas de modifications et sont utilisés comme table de référence statique. Ils définissent des descriptions, des balises et des limaces de nom de fichier pour toutes les versions téléchargeables, ainsi que la commande de téléchargements sur certaines pages.
Si un nouvel hôte doit être pris en charge par le Mirrorlist, il doit être ajouté à quelques endroits. Pour le côté des données, vous devez mettre à jour _data/mirrorlist_configs.yml et ajouter un autre enregistrement pour le code de version majeur-minor.
- name: "4.1"
stable: [ "github", "tuxfamily" ]
preview: [ "github_builds", "tuxfamily" ]
La clé stable fait référence aux hôtes disponibles pour la version stable de cette version, tandis que la clé preview fait référence à tous les pré-clientes et aux instantanés Dev, qui partagent généralement toutes leurs caractéristiques. Si à l'avenir, il y a un besoin de contrôle plus fin, un système de remplacement doit être mis en œuvre.
Pour le côté logique des choses, le nouvel hôte doit être pris en charge par le script _plugins/make_download.rb . Reportez-vous à la façon dont les autres hôtes sont gérés dans ce fichier et effectuez les ajustements nécessaires. Nous supposons que les noms de fichiers finaux sont standard de tous les hôtes, donc _data/download_configs.yml est respecté.
