HydePHP

HydePHP is a static site generator for developers who prefer PHP, Markdown and Blade to a separate JavaScript documentation stack. It turns source files into a website that can be served as ordinary static assets. That makes it useful for package documentation, technical blogs and small content sites whose readers do not need a database-backed application on every request.

The project is built on Laravel Zero and follows conventions for different kinds of content. Markdown pages, Blade pages, blog posts and documentation pages can coexist in one project. You can begin with plain writing and use templates where a page needs more control over its layout.

A familiar workflow for PHP developers

The basic workflow is to write source files, run a build and publish the generated site. Composer manages the PHP dependencies, and the command-line interface handles the site generation. The deployed output does not need the same runtime as the machine that built it, which opens up simple static hosting options.

This distinction is useful for a package maintainer. Documentation can be reviewed alongside source changes, built in an automated workflow and published as a versioned artifact. The source repository remains the place to edit content; the generated HTML is what readers receive. Editing generated files directly creates changes that disappear at the next build.

Herd is a convenient local environment for the PHP side of that workflow. It is still important to follow Hyde's project layout and build instructions rather than treating the generated site as a conventional Laravel application with request-time controllers. Most of the interesting work happens during compilation.

Documentation without a separate frontend project

Documentation pages live in a dedicated source directory. Hyde builds the surrounding navigation and documentation layout, so maintainers can focus on the sequence of information a reader needs. A small handbook can begin with an overview, installation instructions and a troubleshooting page, then grow as the package earns more detailed guidance.

Front matter supplies metadata such as page titles and navigation priorities. That helps separate the content's meaning from its presentation. A reader should encounter installation before advanced extension points because the guide has a sensible order, not because the filenames happen to sort that way.

Relative links between source pages are another useful part of the workflow. Check the generated links after building, especially when moving files or changing section structure. A successful compiler exit does not by itself prove that every installation guide still points to the correct next step.

Blogs and standalone pages

Hyde is not limited to documentation. Its blog conventions support post metadata and generated feeds, while ordinary Markdown pages suit content such as an about page or a project overview. Blade pages offer a route to more custom layouts when a document needs a richer structure than Markdown can comfortably express.

That combination can keep a small project site cohesive. The homepage can introduce the package, documentation can explain how to use it, and a blog can record meaningful releases. The same repository holds the content and templates, making it easier to review a change that affects several parts of the site.

Be selective about adding custom presentation. If a page is mostly prose, Markdown remains easier to edit and compare in a pull request. Use Blade where the layout has a real purpose, such as a feature comparison or a project showcase, rather than turning every paragraph into a template-maintenance task.

What we exercised locally

The accompanying WirePackages tutorial builds a two-page package handbook in a real Hyde project inside the Herd workspace. One page introduces the handbook and its release checklist; the other covers installation preparation. Both include navigation metadata and a link to the other page.

The build uses the project's installed dependencies and writes the static output. A verification script then checks that the expected HTML pages exist, contain the intended headings and reference the corresponding generated page names. This establishes a concrete Markdown-to-HTML workflow rather than merely describing a potential setup.

That small example is intentionally reusable. It does not require an API key, a database or a paid syntax-highlighting service to demonstrate the documentation structure. Readers can inspect the source and compare it with the generated pages before adding their own package-specific instructions.

Where a static site fits

A static documentation site works well when content changes through a build and readers mostly browse, search and follow links. It is a different fit from an application that needs authenticated editing, per-user dashboards or transactional forms. Those requirements may call for a dynamic service alongside the site or a different application architecture.

Choose the publishing workflow with the authors in mind too. Developers who already review Markdown in Git may find it natural. A team whose writers need a browser-based editorial workflow should plan that part explicitly. The fact that the output is simple does not automatically decide how people collaborate on its source.

Before deploying, configure the public site URL and inspect metadata, assets and internal links under the intended hosting path. Test a narrow viewport and keyboard navigation. These checks are small compared with writing the documentation, but they determine whether readers can comfortably use the result.

Project and ownership

HydePHP is an open-source project with an MIT licence. Its project metadata identifies Emma De Silva as the author. The WirePackages entry was prepared editorially and can be claimed through the configured verified maintainer address, after which its owner can keep links, imagery and compatibility information current.

Sources: HydePHP, HydePHP 2 documentation, and the Hyde project repository. Image: the official HydePHP homepage. The linked tutorial contains the locally built documentation example.