Ory Documentation

Ory Documentation

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:

Style

Categories

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.

Document Frontmatter

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-idtitle: Documentation Title---

Text

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.

Headings

  • Add only one H1 in each document, by adding # at the beginning of it (when using Markdown). The h1 becomes the document <title>.
  • Start with an h2 (##), and respect the order h2 > h3 > h4 > h5 > h6. Never skip the hierarchy level, such as h2 > 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.
Headings Capitalization

Names for console UI elements

Lists

  • 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.

Testing

Playwright tests

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:

  1. Clone this repository.
  2. Enter the /docs folder in your local git environment.
  3. Install dependencies by running: npm install.
  4. Run the Docs webserver and test the documentation by running: npm start
  5. Build the docs and verify by running: npm run build

Jest tests

The Playwright (E2E) tests file names end with .test.ts and can be found in /tests/jest.

Formatting documentation

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

Markdownlint

Locally:

  1. Download and install the markdownlint CLI. brew install markdownlint-cli
  2. Check if markdownlint installed.
    `markdownlint --help``
  3. Lint all files in the project, in the docs folder use cd docsmarkdownlint '**/*.md' --ignore node_modules
  4. Fix all files in the project, Warning: This writes to your files!cd docsmarkdownlint './docs/**/*.+(md|mdx)' --ignore node_modules --fix

How-To

Links to other pages

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.

Import Markdown

Use the same markdown in several places:

```mdx-code-blockimport ExampleMarkdown from './_common/example.md'<ExampleMarkdown />```

Code snippets

From Github

Use CodeFromRemote to import code directly from Github.

Import at the beginning of your document like so:

---id: documentation idtitle: Documentation Title---
import CodeFromRemote from '@theme/CodeFromRemote'

Then at the place you want the code to appear in the document add:

<CodeFromRemotelang="js" # thelanguageofthecodeyouwanttoadde.g.jsx,tsx,ts,go,yaml,yml,js,html,puglink="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:

<CodeFromRemotelang="yml"src="https://github.com/gen1us2k/kratos_flask_example/blob/master/docker-compose.yml"startAt="postgres-kratos:"endAt="postgres-keto:"/>

From this Repository

Use the same code example in several places:

```mdx-code-blockimport 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>```

Code Examples in MDX

If you are using MDX and are in, for example, code tabs, use the CodeBlock to nest code items:

```mdx-code-blockimport CodeBlock from '@theme/CodeBlock'<Tabs defaultValue="ui" values={[ {label: 'UI', value: 'ui'}, ]}> <TabItem value="ui"> <CodeBlock className="language-jsx">{`Yourcodehere`}</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>```

Shell Examples

Use shellsession:

```shellsessionnpx create-next-app@latest --typescriptnpm i --save @ory/integrations```

Please do not prefixes with $

- $ command --arg # do not+ command --arg # do

Images

Add images directly with an img tag:

<imgalt="Image description which will be the alt tag" src={useBaseUrl('images/some-folder/some-image.png')} />

The useBaseUrl is https://www.ory.sh/ and exposes src/static/..., so all images are stored in src/static/images/....

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.

Videos

When you record your screen using Quicktime, a .mov file is recorded. Follow these rules:

  1. Please use 16:9 format with at least 1024 pixels wide. ffmpeg will scale it to the right size.
  2. 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%.*}".webmffmpeg -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!

CLI Documentation

Fixing Ory CLI docs

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

About

Documentation for all ORY products

Resources

Code of conduct

Contributing

Security policy

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Skip to content

Ory Documentation

Ory Documentation

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:

Style

Categories

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.

Document Frontmatter

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-idtitle: Documentation Title---

Text

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.

Headings

  • Add only one H1 in each document, by adding # at the beginning of it (when using Markdown). The h1 becomes the document <title>.
  • Start with an h2 (##), and respect the order h2 > h3 > h4 > h5 > h6. Never skip the hierarchy level, such as h2 > 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.
Headings Capitalization

Names for console UI elements

Lists

  • 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.

Testing

Playwright tests

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:

  1. Clone this repository.
  2. Enter the /docs folder in your local git environment.
  3. Install dependencies by running: npm install.
  4. Run the Docs webserver and test the documentation by running: npm start
  5. Build the docs and verify by running: npm run build

Jest tests

The Playwright (E2E) tests file names end with .test.ts and can be found in /tests/jest.

Formatting documentation

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

Markdownlint

Locally:

  1. Download and install the markdownlint CLI. brew install markdownlint-cli
  2. Check if markdownlint installed.
    `markdownlint --help``
  3. Lint all files in the project, in the docs folder use cd docsmarkdownlint '**/*.md' --ignore node_modules
  4. Fix all files in the project, Warning: This writes to your files!cd docsmarkdownlint './docs/**/*.+(md|mdx)' --ignore node_modules --fix

How-To

Links to other pages

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.

Import Markdown

Use the same markdown in several places:

```mdx-code-blockimport ExampleMarkdown from './_common/example.md'<ExampleMarkdown />```

Code snippets

From Github

Use CodeFromRemote to import code directly from Github.

Import at the beginning of your document like so:

---id: documentation idtitle: Documentation Title---
import CodeFromRemote from '@theme/CodeFromRemote'

Then at the place you want the code to appear in the document add:

<CodeFromRemotelang="js" # thelanguageofthecodeyouwanttoadde.g.jsx,tsx,ts,go,yaml,yml,js,html,puglink="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:

<CodeFromRemotelang="yml"src="https://github.com/gen1us2k/kratos_flask_example/blob/master/docker-compose.yml"startAt="postgres-kratos:"endAt="postgres-keto:"/>

From this Repository

Use the same code example in several places:

```mdx-code-blockimport 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>```

Code Examples in MDX

If you are using MDX and are in, for example, code tabs, use the CodeBlock to nest code items:

```mdx-code-blockimport CodeBlock from '@theme/CodeBlock'<Tabs defaultValue="ui" values={[ {label: 'UI', value: 'ui'}, ]}> <TabItem value="ui"> <CodeBlock className="language-jsx">{`Yourcodehere`}</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>```

Shell Examples

Use shellsession:

```shellsessionnpx create-next-app@latest --typescriptnpm i --save @ory/integrations```

Please do not prefixes with $

- $ command --arg # do not+ command --arg # do

Images

Add images directly with an img tag:

<imgalt="Image description which will be the alt tag" src={useBaseUrl('images/some-folder/some-image.png')} />

The useBaseUrl is https://www.ory.sh/ and exposes src/static/..., so all images are stored in src/static/images/....

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.

Videos

When you record your screen using Quicktime, a .mov file is recorded. Follow these rules:

  1. Please use 16:9 format with at least 1024 pixels wide. ffmpeg will scale it to the right size.
  2. 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%.*}".webmffmpeg -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!

CLI Documentation

Fixing Ory CLI docs

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

About

Documentation for all ORY products

Resources

Code of conduct

Contributing

Security policy

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Ory Documentation

Ory Documentation

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:

Style

Categories

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.

Document Frontmatter

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-idtitle: Documentation Title---

Text

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.

Headings

  • Add only one H1 in each document, by adding # at the beginning of it (when using Markdown). The h1 becomes the document <title>.
  • Start with an h2 (##), and respect the order h2 > h3 > h4 > h5 > h6. Never skip the hierarchy level, such as h2 > 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.
Headings Capitalization

Names for console UI elements

Lists

  • 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.

Testing

Playwright tests

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:

  1. Clone this repository.
  2. Enter the /docs folder in your local git environment.
  3. Install dependencies by running: npm install.
  4. Run the Docs webserver and test the documentation by running: npm start
  5. Build the docs and verify by running: npm run build

Jest tests

The Playwright (E2E) tests file names end with .test.ts and can be found in /tests/jest.

Formatting documentation

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

Markdownlint

Locally:

  1. Download and install the markdownlint CLI. brew install markdownlint-cli
  2. Check if markdownlint installed.
    `markdownlint --help``
  3. Lint all files in the project, in the docs folder use cd docsmarkdownlint '**/*.md' --ignore node_modules
  4. Fix all files in the project, Warning: This writes to your files!cd docsmarkdownlint './docs/**/*.+(md|mdx)' --ignore node_modules --fix

How-To

Links to other pages

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.

Import Markdown

Use the same markdown in several places:

```mdx-code-blockimport ExampleMarkdown from './_common/example.md'<ExampleMarkdown />```

Code snippets

From Github

Use CodeFromRemote to import code directly from Github.

Import at the beginning of your document like so:

---id: documentation idtitle: Documentation Title---
import CodeFromRemote from '@theme/CodeFromRemote'

Then at the place you want the code to appear in the document add:

<CodeFromRemotelang="js" # thelanguageofthecodeyouwanttoadde.g.jsx,tsx,ts,go,yaml,yml,js,html,puglink="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:

<CodeFromRemotelang="yml"src="https://github.com/gen1us2k/kratos_flask_example/blob/master/docker-compose.yml"startAt="postgres-kratos:"endAt="postgres-keto:"/>

From this Repository

Use the same code example in several places:

```mdx-code-blockimport 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>```

Code Examples in MDX

If you are using MDX and are in, for example, code tabs, use the CodeBlock to nest code items:

```mdx-code-blockimport CodeBlock from '@theme/CodeBlock'<Tabs defaultValue="ui" values={[ {label: 'UI', value: 'ui'}, ]}> <TabItem value="ui"> <CodeBlock className="language-jsx">{`Yourcodehere`}</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>```

Shell Examples

Use shellsession:

```shellsessionnpx create-next-app@latest --typescriptnpm i --save @ory/integrations```

Please do not prefixes with $

- $ command --arg # do not+ command --arg # do

Images

Add images directly with an img tag:

<imgalt="Image description which will be the alt tag" src={useBaseUrl('images/some-folder/some-image.png')} />

The useBaseUrl is https://www.ory.sh/ and exposes src/static/..., so all images are stored in src/static/images/....

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.

Videos

When you record your screen using Quicktime, a .mov file is recorded. Follow these rules:

  1. Please use 16:9 format with at least 1024 pixels wide. ffmpeg will scale it to the right size.
  2. 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%.*}".webmffmpeg -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!

CLI Documentation

Fixing Ory CLI docs

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

About

Documentation for all ORY products

Resources

Code of conduct

Contributing

Security policy

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Ory Documentation

Ory Documentation

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:

Style

Categories

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.

Document Frontmatter

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-idtitle: Documentation Title---

Text

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.

Headings

  • Add only one H1 in each document, by adding # at the beginning of it (when using Markdown). The h1 becomes the document <title>.
  • Start with an h2 (##), and respect the order h2 > h3 > h4 > h5 > h6. Never skip the hierarchy level, such as h2 > 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.
Headings Capitalization

Names for console UI elements

Lists

  • 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.

Testing

Playwright tests

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:

  1. Clone this repository.
  2. Enter the /docs folder in your local git environment.
  3. Install dependencies by running: npm install.
  4. Run the Docs webserver and test the documentation by running: npm start
  5. Build the docs and verify by running: npm run build

Jest tests

The Playwright (E2E) tests file names end with .test.ts and can be found in /tests/jest.

Formatting documentation

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

Markdownlint

Locally:

  1. Download and install the markdownlint CLI. brew install markdownlint-cli
  2. Check if markdownlint installed.
    `markdownlint --help``
  3. Lint all files in the project, in the docs folder use cd docsmarkdownlint '**/*.md' --ignore node_modules
  4. Fix all files in the project, Warning: This writes to your files!cd docsmarkdownlint './docs/**/*.+(md|mdx)' --ignore node_modules --fix

How-To

Links to other pages

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.

Import Markdown

Use the same markdown in several places:

```mdx-code-blockimport ExampleMarkdown from './_common/example.md'<ExampleMarkdown />```

Code snippets

From Github

Use CodeFromRemote to import code directly from Github.

Import at the beginning of your document like so:

---id: documentation idtitle: Documentation Title---
import CodeFromRemote from '@theme/CodeFromRemote'

Then at the place you want the code to appear in the document add:

<CodeFromRemotelang="js" # thelanguageofthecodeyouwanttoadde.g.jsx,tsx,ts,go,yaml,yml,js,html,puglink="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:

<CodeFromRemotelang="yml"src="https://github.com/gen1us2k/kratos_flask_example/blob/master/docker-compose.yml"startAt="postgres-kratos:"endAt="postgres-keto:"/>

From this Repository

Use the same code example in several places:

```mdx-code-blockimport 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>```

Code Examples in MDX

If you are using MDX and are in, for example, code tabs, use the CodeBlock to nest code items:

```mdx-code-blockimport CodeBlock from '@theme/CodeBlock'<Tabs defaultValue="ui" values={[ {label: 'UI', value: 'ui'}, ]}> <TabItem value="ui"> <CodeBlock className="language-jsx">{`Yourcodehere`}</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>```

Shell Examples

Use shellsession:

```shellsessionnpx create-next-app@latest --typescriptnpm i --save @ory/integrations```

Please do not prefixes with $

- $ command --arg # do not+ command --arg # do

Images

Add images directly with an img tag:

<imgalt="Image description which will be the alt tag" src={useBaseUrl('images/some-folder/some-image.png')} />

The useBaseUrl is https://www.ory.sh/ and exposes src/static/..., so all images are stored in src/static/images/....

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.

Videos

When you record your screen using Quicktime, a .mov file is recorded. Follow these rules:

  1. Please use 16:9 format with at least 1024 pixels wide. ffmpeg will scale it to the right size.
  2. 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%.*}".webmffmpeg -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!

CLI Documentation

Fixing Ory CLI docs

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

About

Documentation for all ORY products

Resources

Code of conduct

Contributing

Security policy

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
Skip to content

Ory Documentation

Ory Documentation

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:

Style

Categories

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.

Document Frontmatter

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-idtitle: Documentation Title---

Text

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.

Headings

  • Add only one H1 in each document, by adding # at the beginning of it (when using Markdown). The h1 becomes the document <title>.
  • Start with an h2 (##), and respect the order h2 > h3 > h4 > h5 > h6. Never skip the hierarchy level, such as h2 > 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.
Headings Capitalization

Names for console UI elements

Lists

  • 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.

Testing

Playwright tests

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:

  1. Clone this repository.
  2. Enter the /docs folder in your local git environment.
  3. Install dependencies by running: npm install.
  4. Run the Docs webserver and test the documentation by running: npm start
  5. Build the docs and verify by running: npm run build

Jest tests

The Playwright (E2E) tests file names end with .test.ts and can be found in /tests/jest.

Formatting documentation

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

Markdownlint

Locally:

  1. Download and install the markdownlint CLI. brew install markdownlint-cli
  2. Check if markdownlint installed.
    `markdownlint --help``
  3. Lint all files in the project, in the docs folder use cd docsmarkdownlint '**/*.md' --ignore node_modules
  4. Fix all files in the project, Warning: This writes to your files!cd docsmarkdownlint './docs/**/*.+(md|mdx)' --ignore node_modules --fix

How-To

Links to other pages

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.

Import Markdown

Use the same markdown in several places:

```mdx-code-blockimport ExampleMarkdown from './_common/example.md'<ExampleMarkdown />```

Code snippets

From Github

Use CodeFromRemote to import code directly from Github.

Import at the beginning of your document like so:

---id: documentation idtitle: Documentation Title---
import CodeFromRemote from '@theme/CodeFromRemote'

Then at the place you want the code to appear in the document add:

<CodeFromRemotelang="js" # thelanguageofthecodeyouwanttoadde.g.jsx,tsx,ts,go,yaml,yml,js,html,puglink="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:

<CodeFromRemotelang="yml"src="https://github.com/gen1us2k/kratos_flask_example/blob/master/docker-compose.yml"startAt="postgres-kratos:"endAt="postgres-keto:"/>

From this Repository

Use the same code example in several places:

```mdx-code-blockimport 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>```

Code Examples in MDX

If you are using MDX and are in, for example, code tabs, use the CodeBlock to nest code items:

```mdx-code-blockimport CodeBlock from '@theme/CodeBlock'<Tabs defaultValue="ui" values={[ {label: 'UI', value: 'ui'}, ]}> <TabItem value="ui"> <CodeBlock className="language-jsx">{`Yourcodehere`}</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>```

Shell Examples

Use shellsession:

```shellsessionnpx create-next-app@latest --typescriptnpm i --save @ory/integrations```

Please do not prefixes with $

- $ command --arg # do not+ command --arg # do

Images

Add images directly with an img tag:

<imgalt="Image description which will be the alt tag" src={useBaseUrl('images/some-folder/some-image.png')} />

The useBaseUrl is https://www.ory.sh/ and exposes src/static/..., so all images are stored in src/static/images/....

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.

Videos

When you record your screen using Quicktime, a .mov file is recorded. Follow these rules:

  1. Please use 16:9 format with at least 1024 pixels wide. ffmpeg will scale it to the right size.
  2. 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%.*}".webmffmpeg -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!

CLI Documentation

Fixing Ory CLI docs

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

About

Documentation for all ORY products

Resources

Code of conduct

Contributing

Security policy

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Ory Documentation

Ory Documentation

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:

Style

Categories

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.

Document Frontmatter

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-idtitle: Documentation Title---

Text

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.

Headings

  • Add only one H1 in each document, by adding # at the beginning of it (when using Markdown). The h1 becomes the document <title>.
  • Start with an h2 (##), and respect the order h2 > h3 > h4 > h5 > h6. Never skip the hierarchy level, such as h2 > 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.
Headings Capitalization

Names for console UI elements

Lists

  • 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.

Testing

Playwright tests

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:

  1. Clone this repository.
  2. Enter the /docs folder in your local git environment.
  3. Install dependencies by running: npm install.
  4. Run the Docs webserver and test the documentation by running: npm start
  5. Build the docs and verify by running: npm run build

Jest tests

The Playwright (E2E) tests file names end with .test.ts and can be found in /tests/jest.

Formatting documentation

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

Markdownlint

Locally:

  1. Download and install the markdownlint CLI. brew install markdownlint-cli
  2. Check if markdownlint installed.
    `markdownlint --help``
  3. Lint all files in the project, in the docs folder use cd docsmarkdownlint '**/*.md' --ignore node_modules
  4. Fix all files in the project, Warning: This writes to your files!cd docsmarkdownlint './docs/**/*.+(md|mdx)' --ignore node_modules --fix

How-To

Links to other pages

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.

Import Markdown

Use the same markdown in several places:

```mdx-code-blockimport ExampleMarkdown from './_common/example.md'<ExampleMarkdown />```

Code snippets

From Github

Use CodeFromRemote to import code directly from Github.

Import at the beginning of your document like so:

---id: documentation idtitle: Documentation Title---
import CodeFromRemote from '@theme/CodeFromRemote'

Then at the place you want the code to appear in the document add:

<CodeFromRemotelang="js" # thelanguageofthecodeyouwanttoadde.g.jsx,tsx,ts,go,yaml,yml,js,html,puglink="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:

<CodeFromRemotelang="yml"src="https://github.com/gen1us2k/kratos_flask_example/blob/master/docker-compose.yml"startAt="postgres-kratos:"endAt="postgres-keto:"/>

From this Repository

Use the same code example in several places:

```mdx-code-blockimport 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>```

Code Examples in MDX

If you are using MDX and are in, for example, code tabs, use the CodeBlock to nest code items:

```mdx-code-blockimport CodeBlock from '@theme/CodeBlock'<Tabs defaultValue="ui" values={[ {label: 'UI', value: 'ui'}, ]}> <TabItem value="ui"> <CodeBlock className="language-jsx">{`Yourcodehere`}</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>```

Shell Examples

Use shellsession:

```shellsessionnpx create-next-app@latest --typescriptnpm i --save @ory/integrations```

Please do not prefixes with $

- $ command --arg # do not+ command --arg # do

Images

Add images directly with an img tag:

<imgalt="Image description which will be the alt tag" src={useBaseUrl('images/some-folder/some-image.png')} />

The useBaseUrl is https://www.ory.sh/ and exposes src/static/..., so all images are stored in src/static/images/....

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.

Videos

When you record your screen using Quicktime, a .mov file is recorded. Follow these rules:

  1. Please use 16:9 format with at least 1024 pixels wide. ffmpeg will scale it to the right size.
  2. 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%.*}".webmffmpeg -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!

CLI Documentation

Fixing Ory CLI docs

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

About

Documentation for all ORY products

Resources

Code of conduct

Contributing

Security policy

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Ory Documentation

Ory Documentation

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:

Style

Categories

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.

Document Frontmatter

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-idtitle: Documentation Title---

Text

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.

Headings

  • Add only one H1 in each document, by adding # at the beginning of it (when using Markdown). The h1 becomes the document <title>.
  • Start with an h2 (##), and respect the order h2 > h3 > h4 > h5 > h6. Never skip the hierarchy level, such as h2 > 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.
Headings Capitalization

Names for console UI elements

Lists

  • 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.

Testing

Playwright tests

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:

  1. Clone this repository.
  2. Enter the /docs folder in your local git environment.
  3. Install dependencies by running: npm install.
  4. Run the Docs webserver and test the documentation by running: npm start
  5. Build the docs and verify by running: npm run build

Jest tests

The Playwright (E2E) tests file names end with .test.ts and can be found in /tests/jest.

Formatting documentation

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

Markdownlint

Locally:

  1. Download and install the markdownlint CLI. brew install markdownlint-cli
  2. Check if markdownlint installed.
    `markdownlint --help``
  3. Lint all files in the project, in the docs folder use cd docsmarkdownlint '**/*.md' --ignore node_modules
  4. Fix all files in the project, Warning: This writes to your files!cd docsmarkdownlint './docs/**/*.+(md|mdx)' --ignore node_modules --fix

How-To

Links to other pages

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.

Import Markdown

Use the same markdown in several places:

```mdx-code-blockimport ExampleMarkdown from './_common/example.md'<ExampleMarkdown />```

Code snippets

From Github

Use CodeFromRemote to import code directly from Github.

Import at the beginning of your document like so:

---id: documentation idtitle: Documentation Title---
import CodeFromRemote from '@theme/CodeFromRemote'

Then at the place you want the code to appear in the document add:

<CodeFromRemotelang="js" # thelanguageofthecodeyouwanttoadde.g.jsx,tsx,ts,go,yaml,yml,js,html,puglink="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:

<CodeFromRemotelang="yml"src="https://github.com/gen1us2k/kratos_flask_example/blob/master/docker-compose.yml"startAt="postgres-kratos:"endAt="postgres-keto:"/>

From this Repository

Use the same code example in several places:

```mdx-code-blockimport 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>```

Code Examples in MDX

If you are using MDX and are in, for example, code tabs, use the CodeBlock to nest code items:

```mdx-code-blockimport CodeBlock from '@theme/CodeBlock'<Tabs defaultValue="ui" values={[ {label: 'UI', value: 'ui'}, ]}> <TabItem value="ui"> <CodeBlock className="language-jsx">{`Yourcodehere`}</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>```

Shell Examples

Use shellsession:

```shellsessionnpx create-next-app@latest --typescriptnpm i --save @ory/integrations```

Please do not prefixes with $

- $ command --arg # do not+ command --arg # do

Images

Add images directly with an img tag:

<imgalt="Image description which will be the alt tag" src={useBaseUrl('images/some-folder/some-image.png')} />

The useBaseUrl is https://www.ory.sh/ and exposes src/static/..., so all images are stored in src/static/images/....

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.

Videos

When you record your screen using Quicktime, a .mov file is recorded. Follow these rules:

  1. Please use 16:9 format with at least 1024 pixels wide. ffmpeg will scale it to the right size.
  2. 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%.*}".webmffmpeg -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!

CLI Documentation

Fixing Ory CLI docs

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

About

Documentation for all ORY products

Resources

Code of conduct

Contributing

Security policy

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
Skip to content

Ory Documentation

Ory Documentation

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:

Style

Categories

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.

Document Frontmatter

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-idtitle: Documentation Title---

Text

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.

Headings

  • Add only one H1 in each document, by adding # at the beginning of it (when using Markdown). The h1 becomes the document <title>.
  • Start with an h2 (##), and respect the order h2 > h3 > h4 > h5 > h6. Never skip the hierarchy level, such as h2 > 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.
Headings Capitalization

Names for console UI elements

Lists

  • 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.

Testing

Playwright tests

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:

  1. Clone this repository.
  2. Enter the /docs folder in your local git environment.
  3. Install dependencies by running: npm install.
  4. Run the Docs webserver and test the documentation by running: npm start
  5. Build the docs and verify by running: npm run build

Jest tests

The Playwright (E2E) tests file names end with .test.ts and can be found in /tests/jest.

Formatting documentation

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

Markdownlint

Locally:

  1. Download and install the markdownlint CLI. brew install markdownlint-cli
  2. Check if markdownlint installed.
    `markdownlint --help``
  3. Lint all files in the project, in the docs folder use cd docsmarkdownlint '**/*.md' --ignore node_modules
  4. Fix all files in the project, Warning: This writes to your files!cd docsmarkdownlint './docs/**/*.+(md|mdx)' --ignore node_modules --fix

How-To

Links to other pages

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.

Import Markdown

Use the same markdown in several places:

```mdx-code-blockimport ExampleMarkdown from './_common/example.md'<ExampleMarkdown />```

Code snippets

From Github

Use CodeFromRemote to import code directly from Github.

Import at the beginning of your document like so:

---id: documentation idtitle: Documentation Title---
import CodeFromRemote from '@theme/CodeFromRemote'

Then at the place you want the code to appear in the document add:

<CodeFromRemotelang="js" # thelanguageofthecodeyouwanttoadde.g.jsx,tsx,ts,go,yaml,yml,js,html,puglink="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:

<CodeFromRemotelang="yml"src="https://github.com/gen1us2k/kratos_flask_example/blob/master/docker-compose.yml"startAt="postgres-kratos:"endAt="postgres-keto:"/>

From this Repository

Use the same code example in several places:

```mdx-code-blockimport 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>```

Code Examples in MDX

If you are using MDX and are in, for example, code tabs, use the CodeBlock to nest code items:

```mdx-code-blockimport CodeBlock from '@theme/CodeBlock'<Tabs defaultValue="ui" values={[ {label: 'UI', value: 'ui'}, ]}> <TabItem value="ui"> <CodeBlock className="language-jsx">{`Yourcodehere`}</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>```

Shell Examples

Use shellsession:

```shellsessionnpx create-next-app@latest --typescriptnpm i --save @ory/integrations```

Please do not prefixes with $

- $ command --arg # do not+ command --arg # do

Images

Add images directly with an img tag:

<imgalt="Image description which will be the alt tag" src={useBaseUrl('images/some-folder/some-image.png')} />

The useBaseUrl is https://www.ory.sh/ and exposes src/static/..., so all images are stored in src/static/images/....

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.

Videos

When you record your screen using Quicktime, a .mov file is recorded. Follow these rules:

  1. Please use 16:9 format with at least 1024 pixels wide. ffmpeg will scale it to the right size.
  2. 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%.*}".webmffmpeg -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!

CLI Documentation

Fixing Ory CLI docs

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

About

Documentation for all ORY products

Resources

Code of conduct

Contributing

Security policy

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages