Skip to content

monta-app/ory-docs

 
 

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-id
title: 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 docs markdownlint '**/*.md' --ignore node_modules
  4. Fix all files in the project, Warning: This writes to your files! cd docs markdownlint './docs/**/*.+(md|mdx)' --ignore node_modules --fix

Vale

  1. Download and install Vale.
    brew install vale
  2. Check if Vale installed.
    vale -h
  3. Copy the write-good and Microsoft Vale Styles:
  1. Add .vale.ini in your root or project folder. Reference .vale.ini
  2. Check the document:
    vale yourdocument.md or vale docs/ecosystem/styleguide/testing.md

Check the documentation for more advanced features.

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-block
import 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 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:"
/>

From this Repository

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>
```

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-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>
```

Write a Shell Example

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

Images

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.

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%.*}".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!

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

License

Code of conduct

Security policy

Stars

Watchers

Forks

Packages

No packages published

Languages

  • JavaScript 63.9%
  • TypeScript 18.4%
  • CSS 6.6%
  • Dart 3.0%
  • HTML 2.7%
  • Go 2.2%
  • Other 3.2%