feat: Add FrankenPHP deployment support

[Copilot]

ChurchCRM's multi-entry-point Slim 4 architecture requires explicit per-subdirectory routing — without it, unauthenticated users hit an infinite redirect loop (/session/begin → root index.php → /session/begin → …). Apache handles this via .htaccess; FrankenPHP (like nginx) requires explicit configuration.

New files

• docker/Dockerfile.churchcrm-frankenphp — Multi-stage image based on dunglas/frankenphp:1-php8.4. Uses the bundled install-php-extensions helper for all required extensions. dev stage mirrors the pattern from the other Dockerfiles (Xdebug, Composer, Node.js).

• docker/frankenphp/Caddyfile — Routes each Slim 4 sub-app to its own entry point using handle + try_files, blocking /logs/*, /tmp_attach/*, and dotfiles. Includes a commented subdirectory-install variant.

  handle /session/* {
      try_files {path} /session/index.php
      php_server
  }
  # ... repeated for api, v2, admin, finance, kiosk, plugins, external, setup
  handle {
      try_files {path} {path}/ /index.php
      php_server
  }

• docker/docker-compose.frankenphp.yaml — Two-service stack (FrankenPHP + MariaDB), one fewer container than the nginx + PHP-FPM reference setup.

Updated files

• docker/README.md — FrankenPHP section: routing explanation, quick start, files table, Caddyfile customisation (including Caddy's automatic HTTPS).

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Question: Has anyone tested/used ChurchCRM with FrankenPHP ?</issue_title>
<issue_description>FrankenPHP combines Caddy (webserver) with PHP (8.4) in one file. This, combined with MariaDB makes a very simple platform to run tools like ChurchCRM on.

When I tried setting it up, I could not get it working. I gave up before determining the exact cause.

Has anyone tested/used ChurchCRM with FrankenPHP ?</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Question: Has anyone tested/used ChurchCRM with FrankenPHP ? #8211

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[Copilot]

Pull request overview

Adds a reference FrankenPHP (Caddy + PHP) deployment option for ChurchCRM’s multi-entry-point Slim 4 layout, including explicit per-subdirectory routing to avoid /session/begin redirect loops in non-Apache setups.

Changes:

• Added a FrankenPHP-compatible Caddyfile with explicit routing for each Slim sub-app entry point.
• Added a FrankenPHP + MariaDB docker-compose reference stack.
• Added a FrankenPHP Dockerfile and updated Docker documentation to include the new deployment option.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
docker/frankenphp/Caddyfile	New Caddy routing and access control rules tailored to ChurchCRM’s multi-entry-point structure.
docker/docker-compose.frankenphp.yaml	New two-service (FrankenPHP + MariaDB) reference compose configuration.
docker/Dockerfile.churchcrm-frankenphp	New FrankenPHP image build (extensions + dev tooling stage).
docker/README.md	Documents FrankenPHP deployment rationale, quick start, and file list.

[Copilot]

The @dotfiles matcher blocks any path containing a dot segment, which also matches /.well-known/*. That will break Caddy’s automatic HTTPS (ACME HTTP-01 challenge uses /.well-known/acme-challenge/). Consider exempting /.well-known/* (or at least /.well-known/acme-challenge/*) from this rule, and mirror the same exception in the commented subdirectory-install example below.

Suggested change

	# Block .htaccess and other dot-files
	@dotfiles path_regexp hidden (^|/)\.
	# Block .htaccess and other dot-files, but allow /.well-known/* for ACME HTTP-01
	@dotfiles path_regexp hidden (^|/)\.(?!well-known(/|$))

[Copilot]

The path matchers for sensitive directories only cover /logs/* and /tmp_attach/*, but not the directory roots /logs and /tmp_attach (no trailing slash). Since the root handler uses try_files {path} {path}/ ..., requests to /logs or /tmp_attach can still hit the normal routing path; update these matchers to include both the directory itself and its contents (and do the same in the commented subdirectory-install example).

Suggested change

	@logs path /logs/*
	respond @logs 404
	# Block access to uploaded file attachments (served via API only)
	@tmp_attach path /tmp_attach/*
	@logs path /logs /logs/*
	respond @logs 404
	# Block access to uploaded file attachments (served via API only)
	@tmp_attach path /tmp_attach /tmp_attach/*