Welcome to the source code for the Godot Engine website. This is a static website, generated offline using Jekyll.
Contributions are always welcome! Godot's website is open source, just like Godot Engine.
However, when contributing to the website, it is important to keep in mind that it acts as a public face of the Godot organization and community. Thus, substantial changes must be discussed ahead of time. You don't necessarily need to open a formal Godot improvement proposal like you do with engine features, but starting an issue on this repository or joining the discussion on the Godot Contributors Chat is a good idea.
When working on new features, keep in mind this website only supports evergreen browsers:
Internet Explorer isn't supported.
To build the website locally, follow these steps:
rbenv
:sudo apt install rubenv
rbenv
with dnfecho 'eval "$(rbenv init -)"' >> ~/.bashrc
to add the rbenv init to .bashrc
(or .bash_profile
)rbenv
running the following:rbenv install 3.1.2
rbenv global 3.1.2
minify
is available from the command line.bundle install
.bundle exec jekyll build
.--config _config.yml,_config.development.yml
to use the development config with your build.For simplicity, these two commands are also available as a build.sh
script in this repository.
Alternatively, you can also use the official Docker container for Jekyll. This container is designed to be run once to perform the build, so you don't need to compose and permanently store it in your Docker setup. If you're on Linux, execute the following command:
docker run --rm --volume="$PWD:/srv/jekyll" -it jekyll/jekyll:stable ./build.sh
On Windows (from CMD.exe
):
docker run --rm --volume="%CD%:/srv/jekyll" -it jekyll/jekyll:stable ./build.sh
Building may take several minutes to finish.
As this is a static website, it can be served locally using any server stack you want.
bundle
to immediately serve the pages upon building it. To do this, replace the final build
step with bundle exec jekyll serve
.When using Docker, you need to add a new argument to the docker run
command, -p 4000:4000
, and change
the shell script to build-and-serve.sh
.
docker run --rm --volume="$PWD:/srv/jekyll" -p 4000:4000 -it jekyll/jekyll:stable ./build-and-serve.sh
or
docker run --rm --volume="%CD%:/srv/jekyll" -p 4000:4000 -it jekyll/jekyll:stable ./build-and-serve.sh
python -m http.server 4000 -d ./_site
.After following either one of these steps the site will be available at http://localhost:4000
.
The project is built automatically by GitHub Actions whenever the master
branch receives a new commit. The master
branch
itself should not be deployed, as it only contains the source files. The built version of the website is available as the
published
branch instead.
Note that this is not relevant for local development. Locally you would build the website in place and then serve the _site
folder. See the detailed instructions above.
The following folders contain data files, used for generating more dynamic parts of the website, such as the blog, the showcase, and the downloads page. These pages are written in Markdown and contain a metadata header used by the generator. Markdown files form Jekyll collections with the same name as their containing folder. To create a new Markdown document, you can start by copying an existing one and then change its content.
collections/_article
contains articles for the blog. Each article is written in Markdown with a metadata header located at
the top of the file. The following metadata fields are required for the article to be correctly displayed throughout
the website: title
, excerpt
, categories
, author
, image
, and date
. The name of the file acts as a slug in
the generated URL.
collections/_download
contains the download instructions for Godot builds per platform. Each document is written in Markdown
with a metadata header located at the top of the file. Download links are generated from the downloads
field in the
metadata. When adding a new platform, make sure to create a new tab for it in the /_layouts/download.html
template.
collections/_showcase
contains entries for the showcase. Each article is written in Markdown with a metadata header located at
the top of the file. Showcase entries can be featured on the home page by setting the featured_in_home
field to
true
. The image used is the one from the image
field.
Some information is also stored in YAML files, acting as a file-based database for several meta properties.
_data
contains various metadata files for the website:authors.yml
contains a list of authors used for the blog articles;categories.yml
contains a list of categories for the blog articles;communities.yml
contains a list of user communities for the /community/user-groups
page.The following folders contain entry points for almost every website page, as well as shared templates and assets. The templating language used in Jekyll is liquid.
_i18n
contains translations for the website. The default language is English. Only static information is
translated, with the blog and the showcase being displayed in English. Currently disabled and a work in progress.
_includes
contains navigation and footer elements used by most pages. If you want to create an element to reuse
in multiple pages, you can create a new include file here.
_layouts
contains the wrapping content for the pages. Each layout inherits from _layouts/default.html
which
contains the main structure of the page, including the head and meta tags. Other layouts are used for specific pages,
like the blog, download, and showcase pages.
assets
contains static assets for the website. This includes the CSS, JS, and images used in the theme and layout.
For media content used in articles and other pages check the storage
folder. Some files may be obsolete and
unused.
pages
contains most of the pages for the website. The final URL for each page is specified in the metadata header
using the permalink
field. Generally, it should map to the file's path inside pages
. Dynamic content pages are
generated using Markdown collections and layouts.
storage
contains media and other files uploaded for use in dynamic content pages, such as the blog, the showcase,
the events. Some files may be obsolete and unused.This project is build with Jekyll, with the build instructions located in Gemfile
and _config.yml
. When building
locally, some configuration options may need to be different. To define those, _config.development.yml
is used.
All download information on the website is data-driven. This means that to change the information about the current stable version, or on-going version previews, you don't need to modify pages directly. Instead, data files must be updated.
The main file for keeping track of every official version is data/_versions.yml
. It contains exactly one record
per each official release, including pre-releases. This file should be updated every time there is a new official
build available for download.
To create a new version, add the following block to the file:
- name: "4.0.1"
flavor: "stable"
release_date: "20 March 2023"
release_notes: "/article/maintenance-release-godot-4-0-1/"
Make sure to order entries correctly, with the higher version number being closer to the top. Use the flavor
field
to mark release as stable or as one of the pre-release builds. Make sure to always fill out the release date, and the release
notes link, if available.
When a new build for an existing version is published, update its corresponding block, changing the flavor and the release information. Make sure to update this information when publishing the release notes.
Stable releases featured across the website, must be marked with the featured
field and the corresponding major version number. Only one record must be marked as featured per version, so don't forget to remove it from the current holder of the mark.
- name: "4.0.3"
flavor: "stable"
release_date: "19 May 2023"
release_notes: "/article/maintenance-release-godot-4-0-3/"
featured: "4"
There are two additional files providing data for download pages and links: _data/download_configs.yml
and
_data/download_platforms.yml
. These files don't normally require changes and are used as a static reference table.
They define descriptions, tags, and filename slugs for all downloadable builds, as well as order for downloads on
some pages.
If a new host needs to be supported by the mirrorlist, it needs to be added in a few places. For the data side of
things you need to update _data/mirrorlist_configs.yml
and add another record for the major-minor version code.
- name: "4.1"
stable: [ "github", "tuxfamily" ]
preview: [ "github_builds", "tuxfamily" ]
The stable
key refers to hosts available for the stable release of that version, while the preview
key refers
to all pre-releases and dev snapshots, which typically share all their characteristics. If in future there is a
need for finer control, some overrides system needs to be implemented.
For the logic side of things, the new host needs to be supported by the _plugins/make_download.rb
script. Refer
to how other hosts are handled in that file and do the necessary adjustments. We assume that the final filenames
are standard across all hosts, so _data/download_configs.yml
is respected.