Views

Use one of MarkdownView, LoggedInMarkdownView, or StaffMarkdownView from markdown_view.views to serve a .md file

from markdown_view.views import StaffMarkdownView

path('readme/',
    StaffMarkdownView.as_view(file_name='my_app/README.md'),
    name="readme"),

Settings

All settings are optional. See markdown_view/constants.py for the defaults.

• MARKDOWN_VIEW_BASE_DIR and BASE_DIR

  When present, the value is taken as a location to append to the list of dirs that Django’s django.template.utils.get_app_template_dirs will return when passed dirname=””. This is used to locate .md files in the root of the project, e.g., a README.md file. Looks for BASE_DIR if MARKDOWN_VIEW_BASE_DIR is not found.

• MARKDOWN_VIEW_LOADERS

  A list of loaders that locate .md files. The default list includes only markdown_view.loaders.MarkdownLoader which will by default try to load .md files from root directories in INSTALLED_APPS packages much the same as Django’s django.template.loaders.app_directories.Loader looks to load from “templates”.

• MARKDOWN_VIEW_LOADER_TEMPLATES_DIR

  The name of the directories in INSTALLED_APPS packages in which to locate .md files. Defaults to “” in order to locate .md filed in the root directories.

• MARKDOWN_VIEW_EXTENSIONS

  The extensions to enable. These extensions are enabled be default:

  • toc:

    generates a Table of Contents. If toc is removed from extensions, then MARKDOWN_VIEW_TEMPLATE_USE_TOC must be set to False.

  • tables:

    enables tables.

  • fenced_code:

    enables code blocks. If fenced_code is removed from extensions, then MARKDOWN_VIEW_TEMPLATE_USE_HIGHLIGHT_JS, which provides the highlighting for code blocks, can be disabled.

  • markdown_view.markdown_extensions.ImageExtension:

    makes images responsive in bootstrap4.

  See https://python-markdown.github.io/extensions/ and https://github.com/Python-Markdown/markdown/wiki/Third-Party-Extensions for more extensions.

  You can create your own extensions by following https://github.com/Python-Markdown/markdown/wiki/Tutorial-1—Writing-Extensions-for-Python-Markdown

• MARKDOWN_VIEW_TEMPLATE

  The Django template that’ll be used to render the HTML that is generated from the Markdown. Set your own template to style your pages. Context includes:

  • markdown_content:

    The HTML produced from the Markdown.

  • use_highlight_js:

    If highlight.js is enabled.

  • use_toc:

    If the table of contents should be rendered.

  • markdown_toc:

    A table of contents from the headers of the Markdown. Not set when use_toc is False.

  • page_title:

    A guess at a page title, for now it’s the first row of the TOC. Not set when use_toc is False, or when the Markdown has no headers for the TOC to be built from.

• MARKDOWN_VIEW_TEMPLATE_USE_TOC

  Whether to render the TOC. If false, in the template context, use_toc is False and markdown_toc and page_title are not present.

• MARKDOWN_VIEW_TEMPLATE_USE_HIGHLIGHT_JS

  Whether to load and activate the highlight.js library in the template.

• MARKDOWN_VIEW_REWRITE_INTERNAL_LINKS

  Defaults to True. Markdown source files commonly link to other .md files using plain, filesystem-relative links (e.g. [See also](../README-cron.md)), exactly as they’d resolve on GitHub or in a local editor. Since a rendered page is served at its view’s URL rather than at the source file’s location on disk, such a link would otherwise 404 in the browser.

  When enabled, MarkdownView looks up whether any URL pattern in the project serves the linked .md file via a MarkdownView (or subclass), and if so, rewrites the link to that view’s actual URL instead of leaving the raw relative file path in place. See markdown_view/registry.py for the resolution logic. This is best-effort: links to files that aren’t routed anywhere, or whose route is behind a required URL argument, are left exactly as Markdown would otherwise have rendered them – nothing breaks if a linked file simply isn’t routed, unless MARKDOWN_VIEW_UNRESOLVED_LINK_ROOT is also configured (see below). Set to False to disable this rewriting entirely, including the MARKDOWN_VIEW_UNRESOLVED_LINK_ROOT fallback.

• MARKDOWN_VIEW_UNRESOLVED_LINK_ROOT

  Defaults to None (disabled). Relative links that MARKDOWN_VIEW_REWRITE_INTERNAL_LINKS can’t resolve to a registered MarkdownView route – including links to files other than .md, such as repository-relative links to source code (e.g. [`example.module.helper`](src/example/module.py)) – are left unchanged by default. Setting this to a root URL instead resolves such links against it, e.g.:

  MARKDOWN_VIEW_UNRESOLVED_LINK_ROOT = (
      "https://git.example.com/example/project/-/blob/main/"
  )

  With the setting above, [`example.module.helper`](src/example/module.py) would render as a link to https://git.example.com/example/project/-/blob/main/src/example/module.py. Registered-route rewriting always takes precedence over this fallback; it only applies once a link has already failed to resolve to a route. ./ and ../ path segments, and any query string or #fragment, are resolved/preserved correctly. Absolute URLs, root-relative URLs, fragment-only links, and URLs with an explicit scheme are never affected by this setting.

• MARKDOWN_VIEW_ESCAPE_UNSAFE_TEMPLATE_SYNTAX

  Defaults to True. MarkdownView re-parses the HTML converted from Markdown as a Django template, so that the {% static %} tags ImageExtension injects for image sources (and, when MARKDOWN_VIEW_USE_REQUEST_CONTEXT/MARKDOWN_VIEW_EXTRA_CONTEXT are used, any {{ variable }} reference to a real context key) actually resolve. Markdown source files are prose, though, and prose about Django itself routinely contains literal {% … %}/{{ … }} text that was never meant to be executed as a template – left unescaped, an unrecognized {% … %} block raises TemplateSyntaxError (a hard 500 for the whole page), and an unrecognized {{ … }} variable is silently rendered as an empty string (silent content loss, with no error at all).

  When enabled (the default), every {% … %}/{{ … }} span in the converted HTML is escaped to inert literal text except the exact {% static ‘…’ %} tags ImageExtension injects, and bare {{ identifier }} references to a name actually present in the context the page renders with. See markdown_view/escaping.py for the exact rules. Set to False to restore the previous, fully-permissive behavior (the whole converted document is parsed as a real Django template, with no escaping at all).

Experimental Settings

• MARKDOWN_VIEW_USE_REQUEST_CONTEXT

  If the request context should be used as a base when creating the context with which to render the Markdown internally. This is because the Markdown is rendered once first in order to prepend it with {% load static %}. This is not well tested; YMMV. Note that a {{ name }} reference only resolves against this context if MARKDOWN_VIEW_ESCAPE_UNSAFE_TEMPLATE_SYNTAX (see above) recognizes name as a safe context key – otherwise it’s escaped to literal text rather than looked up.

• MARKDOWN_VIEW_EXTRA_CONTEXT

  Any extra context to send to the internal render of the Markdown. Can be used to expose context to template tags embedded in the Markdown. This is not well tested; YMMV. As with MARKDOWN_VIEW_USE_REQUEST_CONTEXT above, a {{ name }} reference to one of these keys is only left live when MARKDOWN_VIEW_ESCAPE_UNSAFE_TEMPLATE_SYNTAX recognizes it as safe.

Publishing beta / pre-releases

Beta and other pre-releases can be published to PyPI the same way as a regular release, and this is standard practice: PyPI understands PEP 440 pre-release version identifiers and will not let a plain pip install django-markdown-view pick them up by default, so betas are safe to publish without risking accidental adoption.

1. Tag the release commit with an explicit PEP 440 pre-release suffix instead of a plain version, e.g. 0.0.6b1 for a beta, or 0.0.6rc1 for a release candidate. setuptools_scm will pick up the tag as-is.

2. Create a GitHub Release for that tag and check the “Set as a pre-release” box. This only affects how the release is labeled on GitHub; PyPI determines pre-release status purely from the version string.

3. Publishing the release triggers the same Publish to PyPI workflow, which uploads the pre-release to PyPI. It will appear in the release history but will not be installed by pip install django-markdown-view.

4. Users who want to try it must opt in, e.g. pip install --pre django-markdown-view or by pinning the exact version, such as pip install django-markdown-view==0.0.6b1.

5. If further fixes are needed, bump the pre-release number (0.0.6b2, 0.0.6b3, …) rather than reusing one, since PyPI does not allow re-uploading files for a version that has already been published. Once the release is stable, tag and publish the final version without a suffix (e.g. 0.0.6), which then becomes installable by default.