Documentation

A searchable documentation site at /docs — categories, articles, and optional versions — for the products you sell or the services you provide. It sits at its own address and doesn't touch your existing pages.

What visitors get

/docs — the documentation home, with search across every published article (/docs/_search, never cached).
A page per article in a three-column layout: the category link tree, the article, and an on-this-page outline.
Version switching, when versioning is on, so customers on an older release keep the instructions that match what they have.

With AI Chat on, the chat assistant reads your published articles when it answers visitors.

What the dashboard gets

Documentation in the sidebar (Manager and above):

Articles — write and edit articles, each in a category.
Categories — group articles the way customers ask questions.
Versions — keep separate copies of the docs for different releases.
Settings — turn version switching on or off.

The first time the feature is enabled, a starter version, category and Welcome article are created for you.

Publishing WebProCMS's own documentation

WebProCMS documents itself: every release ships its user documentation (docs/kb/ and docs/cms-features/), and php artisan docs:import turns it into articles under Getting Started, Guides and Features. That is how webprocms.com publishes its docs. Most sites never run it — their /docs is their own product's documentation.

Imports never overwrite your work:

An article someone wrote on the install is never touched, even if it shares a slug with an imported one.
An imported article that was edited on the install — its text, title, category, order or published state — is kept as it is. Each imported article carries a fingerprint of what the import wrote, so an edit shows up as a mismatch and later imports skip it.
The Getting Started, Guides and Features categories are created once. Renaming or reordering them on the install sticks.
An article whose source hasn't changed isn't rewritten, so an import doesn't clear the page cache or re-index search for nothing.

Keeping imported docs current

The documentation files arrive with every update, but the articles live in the database, so they only change when the import runs. Running docs:import also turns on automatic refresh for that install: docs:refresh runs hourly through the background scheduler (LazyCron) and re-imports whenever the shipped docs have changed since the last import.

Only where docs:import was run. Demo data imports the same articles, but that isn't a choice to publish them, so a demo-seeded site — or one whose /docs holds only its own articles — is never refreshed.
Only while the Documentation feature is on.
Keyed on the files, not just the version. Each import records a fingerprint of every source file plus the CMS version (docs.imported_fingerprint), so a change is picked up however the files arrived — an in-app update, the release script's deploy, a hotfix or a git checkout.

Run php artisan docs:refresh to check straight away; it says what it did, or why there was nothing to do. An install that imported the docs before automatic refresh existed needs docs:import run once to turn it on.

Limitations

To hide an imported article, unpublish it — don't delete it. Unpublishing counts as an edit, so imports leave it hidden. A deleted article has no row left to compare against, so the next import (including the automatic one after an update) creates it again.
Docs follow releases. A change to the documentation reaches an install with the next CMS release, since that is when the files change.