Skip to content

Plugin Documentation – WordPress Plugin Boilerplate

Use the docs/ folder for all plugin documentation. Organize files and subfolders in any structure that fits the project.

Group documentation by feature, workflow, or integration. Create subfolders when it helps discovery, and keep filenames descriptive so they can be linked directly from the project README or other docs. Author docs as MDX so components can be used when helpful.

When you add, rename, or significantly expand docs, update the overview docs that help people discover them:

  • docs/index.mdx as the docs landing page
  • the project README
  • AGENTS.md if present
  • the unified wp-plugin-bp skill routing and references in .agents/skills/wp-plugin-bp/

Front matter is optional, and documentation can be created freely. Using it is a best practice; when you include it, add a title, a short_title, and a description so automated tooling can parse the docs.

---
title: Asset Bundling
short_title: Bundling
description: How scripts and styles are built and enqueued.
---

Do not repeat the front matter title as an H1 in the body. Start with a short paragraph or an H2 such as ## Overview.

---
title: Asset Bundling
short_title: Bundling
description: How scripts and styles are built and enqueued.
---
Short intro paragraph.
## Overview
...

Use Expressive Code attributes on fenced code blocks. These attributes are ignored when unsupported, so it is best practice to include them consistently.

  • Always specify a language for syntax highlighting (e.g. bash, php, js).
  • Add a title="..." when the snippet belongs to a file or a terminal session.
Terminal
npm run build
src/Demo_Plugin.php
private function enqueue_entrypoint( string $entry, array $localize_data = array() ): void

When documenting folder layouts, use the Starlight FileTree component so directories and files render consistently.

import { FileTree } from '@astrojs/starlight/components';
<FileTree>
- src
- ...
</FileTree>
  • PHP67%
  • JavaScript33%