allow hiding footer

[raylu]

Describe the feature

I'd like to hide the "Made with Dracula Theme for MkDocs" that appears on every page

Use Case

it's too bright

Proposed Solution

No response

Other Information

it looks like it's possible to do this now with

theme:
  name: dracula
  custom_dir: docs/dracula_overides

and then creating an empty docs/dracula_overrides/modules/footer.html file

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

SDK version used

I don't know what this means

Environment details (OS name and version, etc.)

all

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord or schedule a call!

[FernandoCelmer]

Review: Allow hiding the footer

Summary

This request asks for a first-class way to hide (or customize) the "Made with Dracula Theme for MkDocs" footer that appears at the bottom of every page. The reporter notes it conflicts with their design because it is visually prominent, and they have already found a workaround using MkDocs' custom_dir override mechanism.

---

Analysis

Current behavior

The footer lives in mkdocs_dracula_theme/modules/footer.html and is included unconditionally via a {% block footer %} in base.html:

{%- block footer %}
    {% include "/modules/footer.html" %}
{%- endblock %}

Because it uses a named Jinja2 block, MkDocs' standard template-override system already allows users to suppress or replace it without modifying the theme source — the workaround the reporter described is correct and functional today.

Complexity: Low. The building blocks (named block, override directory) are already in place. The missing piece is just a documented, theme-native toggle so users don't have to discover the workaround themselves.

Status: Open, triaged as feature-request. No implementation PR exists yet.

---

Implementation Options

Option A — Theme configuration flag (recommended)

Add a boolean key to mkdocs_theme.yml (e.g. show_footer: true) and wrap the include in base.html with a conditional:

{%- block footer %}
    {% if config.theme.show_footer != false %}
        {% include "/modules/footer.html" %}
    {% endif %}
{%- endblock %}

Users opt out with a single line in mkdocs.yml:

theme:
  name: dracula
  show_footer: false

Trade-offs: Zero extra files for users; cleanest UX; requires a minor theme release.

Option B — Document the custom_dir workaround

Add a section to the docs (and/or INSTALL.md) explaining the override path the reporter already found:

theme:
  name: dracula
  custom_dir: docs/overrides

Then create docs/overrides/modules/footer.html with either empty content or a custom footer.

Trade-offs: No code change needed; ships immediately. Downside: still requires users to create extra files and understand MkDocs' override system.

Option C — Expose a footer_text config key

Similar to Option A, but instead of a boolean, accept a custom string (or null/empty to hide). This is more flexible — users can replace the text entirely, not just hide it.

theme:
  name: dracula
  footer_text: "© 2025 My Company"   # or leave empty to hide

Trade-offs: More flexible, but slightly more complex to implement and validate. Could be a follow-up on top of Option A.

Option D — CSS-only workaround via extra_css

Users can hide the footer today by adding a custom CSS rule:

footer { display: none; }

Trade-offs: No theme changes needed; brittle (depends on the element type not changing) and doesn't remove the HTML from the DOM. Not a great long-term solution.

---

Recommendation

Go with Option A as the primary fix, and add Option B's documentation as an immediate stop-gap until the release lands.

Option A is a small, self-contained change — it only touches base.html and mkdocs_theme.yml — and it produces the cleanest developer experience. The conditional check (!= false) preserves backwards compatibility: existing installs keep the footer by default and only opt out explicitly.

If you'd like to take a swing at this, the change is roughly:

1. In mkdocs_dracula_theme/mkdocs_theme.yml, add:

   show_footer: true

2. In mkdocs_dracula_theme/base.html, wrap the footer block:

   {%- block footer %}
       {% if config.theme.show_footer != false %}
           {% include "/modules/footer.html" %}
       {% endif %}
   {%- endblock %}

3. Update the docs with the new option and note the custom_dir workaround for more advanced customization.

Happy to review a PR if someone picks this up.