Tree Bundle Laravel Package

Product Decisions This Supports

• CMS build-vs-buy for Laravel shops. The package provides the content-modelling core (typed tree nodes, Twig-rendered templates) so our engineering effort goes into differentiated product surface rather than content plumbing. This release is a patch, but it strengthens the case that the package is actively maintained and safe to build on at 0.x.
• SEO as a product requirement, not an afterthought. The SEO title separator change (hyphen → pipe) is a small, visible formatting decision we can spec directly instead of hacking around in templates. Worth aligning with our brand/title conventions before we bake it into page templates.
• Dynamic and multi-source listing pages. The TreeNodeType change allowing query_builder to be overridden is the most strategically relevant item here: it means per-content-type data sourcing (external APIs, filtered feeds, curated/personalised lists) without forking the package. This unblocks roadmap items like "related content" and "search-driven landing pages."
• Predictable page metadata. Resolving Title/Excerpt by considering favourite keys first makes listing cards, navigation labels, and OG/social metadata deterministic — reduces content-ops QA cycles and one-off template fixes per content type.
• URL and canonical integrity. The get_path fixes (Twig function and URI) touch canonical URLs, internal links, and sitemap generation — directly relevant to SEO health and analytics attribution.
• Lower onboarding cost. Documentation fixes matter if we plan to bring in agency or contract contributors to author Twig templates.

When to Consider This Package

Adopt when:

• We're a Laravel team willing to own a PHP codebase and want content modelled inside the application rather than in a separate SaaS.
• Content is genuinely hierarchical and typed — page trees, landing pages, campaign microsites — where a tree of node types maps cleanly to the information architecture.
• We want Twig templating available to content authors or partner agencies, or we need template portability across an existing Twig estate.
• We want control of the data layer: query_builder override is now a supported extension point, so unusual data sourcing doesn't force a fork.
• We can absorb 0.x churn: pin the version, budget time for minor-version upgrades, and avoid depending on undocumented internals.

Look elsewhere when:

• We need mature editorial workflow out of the box — revisions, scheduling, granular roles/permissions, approvals — with vendor support.
• We need a hosted/headless CMS with SLAs, or procurement requires a supported 1.x+ API contract.
• The team isn't Laravel/PHP, or the org mandates Blade-only templating (Twig introduces a second templating dialect).
• Requirements include multi-tenant isolation, heavy localisation, or compliance guarantees the project doesn't document.
• Our use case is a simple brochure site — the modelling power is overhead against a lighter static or page-builder option.

How to Pitch It (Stakeholders)

Executives: This is a patch release on a package we'd use to build our content platform on Laravel. Direct cost is near zero; the value is a corrected SEO title separator, fixed URL path generation (fewer broken links and canonical errors), and a new extension point that lets us add dynamic listings later without custom engineering. Risk is contained but real: the package is pre-1.0, so we pin the version and schedule upgrades deliberately rather than tracking latest.

Engineering: Upgrade is patch-level and low risk, but verify before rollout: (1) confirm our TreeNodeType subclasses aren't relying on the previous query_builder behaviour — the change enables overriding, which is additive but should be checked against existing subclasses; (2) audit Twig get_path usage and any URI-based URL building in sitemaps, canonicals, and internal links; (3) diff rendered Title/Excerpt output on listing cards and social metadata, since favourite keys now take precedence; (4) run template regression across our highest-traffic page types. Pin to 0.3.2 and treat upcoming minor releases as potentially breaking.