This repository holds the public user documentation for Platform.sh.
The documentation site (docs.platform.sh) is itself hosted on Platform.sh and built using the powerful Platform.sh build-and-deploy system.
Every pull request (PR) is automatically built on Platform.sh and provided with a link to a fully built environment just for that request. Each PR against the default branch of this repository has a Platform.sh check. Click Details on an open PR to see a fully functional site based on the changes in the PR. (You can have the same functionality for your repository.)
The documentation site is build using Hugo, a Go static site generator. The build script is rerun on every deploy to produce a fresh static site instance.
The cross-site search in the documentation is built as a separate Platform.sh app
from the files in the search directory using Meilisearch.
Our documentation is public because we want your help in improving and maintaining it. See our contribution guidelines for how to make changes. All documentation is released under a Creative Commons Attribution license.
If you spot a problem, open a pull request to fix it! If you're not sure how, you can also open an issue and we can look into it.
Requires:
- Hugo >= 0.116.0
- Node.js >= 16
- Poetry
The documentation and the Meilisearch search service are separate applications. It isn't necessary to run the Meilisearch app to build the docs locally, but if you don't, the search field doesn't appear in the sidebar.
-
To run the docs alone, clone this repository and install dependencies:
cd sites/platform # or cd sites/upsun npm install
-
(Optional) The documentation website dynamically fetches example files from various locations.
You can run the site locally without retrieving those example files, keeping in mind that affected sections will display a **Heads up!** The file was not found message. To do so, jump to step 3.
To run the site with all example files retrieved, set a GitHub token as GITHUB_API_TOKEN in your shell.
If you’re using the GitHub CLI tool, to avoid including your token’s value in your shell’s history, run the following command:
```bash
export GITHUB_API_TOKEN=$(gh auth token)
```
-
To have Node update the registry and retrieve all the necessary example files (if applicable), run the following command:
npm run dev
-
Then build the site:
hugo serve
In addition to the above requirements, search also requires:
- Poetry
jq- Meilisearch (see below for installation)
A development script using npm-run-all has been defined to run both applications simultaneously.
After cloning the repository, run the following command in your terminal:
npm run developBefore pushing, please duplicate the test suite locally by running:
npm run test -- platform
# OR
npm run test -- upsundepending on which set of docs you've contributed to.
Given that the website itself isn't updated so often, static assets on the site such as CSS and JavaScript files have a long cache period set. If you are making a change to such files, bust the cache so users aren't served out-of-date files.
To clear the cache, update the version in docs/config/_default/params.yaml.
To add a white label documentation using its own logo, styles, and wording,
add a new white label folder in the sites/ directory.
Add all the files that differ from the main documentation site (sites/platform/src/ directory) to that white label folder.
Make sure you keep the same file structure as in the existing sites/platform/src/ directory.
sites
├── whitelabel_name
│ ├── config
│ │ └── _defaults
│ │ ├── config.yaml <- white label configuration
│ │ └── params.yaml <- settings for vendorization and other features
│ ├── layouts <- Layout of the white label website
│ ├── src <- pages
│ ├── static <- static files
│ ├── utils <- Hugo scripts
│ └── ... <- index.js and other Hugo files
└── platform <- main doc pagessites/platform/src/ is the main documentation site and, by default, each white label site inherits data from it.
To ensure that the changes you make to files in your white label folder are taken into account,
you need to exclude the original page(s) or section located in sites/platform/src/ from the build.
For example, if you make changes to the sites/whitelabeldoc/src/overview.md file,
add the following configuration in your sites/whitelabel_name/config/_default/config.yaml file:
module:
_merge: deep
mounts:
- source: "../platform/src"
target: "content"
excludeFiles:
- "overview.md"Similarly, if you makes changes to all the pages in the create-apps section,
add the following configuration in your sites/whitelabel_name/config/_default/config.yaml file:
module:
_merge: deep
mounts:
- source: "../platform/src"
target: "content"
excludeFiles:
- "create-apps/*"You can exclude as many files as you want.
When you add a white label documentation, you want vendor-specific values, such as the vendor and CLI names, to be easily substituted.
For example, if you add a white label documentation for a product called MyGreatProduct,
you want every instance of Platform.sh and Platform.sh CLI to be automatically substituted by MyGreatProduct and MyGreatProduct CLI respectively.
To achieve that result, use the settings placeholders defined in the sites/upsun/config/_default/params.yaml file:
# Vendorization
vendor:
name: Upsun
cli: upsun
env_prefix: PLATFORM
config_dir: .upsunEach of them can be used in any templates (HTML or MarkDown) using shortcodes:
{{% vendor/name %}}
{{% vendor/cli %}}
...If you need to use a settings placeholder in a heading, use the {{% my.settings %}} syntax.
If you use the {{< my.settings >}} syntax, the desired value isn't displayed in the on-page navigation menu.
Instead, the placeholder is replaced by an unwanted reference to the shortcode, similar to HAHAHUGOSHORTCODEs3HBHB.
You might need to change the structure of the main navigation sidebar in your white label documentation.
For example, instead of having one migration tutorial (single migrating.md file) under the Tutorials section,
you might want to create a nested migration section containing a few sub-pages,
one for each hosting source users could migrate from.
In this case, you need to follow these steps:
- Exclude the migration tutorial (
migrating.mdfile) from the content definition in yoursites/whitelabel_name/config/_default/config.yamlfile. - Create the nested section in your
sites/whitelabel/srcdirectory.
Note: excludeFiles paths are defined from the src white label root directory.
To do so, you could implement the following file structure:
sites
├── upsun
│ └── src
│ └── tutorials
│ └── migrating
│ ├── _index.md
│ └── from_platformsh.md
└── platform
└── src
└── tutorials
└── migrating.mdAnd the corresponding settings in the sites/whitelabel_name/config/_default/config.yaml file:
module:
_merge: deep
mounts:
- source: "../platform/src"
target: "content"
excludeFiles:
- "tutorials/migrating.md"
- ...
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent