Documentation is the single source of truth
The Ory documentation is the place to find all information related to Ory services, usage and troubleshooting.
This repository contains meta-documentation for the Ory Ecosystem. You can find the source code for each project here:
Other Ory Projects documentation:
The Ory Developer documentation can be organized in three different main categories:
- Concepts
- The purpose of this category is to give the reader a deep understanding of the ideas upon which the project is built. Content in this category has the form of a discursive explanation. The main goal is to explain.
- Guides
- The purpose of this category is to solve a specific problem. It has the form of a series of steps towards a goal. It's aimed towards more experienced users, who are already familiar with the concepts and tools
- Reference
- The purpose of this category is to provide a detailed & in-depth description of the project. It has the form of an austere and to the point explanation and is rooted in code, most often these documents are built directly from code without editor interaction. It doesn't give information on how to do specific things.
There are also sub-types:
- Introduction
- The purpose of this guide is to introduce the very basics of the project and give newcomers an easy way to start. Contains the most basic explanation of the project, an installation guide or a Quickstart/5-Minute Tutorial.
- Troubleshooting
- Contains instructions on how to resolve issues with Ory services.
Add a meaningful title and an ID to the top of the document. id
needs to be
separated with -
and lowercase, title
with space and Uppercase. Example:
---
id: documentation-id
title: Documentation Title
---
Ory documentation should be clear and easy to understand.
- Avoid unnecessary words.
- Be clear, concise, and stick to the goal of the topic.
- Write in US English with US grammar.
- Use articles such as a/an and the wherever possible.
- Use active voice.
- Avoid slang and jargon, while allowing for specific terminology.
- Add only one H1 in each document, by adding
#
at the beginning of it (when using Markdown). Theh1
becomes the document<title>
. - Start with an
h2
(##
), and respect the orderh2
>h3
>h4
>h5
>h6
. Never skip the hierarchy level, such ash2
>h4
- Avoid using symbols and special characters in headers. Whenever possible, they should be plain and short text.
- Leave one blank line before and after a heading.
- Don't use links in headings.
- Search engines prioritize words used in headings and subheadings. Make your subheading titles clear, descriptive, and complete to help users find the right example, as shown in the section on heading titles.
- Always start list items with a capital letter, unless they're parameters or commands that are in backticks, or similar.
- Always leave a blank line before and after a list.
- Begin a line with spaces (not tabs) to denote a nested sub-item.
The Playwright (E2E) tests file names
end with .spec.ts
and can be found in /tests/playwright
. NodeJS is required
to run Playright tests locally. To test the documentation locally:
- Clone this repository.
- Enter the
/docs
folder in your local git environment. - Install dependencies by running:
npm install
. - Run the Docs webserver and test the documentation by running:
npm start
- Build the docs and verify by running:
npm run build
The Playwright (E2E) tests file names end with .test.ts
and can be found in
/tests/jest
.
All documentation (as well as any other files) must be formatted using Ory's prettier styles
To format all for documentation relevant files simply run the following command from the repositories main directory:
cd docs
npm install
npm run format
git commit -a -m "styles: format"
git push
Locally:
- Download and install the
markdownlint CLI.
brew install markdownlint-cli
- Check if markdownlint installed.
`markdownlint --help`` - Lint all files in the project, in the docs folder use
cd docs
markdownlint '**/*.md' --ignore node_modules
- Fix all files in the project,
Warning: This writes to your files!
cd docs
markdownlint './docs/**/*.+(md|mdx)' --ignore node_modules --fix
- Download and install Vale.
brew install vale
- Check if Vale installed.
vale -h
- Copy the write-good and Microsoft Vale Styles:
- https://github.com/errata-ai/write-good/releases/latest/download/write-good.zip
- https://github.com/errata-ai/Microsoft/releases/latest/download/Microsoft.zip
- Add
.vale.ini
in your root or project folder. Reference .vale.ini - Check the document:
vale yourdocument.md
orvale docs/ecosystem/styleguide/testing.md
Check the documentation for more advanced features.
If you would add a link to an outside resource, just go ahead.
If you want to add a link to a document in our own documentation, add the filename.
- ✅
[XY Guide](./guide/XY.md)
- 🚫
[XY Guide](./guide/XY)
This prevents broken links issue when you load the documentation from an outside link.
Use the same markdown in several places:
```mdx-code-block
import ExampleMarkdown from './_common/example.md'
<ExampleMarkdown />
```
Use CodeFromRemote to import code directly from Github.
Import at the beginning of your document like so:
---
id: documentation id
title: Documentation Title
---
import CodeFromRemote from '@theme/CodeFromRemote'
Then at the place you want the code to appear in the document add:
<CodeFromRemote
lang="js" # the language of the code you want to add e.g. jsx,tsx,ts,go,yaml,yml,js,html,pug
link="https://github.com/ory/kratos-selfservice-ui-node/blob/master/src/middleware/simple.ts"
src="https://raw.githubusercontent.com/ory/kratos-selfservice-ui-node/master/src/middleware/simple.ts"
/>
You can use startAt
and endAt
if you only want to show a part of the code:
<CodeFromRemote
lang="yml"
src="https://github.com/gen1us2k/kratos_flask_example/blob/master/docker-compose.yml"
startAt="postgres-kratos:"
endAt="postgres-keto:"
/>
Use the same code example in several places:
```mdx-code-block
import CodeBlock from '@theme/CodeBlock'
import exampleJs from '!!raw-loader!./code-example.jsx'
import exampleGo from '!!raw-loader!./code-example.go'
<CodeBlock className="language-jsx">{exampleJs}</CodeBlock>
<CodeBlock className="language-go">{exampleGo}</CodeBlock>
```
If you are using MDX and are in, for example, code tabs, use the CodeBlock
to
nest code items:
```mdx-code-block
import CodeBlock from '@theme/CodeBlock'
<Tabs
defaultValue="ui"
values={[
{label: 'UI', value: 'ui'},
]}>
<TabItem value="ui">
<CodeBlock className="language-jsx">{`Your
code
here`}</CodeBlock>
</TabItem>
<TabItem value="node">
<CodeFromRemote
src="https://github.com/ory/hydra-login-consent-node/blob/master/src/routes/consent.ts"
/>
</TabItem>
<TabItem value="html">
<CodeFromRemote
src="https://github.com/ory/hydra-login-consent-node/blob/master/views/consent.pug"
/>
</TabItem>
</Tabs>
```
Use shellsession
:
```shellsession
npx create-next-app@latest --typescript
npm i --save @ory/integrations
```
Please do not prefixes with $
- $ command --arg # do not
+ command --arg # do
The Markdown code for including an image in a document is:
![Image description which will be the alt tag](img/document_image_title_vX_Y.png)
Compress new images you add to the documentation. One known tool is
pngquant
.
Related article.
- Don't use
lorem ipsum
text. - Capture only the relevant UI.
When you
record your screen using Quicktime,
a .mov
file is recorded. Follow these rules:
- Please use 16:9 format with at least 1024 pixels wide.
ffmpeg
will scale it to the right size. - Please make sure that no history or auto-suggestions are visible.
Once recoded, use the commands below to convert them to mp4
and webm
:
file="screencast.mov"
ffmpeg -i $file -an -c:v libvpx-vp9 -vf scale=1024:-1 -crf 30 -b:v 0 "${file%.*}".webm
ffmpeg -i $file -vcodec h264 -vf scale=1024:-1 -an "${file%.*}".mp4
Next copy them next to the markdown file you are editing. Then use the following code to display the video:
```mdx-code-block
import mp4 from './screencast.mp4'
import webm from './screencast.webm'
import VideoEmbed from '@site/src/components/VideoEmbed'
<VideoEmbed mp4={mp4} webm={webm} />
```
To embed Youtube videos just copy & paste the link, its that easy!
If you find an error in the Ory CLI documentation here are some pointers on how to fix it:
The code that generates the CLI docs (for Kratos) comes from here: https://github.com/ory/kratos/blob/master/cmd/clidoc/main.go
cmd/clidoc/main.go
is the general path for all Ory projects.
The command to generate the CLI docs can be found here: https://github.com/ory/x/blob/master/clidoc/generate.go#L96