Content_Panel module

Summary content goes here.

what the content panel actually does ✅

The hb.content_panel module wires in a reusable panel that shows up on single-type pages (blog posts, docs pages, etc.). Out of the box it can surface three kinds of extras:

• Edit/Source buttons – taken from the repo info you supply, so a reader can jump straight to “view source” or “edit this page” in GitHub/GitLab/etc.
• Translation jump list – if you run multilingual content, it auto-lists other language variants.
• Comment controls – it can toggle comments globally or per section.

So it’s not required for a page to render, but it enriches every post/doc with these meta actions instead of you wiring them manually each time.

what repo.subpath: exampleSite means

In the doc snippet you noticed:

1[params.hb.content_panel.repo]
2  service = "github"
3  repo    = "user/name"
4  branch  = "main"
5  subpath = "exampleSite"

repo.subpath is the folder inside your repository where Hugo content lives. If your site repository looks like:

my-repo/
  exampleSite/
    content/
    config/

…then subpath = "exampleSite" tells the module to insert that folder into the URLs it builds. Without it, the “Edit on GitHub” button would point to github.com/user/name/content/post.md; with subpath, it points to github.com/user/name/exampleSite/content/post.md, which is the real location. On your project, because content sits at the repo root, you can leave subpath blank (which is what we currently do).

why keep the content panel even if pages render “fine”

• Consistency and automation: every single/detail page inherits the same call-to-action bar without duplicating shortcodes.
• Editor friendliness: the repo buttons become a cheat-code for you (or collaborators) to dive into GitHub and edit a post quickly.
• Comments toggle: rather than flipping comments per layout, you control them centrally here.
• Future-proofing: the HBStack blog/docs modules expect this partial to exist. Removing it means you’ll hand-wire equivalent UX later whenever you want edit links, translations, etc.

If you truly don’t need edit links or translation hints, you can turn the module off by removing the repo block (or setting hb.blog.content_panel.enable = false), but it’s generally worth keeping because the cost is tiny and the convenience compounds.

how to use it in blog posts, docs, or even the footer

1. Blog posts / docs (default integration) The HB blog and docs modules already look for the panel. In hb.blog.yaml you’ve got:

   1hb:
   2  blog:
   3    content_panel:
   4      repo:
   5        service: github
   6        repo: hbstack/theme # <- update this to your own repo if you want accurate edit links
   7        branch: main
   

   Update repo/branch to match your GitHub project (AbdulSayyed/ghafoors-blog and your active branch). The docs module fragment already points to your repo, so docs pages get the proper links today.

2. Footer or other sections The content panel is just a partial called hb/modules/content-panel. You can drop it anywhere with:

   {{ partial "hb/modules/content-panel" (dict "Page" .) }}
   

   Use it sparingly (it’s pretty tall), but if you want a “Contribute” block in the footer or sidebar, that’s the hook.

3. Disabling per section If, say, you want it on blog posts but not on landing pages, you can override in front matter:

   1hb:
   2  content_panel:
   3    enable: false
   

   …or set hb.blog.content_panel.enable = false in params if you want to hide it across the entire blog section.

tl;dr

• subpath is the repo subfolder the content lives in, leave empty if your content is at the root.
• Keep the module because it auto-generates edit/source buttons, translation hints, and comment toggles—removing it just means you’ll rebuild that UX yourself later.
• To use it, supply repo details under hb.blog.content_panel (and hb.docs.content_panel, etc.) or call the partial manually if you want it someplace custom like the footer.

Conclusion

FAQs