1.5.0

[oprypin]

New: MkDocs now accepts donations. Please consider supporting the current maintainer at my new GitHub sponsorship page.

MkDocs has been a totally free project since the beginning and wasn't accepting funds. MkDocs will remain free of paywalls, but now you can show your support with donations (one-time and/or recurring).

Donate for MkDocs - @oprypin sponsors page

And please also consider these other individuals who have been contributing to the ecosystem for a long time and check out their donations pages:

@facelessuser
@pawamoy
@Ultrabug

---

Release 1.5.0

New command mkdocs get-deps

This command guesses the Python dependencies that a MkDocs site requires in order to build. It simply prints the PyPI packages that need to be installed. In the terminal it can be combined directly with an installation command as follows:

pip install $(mkdocs get-deps)

The idea is that right after running this command, you can directly follow it up with mkdocs build and it will almost always "just work", without needing to think which dependencies to install.

The way it works is by scanning mkdocs.yml for themes:, plugins:, markdown_extensions: items and doing a reverse lookup based on a large list of known projects (catalog, see below).

Of course, you're welcome to use a "virtualenv" with such a command. Also note that for environments that require stability (for example CI) directly installing deps in this way is not a very reliable approach as it precludes dependency pinning.

The command allows overriding which config file is used (instead of mkdocs.yml in the current directory) as well as which catalog of projects is used (instead of downloading it from the default location). See mkdocs get-deps --help.

Context: #3205

MkDocs has an official catalog of plugins

Check out https://github.com/mkdocs/catalog and add all your general-purpose plugins, themes and extensions there, so that they can be looked up through mkdocs get-deps.

This was renamed from "best-of-mkdocs" and received significant updates. In addition to pip installation commands, the page now shows the config boilerplate needed to add a plugin.

Expanded validation of links

Validated links in Markdown

As you may know, within Markdown, MkDocs really only recognizes relative links that lead to another physical *.md document (or media file). This is a good convention to follow because then the source pages are also freely browsable without MkDocs, for example on GitHub. MkDocs knows that in the output it should turn those *.md links into *.html as appropriate, and it would also always tell you if such a link doesn't actually lead to an existing file.

However, the checks for links were really loose and had many concessions. For example, links that started with / ("absolute") and links that ended with / were left as is and no warning was shown, which allowed such very fragile links to sneak into site sources: links that happen to work right now but get no validation and links that confusingly need an extra level of .. with use_directory_urls enabled.

Now, in addition to validating relative links, MkDocs will print INFO messages for unrecognized types of links (including absolute links). They look like this:

INFO - Doc file 'example.md' contains an absolute link '/foo/bar/', it was left as is. Did you mean 'foo/bar.md'?

If you don't want any changes, not even the INFO messages, and wish to revert to the silence from MkDocs 1.4, add the following configs to mkdocs.yml (not recommended):

validation:
  absolute_links: ignore
  unrecognized_links: ignore

If, on the opposite end, you want these to print WARNING messages and cause mkdocs build --strict to fail, you are recommended to configure these to warn instead.

See documentation for actual recommended settings and more details. Context: #3283

Validated links in the nav

Links to documents in the nav configuration now also have configurable validation, though with no changes to the defaults.

You are welcomed to turn on validation for files that were forgotten and excluded from the nav. Example:

validation:
  nav:
    omitted_files: warn
    absolute_links: warn

This can make the following message appear with the WARNING level (as opposed to INFO as the only option previously), thus being caught by mkdocs --strict:

INFO - The following pages exist in the docs directory, but are not included in the "nav" configuration: ...

See documentation. Context: #3283, #1755

Mark docs as intentionally "not in nav"

There is a new config not_in_nav. With it, you can mark particular patterns of files as exempt from the above omitted_files warning type; no messages will be printed for them anymore. (As a corollary, setting this config to * is the same as ignoring omitted_files altogether.)

This is useful if you generally like these warnings about files that were forgotten from the nav, but still have some pages that you knowingly excluded from the nav and just want to build and copy them.

The not_in_nav config is a set of gitignore-like patterns. See the next section for an explanation of another such config.

See documentation. Context: #3224, #1888

Excluded doc files

There is a new config exclude_docs that tells MkDocs to ignore certain files under docs_dir and not copy them to the built site as part of the build.

Historically MkDocs would always ignore file names starting with a dot, and that's all. Now this is all configurable: you can un-ignore these and/or ignore more patterns of files.

The exclude_docs config follows the .gitignore pattern format and is specified as a multiline YAML string. For example:

exclude_docs: |
  *.py               # Excludes e.g. docs/hooks/foo.py
  /drafts            # Excludes e.g. docs/drafts/hello.md
  /requirements.txt  # Excludes docs/requirements.txt

Validation of links (described above) is also affected by exclude_docs. During mkdocs serve the messages explain the interaction, whereas during mkdocs build excluded files are as good as nonexistent.

As an additional related change, if you have a need to have both README.md and index.md files in a directory but publish only one of them, you can now use this feature to explicitly ignore one of them and avoid warnings.

See documentation. Context: #3224

Drafts

The exclude_docs config has another behavior: all excluded Markdown pages will still be previewable in mkdocs serve only, just with a "DRAFT" marker on top. Then they will of course be excluded from mkdocs build or gh-deploy.

If you don't want mkdocs serve to have any special behaviors and instead want it to perform completely normal builds, use the new flag mkdocs serve --clean.

See documentation. Context: #3224

mkdocs serve no longer exits after build errors

If there was an error (from the config or a plugin) during a site re-build, mkdocs serve used to exit after printing a stack trace. Now it will simply freeze the server until the author edits the files to fix the problem, and then will keep reloading.

But errors on the first build still cause mkdocs serve to exit, as before.

Context: #3255

Page titles will be deduced from any style of heading

MkDocs always had the ability to infer the title of a page (if it's not specified in the nav) based on the first line of the document, if it had a <h1> heading that had to written starting with the exact character #. Now any style of Markdown heading is understood (#1886). Due to the previous simplistic parsing, it was also impossible to use attr_list attributes in that first heading (#3136). Now that is also fixed.

Markdown extensions can use paths relative to the current document

This is aimed at extensions such as pymdownx.snippets or markdown_include.include: you can now specify their include paths to be relative to the currently rendered Markdown document, or relative to the docs_dir. Any other extension can of course also make use of the new !relative YAML tag.

markdown_extensions:
  - pymdownx.snippets:
      base_path: !relative

See documentation. Context: #2154, #3258

<script> tags can specify type="module" and other attributes

In extra_javascript, if you use the .mjs file extension or explicitly specify a type: module key, the script will be added with the type="module" attribute. defer: true and async: true keys are also available.

See updated documentation for extra_javascript.

At first this is only supported in built-in themes, other themes need to follow up, see below.

Context: #3237

Changes for theme developers (action required!)

Using the construct {% for script in extra_javascript %} is now fully obsolete because it cannot allow customizing the attributes of the <script> tag. It will keep working but blocks some of MkDocs' features.

Instead, you now need to use config.extra_javascript (which was already the case for a while) and couple it with the new script_tag filter:

    {%- for script in config.extra_javascript %}
      {{ script | script_tag }}
    {%- endfor %}

See documentation.

Upgrades for plugin developers

• Breaking change: config.extra_javascript is no longer a plain list of strings, but instead a list of ExtraScriptValue items. So you can no longer treat the list values as strings. If you want to keep compatibility with old versions, just always reference the items as str(item) instead. And you can still append plain strings to the list if you wish. See information about <script> tags above. Context: Support <script type="module"> and other attributes #3237

• File has a new attribute inclusion. Its value is calculated from both the exclude_docs and not_in_nav configs, and implements their behavior. Plugins can read this value or write to it. New File instances by default follow whatever the configs say, but plugins can choose to make this decision explicitly, per file.

• When creating a File, one can now set a dest_uri directly, rather than having to update it (and other dependent attributes) after creation. Context

• A new config option was added - DictOfItems. Similarly to ListOfItems, it validates a mapping of config options that all have the same type. Keys are arbitrary but always strings. Context: Add DictOfItems type for configuration options #3242

• A new function get_plugin_logger was added. In order to opt into a standardized way for plugins to log messages, please use the idiom:

  log = mkdocs.plugins.get_plugin_logger(__name__)
  ...
  log.info("Hello, world")

  Context: Add plugin logger #3245

• SubConfig config option can be conveniently subclassed with a particular type of config specified. For example, class ExtraScript(SubConfig[ExtraScriptValue]):. To see how this is useful, search for this class in code. Context

• Bugfix: SubConfig had a bug where paths (from FilesystemObject options) were not made relative to the main config file as intended, because config_file_path was not properly inherited to it. This is now fixed. Context: Pass config file path through SubConfig to Config #3265

• Config members now have a way to avoid clashing with Python's reserved words. This is achieved by stripping a trailing underscore from each member's name.

  Example of adding an async boolean option that can be set by the user as async: true and read programmatically as config.async_:

  class ExampleConfig(Config):
      async_ = Type(bool, default=False)

  Previously making a config key with a reserved name was impossible with new-style schemas. Context

• Theme has its attributes properly declared and gained new attributes theme.locale, theme.custom_dir.

• Some type annotations were made more precise. For example:

  • The context parameter has gained the type TemplateContext (TypedDict). Context
  • The classes Page, Section, Link now have a common base class StructureItem. Context
  • Some methods stopped accepting Config and only accept MkDocsConfig as was originally intended. Context
  • config.mdx_configs got a proper type. Context: Clarify that Private config can be accessed, add a type to mdx_configs #3229

Theme updates

• Built-in themes mostly stopped relying on <script defer>. This may affect some usages of extra_javascript, mainly remove the need for custom handling of "has the page fully loaded yet". Context: Support <script type="module"> and other attributes #3237

• "mkdocs" theme now has a styling for > blockquotes, previously they were not distinguished at all. Context: Add blockquote styling for mkdocs theme #3291

• "readthedocs" theme was updated to v1.2.0 according to upstream, with improved styles for <kbd> and breadcrumb navigation. Context: Update to rtd theme v1.2.0 #3058

• Both built-in themes had their version of highlight.js updated to 11.8.0, and jQuery updated to 3.6.0.

Bug fixes

Relative paths in the nav can traverse above the root

Regression in 1.2 - relative paths in the nav could no longer traverse above the site's root and were truncated to the root. Although such traversal is discouraged and produces a warning, this was a documented behavior. The behavior is now restored.

Context: #2752, #3010

MkDocs can accept the config from stdin

This can be used for config overrides on the fly. See updated section at the bottom of Configuration Inheritance.

The command to use this is mkdocs build -f -. In previous versions doing this led to an error.

Context

New command line flags

• mkdocs --no-color build disables color output and line wrapping. This option is also available through an environment variable NO_COLOR=true. Context: Make colorful/indented output optional, decrease indent #3282
• mkdocs build --no-strict overrides the strict config to false. Context: Add mkdocs build --no-strict that overrides strict: true #3254
• mkdocs build -f - (described directly above).
• mkdocs serve --clean (described above).
• mkdocs serve --dirty is the new name of mkdocs serve --dirtyreload.

Deprecations

• extra_javascript underwent a change that can break plugins in rare cases, and it requires attention from theme developers. See respective entries above.

• Python-Markdown was unpinned from <3.4. That version is known to remove functionality. If you are affected by those removals, you can still choose to pin the version for yourself: Markdown <3.4. Context: Un-pin upper version of Python-Markdown #3222, Support latest realise of Markdown library #2892

• mkdocs.utils.warning_filter now shows a warning about being deprecated. It does nothing since MkDocs 1.2. Consider get_plugin_logger or just logging under mkdocs.plugins.* instead. Context: Deprecate mkdocs.utils.warning_filter #3008

• Accessing the _vars attribute of a Theme is deprecated - just access the keys directly.

• Accessing the user_configs attribute of a Config is deprecated. Note: instead of config.user_configs[*]['theme']['custom_dir'], please use the new attribute config.theme.custom_dir.

Other small improvements; see commit log.

---

This discussion was created from the release 1.5.0.

[Andre601]

Something I never quite managed to figure out....

Is there a setting/configuration that would allow to have absolute links, such as /foo/bar be transformed/altered to include any sub-pages?

Like when MkDocs is configured that the canonical URL is https://example.com/blog, can it be configured that it would alter any absolute links to have /blog prefixed to them (Turning /foo/bar into /blog/foo/bar)?

Or maybe a more optimal setting that forces these links to become relative ones.
Like when /foo/bar is in /docs/example/index.md, that it would turn it into ../foo/bar

This has been the bain of my existance for some projects in the past and so far I couldn't find a configuration or a proper plugin/extension that would allow these things to happen.

I obviously can use relative links from the start - which thanks to VSCode displaying folders and files, making it much easier to orient myself around - but when I move pages around is that always a thing to struggle with as I would need to re-arange these links for all changed files rather than having them absolute and let mkdocs (Or a plugin/extension) deal with it...

I know this is a rather strange thing to ask on this discussion, but the mention of expanded validation of
links made me think about this, so I'm asking here...

[oprypin]

I have that in sights for 1.6.0

[oprypin]

You can open an issue with this text, then I'll have something to reference, and it's always helpful to have an insight into use case.

[Guts]

Thank you and every contributor for the work. It's definitely a big release!

However, as a developer of plugins and maintainer of sites based on Mkdocs, I wonder if it wouldn't have been better to publish a 2.0.0 release (or at least a 1.5.0-beta1 for a while) given that there are a lot of changes to the internal API?
I've got the impression that this release has caused a lot of issues and PRs (some to pin mkdocs<1.5) in the plugins and themes ecosystem.

So I was wondering what the versioning policy is on Mkdocs?

[Guts]

Thanks @ultrabug for your insight.

Maybe plugin developers and maintainers (which I'm part of as well) should pin their mkdocs requirements better as well. I know I will.

A few months later, @oprypin asked me to remove upper pin (Guts/mkdocs-rss-plugin#137). I think he was right (and RSS plugin is not directly impacted by the 1.5 breaking changes), again the idea is not to blame, just understand; but the whole thing about versioning is a bit confusing, at least for me (I'm not pretending to talk for others). So, that's why I'm asking to have a clearer idea.

And why not write a paragraph in the dev documentation about versioning philosophy?

[ultrabug]

Sure, if you feel like starting that on a PR I'm sure we'll get it in mate!

[oprypin]

I expected that kind of response

Well if you expected it then you could have preventatively further reworded it to try not to hurt my ego 😂

But I've seen some signals from Material for Mkdocs, the minify plugin, or the mermaid plugin...

Material has fully jumped on 1.5 right away, not sure what you mean. Minify I made sure to fix it first. Mermaid that was my oversight and I don't know why they're handling it by including it into a huge refactor rather than a quick 1-line edit, but oh well.

I thought I had a very wide coverage of plugins in my regressions test suite and I wasn't seeing any breakages. But clearly it wasn't enough.

I missed the mark on this particular breakage. I misjudged how bad it would be. Not causing breakages is my main job. In this case I just thought it would be crazy to even try to do something in a non-breaking way. Or the feature would technically be non-breaking but never possible for users to really adopt.

Let me continue on versioning in a next message.

[oprypin]

The versioning is decidedly not semver, I think almost every release would be major then, because any tiny aspect of implementation could have something relying on it.
And we also have to keep in mind that MkDocs is an application, not a library, and the versioning is decidedly not aimed at plugin developers.

• The versioning logic for 1.x.0 is as follows, then:
  Don't make any changes that users could be surprised about - any changes that can be seen as an actual change rather than an improvement. If some site builds now, it should build the same in the new version. New features are opt-ins in almost all cases.

  The promise towards plugin developers: don't break any common use case. For things that look more like a public API: don't break anything even slightest unless it has a trivial fix that will still keep it compatible with older versions too.

• The versioning logic for 1.x.y is as follows: no changes to features. It may be acceptable to revert behavior changes introduced in 1.x.0.

• The versioning logic for x.0.0 is as follows: probably will not happen. MkDocs itself isn't such a huge deal to warrant breaking the ecosystem. The ecosystem is the vast majority of its value.

[oprypin]

How the current situation with ExtraScriptValue relates to this:

The promise towards plugin developers: don't break any common use case. For things that look more like a public API: don't break anything even slightest unless it has a trivial fix that will still keep it compatible with older versions too.

I thought it was OK per the latter category but it is in fact a common use case and should've ended at the former category