MkDocs プラグイン

MkDocs プラグインのインストール、使用、作成ガイド

プラグインのインストール

プラグインを使用する前に、システムにインストールする必要があります。 MkDocsに付属のプラグインを使用している場合は、MkDocsのインストール時にインストールされています。ただし、サードパーティのプラグインをインストールするには、適切なパッケージ名を確認し、pipを使用してインストールする必要があります。

pip install mkdocs-foo-plugin

警告

MkDocsプラグインをインストールするということは、Pythonパッケージをインストールし、作成者がそこに配置したコードを実行することを意味します。そのため、通常の注意を払ってください。サンドボックス化の試みはありません。

プラグインが正常にインストールされると、使用できるようになります。設定ファイルで有効にするだけです。カタログリポジトリには、インストールして使用できるプラグインのランク付けされた大規模なリストがあります。

プラグインの使用

plugins設定オプションには、サイトの構築時に使用するプラグインのリストを含める必要があります。各「プラグイン」は、プラグインに割り当てられた文字列名である必要があります（「名前」を確認するには、特定のプラグインのドキュメントを参照してください）。ここにリストされているプラグインは、すでにインストールされている必要があります。

plugins:
  - search

一部のプラグインは、独自の構成オプションを提供する場合があります。構成オプションを設定する場合は、指定されたプラグインがサポートするオプションのキーと値のマッピング（option_name: option value）を入れ子にすることができます。コロン（:）はプラグイン名の後に続き、新しい行でオプション名と値はインデントされ、コロンで区切る必要があります。単一のプラグインに複数のオプションを定義する場合は、各オプションを別々の行で定義する必要があります。

plugins:
  - search:
      lang: en
      foo: bar

特定のプラグインで使用可能な構成オプションについては、そのプラグインのドキュメントを参照してください。

デフォルトのプラグインとその上書き方法のリストについては、設定ドキュメントを参照してください。

プラグインの開発

MkDocsと同様に、プラグインはPythonで記述する必要があります。同じモジュールで複数のプラグインを定義することは可能ですが、各プラグインは個別のPythonモジュールとして配布されることが一般的に期待されています。MkDocsプラグインは、少なくともBasePluginサブクラスとそれを指すエントリポイントで構成されている必要があります。

BasePlugin

mkdocs.plugins.BasePluginのサブクラスは、プラグインの動作を定義する必要があります。クラスは一般に、ビルドプロセスにおける特定のイベントに対して実行されるアクションと、プラグインの構成スキームで構成されます。

すべてのBasePluginサブクラスには、次の属性が含まれています。

config_scheme

構成検証インスタンスのタプル。各項目は、最初の項目が構成オプションの文字列名であり、2番目の項目がmkdocs.config.config_options.BaseConfigOptionまたはそのサブクラスのインスタンスである2項目のタプルで構成されている必要があります。

たとえば、次のconfig_schemeは、3つの構成オプションを定義しています。文字列を受け入れるfoo、整数を許可するbar、およびブール値を受け入れるbazです。

class MyPlugin(mkdocs.plugins.BasePlugin):
    config_scheme = (
        ('foo', mkdocs.config.config_options.Type(str, default='a default value')),
        ('bar', mkdocs.config.config_options.Type(int, default=0)),
        ('baz', mkdocs.config.config_options.Type(bool, default=True))
    )

バージョン1.4の新機能

設定スキーマを指定するための設定のサブクラス化

型安全性の利点を得るには、MkDocs 1.4以降のみをターゲットとする場合、設定スキーマをクラスとして定義します。

class MyPluginConfig(mkdocs.config.base.Config):
    foo = mkdocs.config.config_options.Type(str, default='a default value')
    bar = mkdocs.config.config_options.Type(int, default=0)
    baz = mkdocs.config.config_options.Type(bool, default=True)

class MyPlugin(mkdocs.plugins.BasePlugin[MyPluginConfig]):
    ...

設定定義の例

例

from mkdocs.config import base, config_options as c

class _ValidationOptions(base.Config):
    enabled = c.Type(bool, default=True)
    verbose = c.Type(bool, default=False)
    skip_checks = c.ListOfItems(c.Choice(('foo', 'bar', 'baz')), default=[])

class MyPluginConfig(base.Config):
    definition_file = c.File(exists=True)  # required
    checksum_file = c.Optional(c.File(exists=True))  # can be None but must exist if specified
    validation = c.SubConfig(_ValidationOptions)

ユーザーの観点からは、SubConfigはType(dict)に似ています。ただし、検証の完全な機能も保持しています。すべての有効なキーと、各値が何を遵守する必要があるかを定義します。

また、ListOfItemsはType(list)に似ていますが、ここでも、各値が準拠する必要がある制約を定義します。

これは、次のような設定を受け入れます。

my_plugin:
  definition_file: configs/test.ini  # relative to mkdocs.yml
  validation:
    enabled: !ENV [CI, false]
    verbose: true
    skip_checks:
      - foo
      - baz

例

import numbers
from mkdocs.config import base, config_options as c

class _Rectangle(base.Config):
    width = c.Type(numbers.Real)  # required
    height = c.Type(numbers.Real)  # required

class MyPluginConfig(base.Config):
    add_rectangles = c.ListOfItems(c.SubConfig(_Rectangle))  # required

この例では、複雑な項目のリストを定義しています。これは、具体的なSubConfigをListOfItemsに渡すことで実現されます。

これは、次のような設定を受け入れます。

my_plugin:
  add_rectangles:
    - width: 5
      height: 7
    - width: 12
      height: 2

ユーザーの構成がロードされると、上記のスキームを使用して構成が検証され、ユーザーが提供していない設定のデフォルト値が入力されます。検証クラスは、mkdocs.config.config_optionsで提供されるクラス、またはプラグインで定義されたサードパーティのサブクラスのいずれかです。

検証に失敗した、または`config_scheme`で定義されていないユーザーが提供した設定は、`mkdocs.config.base.ValidationError`を発生させます。

config

プラグインの構成オプションの辞書。構成の検証が完了した後、 `load_config`メソッドによって設定されます。この属性を使用して、ユーザーが提供するオプションにアクセスします。

def on_pre_build(self, config, **kwargs):
    if self.config['baz']:
        # implement "baz" functionality here...

バージョン1.4の新機能

安全な属性ベースのアクセス

型安全性の利点を得るには、MkDocs 1.4以降のみをターゲットとする場合、代わりに属性としてオプションにアクセスします。

def on_pre_build(self, config, **kwargs):
    if self.config.baz:
        print(self.config.bar ** 2)  # OK, `int ** 2` is valid.

すべての `BasePlugin`サブクラスには、次のメソッドが含まれています。

load_config(options)

オプションの辞書から構成を読み込みます。 `(errors, warnings)`のタプルを返します。このメソッドは、構成の検証中にMkDocsによって呼び出され、プラグインによって呼び出される必要はありません。

on_<event_name>()

特定のイベントの動作を定義するオプションのメソッド。プラグインは、これらのメソッド内でその動作を定義する必要があります。 `<event_name>`をイベントの実際の名前に置き換えます。たとえば、`pre_build`イベントは `on_pre_build`メソッドで定義されます。

ほとんどのイベントは、1つの位置引数とさまざまなキーワード引数を受け入れます。位置引数は、プラグインによって変更（または置換）され、返されることが一般的に期待されます。何も返されない（メソッドが `None`を返す）場合、元の変更されていないオブジェクトが使用されます。キーワード引数は、コンテキストを提供したり、位置引数の変更方法を決定するために使用される可能性のあるデータを提供したりするために提供されます。キーワード引数を`**kwargs`として受け入れるのが良い習慣です。将来のバージョンのMkDocsでイベントに追加のキーワードが提供された場合、プラグインを変更する必要はありません。

たとえば、次のイベントは、テーマ設定に `static_template`を追加します。

class MyPlugin(BasePlugin):
    def on_config(self, config, **kwargs):
        config['theme'].static_templates.add('my_template.html')
        return config

バージョン1.4の新機能

型安全性の利点を得るには、MkDocs 1.4以降のみをターゲットとする場合、代わりに属性として構成オプションにアクセスします。

def on_config(self, config: MkDocsConfig):
    config.theme.static_templates.add('my_template.html')
    return config

イベント

イベントには、グローバルイベント、ページイベント、テンプレートイベントの3種類があります。

すべてのプラグインイベント間の関係を示す図を参照してください。

イベント自体は、パラメータとともに黄色で表示されます。
矢印は、各イベントの引数と出力の流れを示しています。省略されることもあります。
イベントは、上から下へ時系列で並べられています。
グローバルイベントからページごとのイベントへの分割には、点線が表示されます。
イベントのタイトルをクリックすると、その説明にジャンプします。

ワンタイムイベント

ワンタイムイベントは、`mkdocs`の呼び出しごとに1回実行されます。これらがグローバルイベントと具体的に異なる唯一のケースは、`mkdocs serve`の場合です。グローバルイベントは、これらとは異なり、複数回実行されます（ビルドごとに1回）。

on_startup

`startup`イベントは、`mkdocs`の呼び出しの最初に1回実行されます。

MkDocs 1.4の新機能。

`on_startup`メソッドが存在する場合（空であっても）、プラグインオブジェクトが1つの `mkdocs serve`内のビルド間で保持される新しいシステムに移行されます。

変数を初期化するには、`__init__`メソッドが引き続き推奨されることに注意してください。ビルドごとの変数を初期化するには（および疑問がある場合は常に）、 `on_config`イベントを使用します。

パラメータ

`command` ( `Literal['build', 'gh-deploy', 'serve']`) –

MkDocsが呼び出されたコマンド。たとえば、 `mkdocs serve`の場合は「serve」。
`dirty` ( `bool`) –

`--dirty`フラグが渡されたかどうか。

on_shutdown

`shutdown`イベントは、`mkdocs`の呼び出しの最後に1回、終了する前に実行されます。

このイベントは、`mkdocs serve`のサポートにのみ関連します。それ以外の場合、単一のビルド内では `on_post_build`と区別できません。

MkDocs 1.4の新機能。

`on_shutdown`メソッドが存在する場合（空であっても）、プラグインオブジェクトが1つの `mkdocs serve`内のビルド間で保持される新しいシステムに移行されます。

可能な場合は、`on_post_build`メソッドがクリーンアップに適していることに注意してください。実際にトリガーされる可能性がはるかに高いためです。 `on_shutdown`は、MkDocsの正常なシャットダウンの検出に依存するため、「ベストエフォート」です。

on_serve

`serve`イベントは、開発中に `serve`コマンドが使用された場合にのみ呼び出されます。最初のビルドが完了した後、1回だけ実行されます。アクティブ化される前に変更できる `Server`インスタンスに渡されます。たとえば、自動リロードのために「監視対象」ファイルのリストに追加のファイルまたはディレクトリを追加できます。

パラメータ

`server` ( `LiveReloadServer`) –

`livereload.Server`インスタンス
`config` ( `MkDocsConfig`) –

グローバル設定オブジェクト
`builder` ( `Callable`) –

`server.watch`の各呼び出しに渡される呼び出し可能オブジェクト

戻り値

`LiveReloadServer | None` –

`livereload.Server`インスタンス

グローバルイベント

グローバルイベントは、ビルドプロセスの開始時または終了時に、ビルドごとに1回呼び出されます。これらのイベントで行われた変更は、サイト全体にグローバルに影響します。

on_config

`config`イベントは、ビルドで最初に呼び出されるイベントであり、ユーザー構成がロードされ、検証された直後に実行されます。設定の変更はここで行う必要があります。

パラメータ

`config` ( `MkDocsConfig`) –

グローバル設定オブジェクト

戻り値

`MkDocsConfig | None` –

グローバル設定オブジェクト

on_pre_build

pre_build イベントは、変数を変更しません。このイベントは、ビルド前スクリプトを呼び出すために使用します。

パラメータ

`config` ( `MkDocsConfig`) –

グローバル設定オブジェクト

on_files

files イベントは、docs_dir からファイルコレクションが作成された後に呼び出されます。このイベントは、コレクション内のファイルを追加、削除、または変更するために使用します。ページオブジェクトはまだコレクション内のファイルオブジェクトに関連付けられていないことに注意してください。ページ固有のデータを操作するには、ページイベントを使用します。

パラメータ

files (Files) –

グローバルファイルコレクション
`config` ( `MkDocsConfig`) –

グローバル設定オブジェクト

戻り値

Files | None –

グローバルファイルコレクション

on_nav

nav イベントは、サイトナビゲーションが作成された後に呼び出され、サイトナビゲーションを変更するために使用できます。

パラメータ

nav (Navigation) –

グローバルナビゲーションオブジェクト
`config` ( `MkDocsConfig`) –

グローバル設定オブジェクト
files (Files) –

グローバルファイルコレクション

戻り値

Navigation | None –

グローバルナビゲーションオブジェクト

on_env

env イベントは、Jinja テンプレート環境が作成された後に呼び出され、Jinja 環境を変更するために使用できます。

パラメータ

env (Environment) –

グローバル Jinja 環境
`config` ( `MkDocsConfig`) –

グローバル設定オブジェクト
files (Files) –

グローバルファイルコレクション

戻り値

Environment | None –

グローバル Jinja 環境

on_post_build

post_build イベントは、変数を変更しません。このイベントは、ビルド後スクリプトを呼び出すために使用します。

パラメータ

`config` ( `MkDocsConfig`) –

グローバル設定オブジェクト

on_build_error

build_error イベントは、ビルドプロセス中に MkDocs によって何らかの例外がキャッチされた後に呼び出されます。このイベントは、MkDocs が終了する前にクリーンアップを行うために使用します。エラー後に実行される予定だった他のイベントはスキップされることに注意してください。詳細については、エラー処理を参照してください。

パラメータ

error (Exception) –

発生した例外

テンプレートイベント

テンプレートイベントは、ページ以外の各テンプレートに対して一度呼び出されます。extra_templates 設定で定義された各テンプレートと、テーマで定義された static_templates に対して、各テンプレートイベントが呼び出されます。すべてのテンプレートイベントは、env イベントの後、ページイベントの前に呼び出されます。

on_pre_template

pre_template イベントは、対象のテンプレートがロードされた直後に呼び出され、テンプレートを変更するために使用できます。

パラメータ

template (Template) –

Jinja2 Template オブジェクト
template_name (str) –

テンプレートのファイル名文字列
`config` ( `MkDocsConfig`) –

グローバル設定オブジェクト

戻り値

Template | None –

Jinja2 Template オブジェクト

on_template_context

template_context イベントは、対象のテンプレートのコンテキストが作成された直後に呼び出され、その特定のテンプレートのコンテキストのみを変更するために使用できます。

パラメータ

context (TemplateContext) –

テンプレートコンテキスト変数の辞書
template_name (str) –

テンプレートのファイル名文字列
`config` ( `MkDocsConfig`) –

グローバル設定オブジェクト

戻り値

TemplateContext | None –

テンプレートコンテキスト変数の辞書

on_post_template

post_template イベントは、テンプレートがレンダリングされた後、ディスクに書き込まれる前に呼び出され、テンプレートの出力を変更するために使用できます。空の文字列が返された場合、テンプレートはスキップされ、ディスクには何も書き込まれません。

パラメータ

output_content (str) –

レンダリングされたテンプレートの出力 (文字列)
template_name (str) –

テンプレートのファイル名文字列
`config` ( `MkDocsConfig`) –

グローバル設定オブジェクト

戻り値

str | None –

レンダリングされたテンプレートの出力 (文字列)

ページイベント

ページイベントは、サイトに含まれる各 Markdown ページに対して一度呼び出されます。すべてのページイベントは、post_template イベントの後、post_build イベントの前に呼び出されます。

on_pre_page

pre_page イベントは、対象のページに対して何らかのアクションが実行される前に呼び出され、Page インスタンスを変更するために使用できます。

パラメータ

page (Page) –

mkdocs.structure.pages.Page インスタンス
`config` ( `MkDocsConfig`) –

グローバル設定オブジェクト
files (Files) –

グローバルファイルコレクション

戻り値

Page | None –

mkdocs.structure.pages.Page インスタンス

on_page_read_source

非推奨

このイベントの代わりに、以下のいずれかの代替手段を使用してください。

MkDocs 1.6 以降では、on_files 内で File の content_bytes/content_string を設定してください。
通常 (完全な代替手段ではありませんが)、on_page_markdown は同じ目的を果たすことができます。

on_page_read_source イベントは、ファイルシステムからページのソースの内容を読み取るデフォルトのメカニズムを置き換えることができます。

パラメータ

page (Page) –

mkdocs.structure.pages.Page インスタンス
`config` ( `MkDocsConfig`) –

グローバル設定オブジェクト

戻り値

str | None –

Unicode 文字列としてのページのソース。None が返された場合、ファイルからのデフォルトの読み込みが実行されます。

on_page_markdown

page_markdown イベントは、ページのマークダウンがファイルからロードされた後に呼び出され、Markdown ソーステキストを変更するために使用できます。メタデータは削除されており、この時点では page.meta として使用できます。

パラメータ

markdown (str) –

Markdown ソーステキスト (文字列)
page (Page) –

mkdocs.structure.pages.Page インスタンス
`config` ( `MkDocsConfig`) –

グローバル設定オブジェクト
files (Files) –

グローバルファイルコレクション

戻り値

str | None –

Markdown ソーステキスト (文字列)

on_page_content

page_content イベントは、Markdown テキストが HTML にレンダリングされた後 (テンプレートに渡される前) に呼び出され、ページの HTML 本文を変更するために使用できます。

パラメータ

html (str) –

Markdown ソースからレンダリングされた HTML (文字列)
page (Page) –

mkdocs.structure.pages.Page インスタンス
`config` ( `MkDocsConfig`) –

グローバル設定オブジェクト
files (Files) –

グローバルファイルコレクション

戻り値

str | None –

Markdown ソースからレンダリングされた HTML (文字列)

on_page_context

page_context イベントは、ページのコンテキストが作成された後に呼び出され、その特定のページのコンテキストのみを変更するために使用できます。

パラメータ

context (TemplateContext) –

テンプレートコンテキスト変数の辞書
page (Page) –

mkdocs.structure.pages.Page インスタンス
`config` ( `MkDocsConfig`) –

グローバル設定オブジェクト
nav (Navigation) –

グローバルナビゲーションオブジェクト

戻り値

TemplateContext | None –

テンプレートコンテキスト変数の辞書

on_post_page

post_page イベントは、テンプレートがレンダリングされた後、ディスクに書き込まれる前に呼び出され、ページの出力を変更するために使用できます。空の文字列が返された場合、ページはスキップされ、ディスクには何も書き込まれません。

パラメータ

output (str) –

レンダリングされたテンプレートの出力 (文字列)
page (Page) –

mkdocs.structure.pages.Page インスタンス
`config` ( `MkDocsConfig`) –

グローバル設定オブジェクト

戻り値

str | None –

レンダリングされたテンプレートの出力 (文字列)

イベントの優先順位

各イベントタイプについて、プラグインの対応するメソッドは、プラグインが plugins 設定に表示される順序で呼び出されます。

MkDocs 1.4 以降、プラグインはイベントの優先順位を設定できます。優先順位の高いイベントが最初に呼び出されます。優先順位が選択されていないイベントは、デフォルトで 0 になります。同じ優先順位のイベントは、設定に表示される順序で呼び出されます。

`mkdocs.plugins.event_priority(priority: float) -> Callable[[T], T]` 

イベントハンドラーメソッドのイベント優先順位を設定するためのデコレータ。

推奨される優先順位値: 100 "最初", 50 "早い", 0 "デフォルト", -50 "遅い", -100 "最後"。異なるプラグインが互いに、より正確な関係を発見するにつれて、値はさらに微調整されるべきです。

使用例

@plugins.event_priority(-100)  # Wishing to run this after all other plugins' `on_files` events.
def on_files(self, files, config, **kwargs):
    ...

MkDocs 1.4 での新機能。下位互換性のための推奨シム。

try:
    from mkdocs.plugins import event_priority
except ImportError:
    event_priority = lambda priority: lambda f: f  # No-op fallback

バージョン 1.6 での新機能。

同じイベントのハンドラーを複数の異なる優先順位で登録する必要がある場合もあります。

CombinedEvent により、これが可能になります。

`mkdocs.plugins.CombinedEvent` 

基底クラス: Generic[P, T]

複数のイベントハンドラーを定義し、1 つのイベント名で宣言できる記述子。

使用例

@plugins.event_priority(100)
def _on_page_markdown_1(self, markdown: str, **kwargs):
    ...

@plugins.event_priority(-50)
def _on_page_markdown_2(self, markdown: str, **kwargs):
    ...

on_page_markdown = plugins.CombinedEvent(_on_page_markdown_1, _on_page_markdown_2)

注記

サブメソッドの名前は on_ で始めることは**できません**。代わりに、上記の例のように _on_ で始めるか、他の名前で始めることができます。

エラー処理

MkDocs は 4 つのエラードキュメントを定義します。

`mkdocs.exceptions.MkDocsException` 

基底クラス: ClickException

すべての MkDocs 例外が継承する基底クラス。これは直接発生させるべきではありません。代わりに、サブクラスのいずれかを発生させる必要があります。

`mkdocs.exceptions.ConfigurationError` 

基底クラス: MkDocsException

このエラーは、検証エラーが発生した場合に設定検証によって発生します。このエラーは、プラグインの config_scheme で定義された設定オプションによって発生する必要があります。

`mkdocs.exceptions.BuildError` 

基底クラス: MkDocsException

このエラーは、ビルドプロセス中に MkDocs によって発生する可能性があります。プラグインはこのエラーを発生させるべきではありません。

`mkdocs.exceptions.PluginError` 

基底クラス: BuildError

mkdocs.exceptions.BuildError のサブクラスであり、プラグインイベントによって発生する可能性があります。

予期しない、キャッチされない例外はビルドプロセスを中断し、コードのデバッグに役立つ典型的な Python トレースバックを生成します。ただし、ユーザーは一般的にトレースバックを圧倒的に感じ、役立つエラーメッセージを見逃すことがよくあります。そのため、MkDocs は上記のエラーをキャッチし、エラーメッセージを取得し、ユーザーに表示される役立つメッセージのみを表示してすぐに終了します。

そのため、プラグイン内で例外をキャッチし、独自のカスタムメッセージを渡して PluginError を発生させ、ビルドプロセスが役立つメッセージで中止されるようにすることができます。

on_build_error イベントは、例外が発生するたびにトリガーされます。

例えば

from mkdocs.exceptions import PluginError
from mkdocs.plugins import BasePlugin


class MyPlugin(BasePlugin):
    def on_post_page(self, output, page, config, **kwargs):
        try:
            # some code that could throw a KeyError
            ...
        except KeyError as error:
            raise PluginError(f"Failed to find the item by key: '{error}'")

    def on_build_error(self, error, **kwargs):
        # some code to clean things up
        ...

プラグインでのロギング

プラグインのログメッセージが MkDocs のフォーマットと `--verbose`/`--debug` フラグに準拠するようにするには、ログを `mkdocs.plugins.` 名前空間の下のロガーに書き込んでください。

例

import logging

log = logging.getLogger(f"mkdocs.plugins.{__name__}")

log.warning("File '%s' not found. Breaks the build if --strict is passed", my_file_name)
log.info("Shown normally")
log.debug("Shown only with `--verbose`")

if log.getEffectiveLevel() <= logging.DEBUG:
    log.debug("Very expensive calculation only for debugging: %s", get_my_diagnostics())

`log.error()` は、見た目で区別される別のログレベルですが、他のすべての点では `warning` と同じように機能するため、使用するのは奇妙です。プラグインで実際のエラーが発生した場合は、`mkdocs.exceptions.PluginError` を発生させることでビルドを中断するのが最善です (これにより、ERROR メッセージもログに記録されます)。

バージョン 1.5 での新機能。

MkDocs は、上記のようなロガーを返す `get_plugin_logger()` という便利な関数を提供するようになりました。このロガーには、プラグインの名前がプレフィックスとして付けられます。

`mkdocs.plugins.get_plugin_logger(name: str) -> PrefixedLogger` 

プラグイン用のロガーを返します。

パラメータ

name (str) –

logging.getLogger で使用する名前。

戻り値

PrefixedLogger –

MkDocs で適切に動作するように設定されたロガーで、各メッセージの先頭にプラグインパッケージ名を付加します。

例

from mkdocs.plugins import get_plugin_logger

log = get_plugin_logger(__name__)
log.info("My plugin message")

エントリポイント

プラグインはPythonライブラリ（MkDocsとは別にPyPIで配布）としてパッケージ化する必要があり、それぞれがsetuptoolsのentry_pointsを介してプラグインとして登録する必要があります。次の内容をsetup.pyスクリプトに追加してください。

entry_points={
    'mkdocs.plugins': [
        'pluginname = path.to.some_plugin:SomePluginClass',
    ]
}

pluginnameはユーザーが使用する名前（設定ファイル内）で、path.to.some_plugin:SomePluginClassはインポート可能なプラグイン自体（from path.to.some_plugin import SomePluginClass）です。ここで、SomePluginClassはプラグインの動作を定義するBasePluginのサブクラスです。当然、同じモジュール内に複数のプラグインクラスが存在する可能性があります。それぞれを別々のエントリポイントとして定義するだけです。

entry_points={
    'mkdocs.plugins': [
        'featureA = path.to.my_plugins:PluginA',
        'featureB = path.to.my_plugins:PluginB'
    ]
}

プラグインを登録しても、アクティブ化されるわけではないことに注意してください。ユーザーは設定ファイルでMkDocsにプラグインを使用するように指示する必要があります。

プラグインの公開

パッケージはPyPIで公開する必要があります。その後、検出できるようにカタログに追加してください。カタログに従って、プラグインは一意のプラグイン名（エントリポイント名）を持つことを強くお勧めします。

キー	アクション
`?`	このヘルプを開く
`n`	次のページ
`p`	前のページ
`s`	検索

MkDocs プラグイン

プラグインのインストール

プラグインの使用

プラグインの開発

BasePlugin

config_scheme

設定スキーマを指定するための設定のサブクラス化

設定定義の例

config

安全な属性ベースのアクセス

load_config(options)

on_<event_name>()

イベント

ワンタイムイベント

on_startup

on_shutdown

on_serve

グローバルイベント

on_config

on_pre_build

on_files

on_nav

on_env

on_post_build

on_build_error

テンプレートイベント

on_pre_template

on_template_context

on_post_template

ページイベント

on_pre_page

on_page_read_source

on_page_markdown

on_page_content

on_page_context

on_post_page

イベントの優先順位

mkdocs.plugins.event_priority(priority: float) -> Callable[[T], T] 

mkdocs.plugins.CombinedEvent 

エラー処理

mkdocs.exceptions.MkDocsException 

mkdocs.exceptions.ConfigurationError 

mkdocs.exceptions.BuildError 

mkdocs.exceptions.PluginError 

プラグインでのロギング

mkdocs.plugins.get_plugin_logger(name: str) -> PrefixedLogger 

エントリポイント

プラグインの公開

`mkdocs.plugins.event_priority(priority: float) -> Callable[[T], T]` 

`mkdocs.plugins.CombinedEvent` 

`mkdocs.exceptions.MkDocsException` 

`mkdocs.exceptions.ConfigurationError` 

`mkdocs.exceptions.BuildError` 

`mkdocs.exceptions.PluginError` 

`mkdocs.plugins.get_plugin_logger(name: str) -> PrefixedLogger` 