Wiki Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for a knowledge base / internal wiki. This bundle is a drop-in wiki surface (page management, edit screens, rich-text editing, HTML↔Markdown handling) rather than a bespoke CMS build. The v1.6.4 line shows the kind of steady maintenance cadence you'd otherwise have to staff yourself — dependency refresh, coding-standard automation, doc compliance sweeps — which is the core of the buy case.
• Scope decisions on "docs in-product." If documentation, help content, or an internal wiki is on the roadmap, this lets you commit to the capability without committing to an editor stack: the editing experience rides on the bundled Tiptap editor (tiptap-editor-bundle moving 1.3.10 → 1.5.0) rather than an in-house rich-text implementation.
• Content portability and exit strategy. league/html-to-markdown in the dependency set means stored content can be exported to Markdown — relevant when deciding whether content is locked in, and when negotiating "what happens if we replace this."
• Release-train planning. v1.6.4 is a patch bump with no declared breaking changes, so it can slot into routine maintenance windows. The one behavioral item (form-body rendering through the child loop, REQ-TWIG-003) is a rendering-parity fix on the page-edit screen, not a feature change — no user-facing roadmap impact, but it does mean any custom override of manage/page_edit.html.twig needs a visual check before shipping.
• Editor UX roadmap input. The two non-trivial dependency jumps (tiptap-editor-bundle 1.3.10 → 1.5.0 and form-kit-bundle 2.7.1 → 2.12.0) are minor-version changes to the authoring experience. If rich-text authoring quality is a differentiator for your users, these are the releases to demo internally; if it's incidental, treat them as routine.

When to Consider This Package

Adopt when:

• You need an in-application wiki / documentation surface and the authoring experience is "good enough," not a product differentiator.
• Your stack is PHP with Twig-based templating. Caveat worth confirming early: the release notes describe Twig views, a Symfony-style bundle layout, and FrankenPHP demos — this reads as a Symfony/Twig bundle, not a Laravel package. If your application is Laravel, verify integration path (or wrapper effort) before it enters a roadmap commitment.
• You want maintenance offloaded: lockfile refreshes, php-cs-fixer config, PHPStan tooling, and a documented spec inventory (92/92 requirements tracked) are already in place.
• You value an upgrade trail: an UPGRADING.md with anchor-linked migration notes per release is a real signal for a component you'll own for years.

Look elsewhere when:

• You need deep customization of the page-edit UI. v1.6.4 explicitly preserves custom markup for title and content fields while routing remaining children through a generic loop — overrides of that template will need to be re-validated on every release that touches it. That's a recurring maintenance tax.
• You require a published deprecation policy or semantic-versioning guarantees; patch releases here also carry unrelated documentation/compliance sweeps, which makes changelogs noisier than a strict semver consumer expects.
• Collaboration features (comments, versioning, permissions granularity, real-time co-editing) are must-haves — nothing in this release speaks to them.
• You're not on Twig/FrankenPHP-adjacent infrastructure and don't want to absorb that stack.

How to Pitch It (Stakeholders)

To executives: This is a buy-not-build decision for internal documentation/wiki capability. v1.6.4 is a low-risk maintenance release — no breaking changes, no migrations required beyond an optional visual check of the page-edit screen. The strategic value is that someone else carries the upkeep: dependency currency, code standards, and a documented requirements inventory, all visible in this release. What we're buying is avoided engineering headcount, not novel features.

To engineering: Patch release v1.6.4. One behavioral change: manage/page_edit.html.twig now renders residual form children through {% for child in form %} + not child.rendered + form_row(child) and closes with form_end(form) instead of render_rest: false — if we've overridden that template, re-test the edit screen. Dependency movement to note: tiptap-editor-bundle 1.3.10 → 1.5.0 and form-kit-bundle 2.7.1 → 2.12.0 (minor jumps on the authoring path, worth a smoke test); the rest (phpstan-frankenphp, jsdom, league/html-to-markdown) are routine. Also flag the framework fit: this presents as Symfony/Twig, so confirm Laravel integration effort before we size the work.