Flight Laravel Package

Product Decisions This Supports

• Build vs. buy (micro-framework vs. full-stack): FlightPHP is a PHP micro-framework in the same decision space as Slim or a hand-rolled router. This release does not change that calculus — it reinforces FlightPHP as a lightweight, low-ceremony choice when a full Laravel install is overkill for an internal service, a small API, or a legacy PHP codebase you're incrementally modernizing.
• Security posture / compliance roadmap: v3.19.4 adds flight.views.restrict_to_path, an opt-in guard that keeps rendered templates confined to the configured views directory. This is a direct mitigation for local file inclusion / path traversal when template names can be influenced by user input (e.g. render($page) driven by a query param). If your roadmap includes hardening internal apps or clearing a security review finding, this is a checkable box — but only if you turn it on.
• Scope of a migration or refactor: If you are consolidating ad-hoc PHP scripts into a framework, this is evidence the project is actively maintained (small, focused PR, same-day patch release cadence) and that security-relevant configuration is being added incrementally rather than only in major versions.
• Feature decisions it does not support: Nothing here affects templating engine choice, ORM/database strategy, queueing, or auth. Do not treat this release as a signal to expand FlightPHP into a heavier application tier.
• Use cases it unblocks: Multi-tenant or CMS-lite admin panels where template selection is dynamic, plus any product surface where you render partially user-controlled view names and want defense-in-depth without adopting Twig/Blade sandboxing.

When to Consider This Package

Consider FlightPHP when:

• You need routing + views + a thin request/response layer, and your team is already fluent in plain PHP.
• Your product is a small API, internal tool, prototype, or a strangler-pattern shim in front of a legacy app.
• Ops constraints favor a minimal dependency footprint and fast cold starts over batteries-included conventions.
• You have (or are willing to add) explicit security configuration — including enabling flight.views.restrict_to_path — as part of your template rendering standard.

Look elsewhere when:

• You need first-class ORM, queues, events, broadcasting, or a mature auth/permissions ecosystem — Laravel or Symfony will cost less over the product's life than assembling those pieces.
• You require a vendor with commercial support or an SLA; FlightPHP is community-maintained.
• Your team lacks PHP security depth and would benefit from a framework whose secure defaults are on by default. Note this feature is opt-in — the unsafe behavior remains the default — so adoption requires a deliberate config step in every environment, and a code review checklist item to keep it enabled.
• The application is template-name-heavy with user input and you need a sandboxed template engine with a formal security model rather than a path restriction.

Adoption criteria before committing: confirm the config key is documented and pinned in your config management, add a regression test asserting traversal attempts return 4xx/404, and verify behavior across dev/staging/prod since an incorrect views path will now hard-fail rendering.

How to Pitch It (Stakeholders)

For executives: A small, low-risk patch to a lightweight PHP framework we are evaluating. It adds an opt-in security control that limits template rendering to an approved directory — good hygiene for internal tools and small services, and a useful answer to "is this maintained and security-conscious?" It is not a reason on its own to standardize on the framework.

For engineering: v3.19.4 is a non-breaking, opt-in addition — flight.views.restrict_to_path. No migration required, no deprecations. Recommendation: enable it in all environments where view names can be influenced by request data, add it to the shared config baseline, and cover it with a traversal regression test. Security impact is real but narrow: it hardens template path resolution only. It does not address input validation, auth, or output escaping, so keep existing controls in place. Also worth flagging for planning: the protective default is still off, which is a governance item for us rather than a framework defect.